System architecture and method for energy industry trading and transaction management

• US 20060036448A1
• Filed: 06/13/2002
• Published: 02/16/2006
• Est. Priority Date: 06/13/2001
• Status: Active Grant

• Current Assignee: Fidelity Information Services, LLC (Fidelity National Information Services Incorporated)
• Original Assignee: Caminus Corp. (Fidelity National Information Services Incorporated)
• Inventors: Haynie, Cynthia, Curfman, Benjamin, Hamilton, Josiah, Pever, Daryl A, Savoie, Philip J, Kadam, Nitin, Alexander, Robert Michael, Hugetz, Shannon, Mossop, Kevin Trevor, Gilmer, Joan, Danielson, Leslie H, Pletka, John E, Stockton, Sunny D
• Granted Patent: US 8,065,219 B2
• Time in Patent Office: Days
• US Class Current: 705/37
• CPC Class Codes: G06Q 10/10 Office automation; Time management
• CPC Class Codes: G06Q 30/08 Auctions
• CPC Class Codes: G06Q 40/04 Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

A system architecture and method for energy industry trading and transaction management includes a business logic server-based layer and a database layer. The business logic server-based layer includes a parameter-based configuration of at least one business logic service. The business logic service is configurable to enable a deployment of the system to be compatible with a respective business practice of at least one client customer. The at least one business logic service is configured to support energy trading and transaction management and to utilize business rules operable on an event basis for processing via an API at least one of energy trading and transaction management data, including data specific to the at least one client customer. The database layer operatively connects to the business logic layer for storing the data processed by the business logic layer in a database.

Claims

1. A system architecture for energy industry trading and transaction management comprising:

a business logic server-based layer including a parameter-based configuration of at least one business logic service configurable to enable a deployment of said system to be compatible with a respective business practice of at least one client customer, the at least one business logic service configured to support energy trading and transaction management and to utilize business rules operable on an event basis for processing via an API at least one of energy trading and transaction management data, including data specific to the at least one client customer;

a database layer operatively connected to said business logic layer for storing the data processed by said business logic layer in a database;

a security layer operatively connected to said configurable business logic server-based layer configured to filter requests to said configurable business logic layer according to a system security, wherein said security layer is configured to provide a secure access to said configurable business logic server-based layer, and wherein said business logic server-based layer is further configured to provide security at an object and client company level within said system architecture;

a messaging layer operatively connected to said business logic layer configured to facilitate an XML-based interchange and open messaging transport communication link between said business logic layer and another layer;

a presentation layer configured to receive at least one of a client request, a reporting request, a migration request, and a third party request; and

a messaging layer operatively connected between said presentation layer and said business logic layer, said messaging layer configured to facilitate an XML-based interchange and open messaging transport communication link between said presentation layer and said business logic layer.

2. The system architecture of claim 1, wherein said business logic layer includes an applications server, and wherein said database layer includes a database server separate from the application server.

3. The system architecture of claim 2, wherein said business logic layer is further configured to provide flexibility, scalability, and extensibility with the use of parameter driven business rules.

4. The system architecture of claim 2, wherein said business logic layer is implemented as a hosted application service provider (ASP).

5. The system architecture of claim 2, wherein said system architecture is an open architecture configured for an ease of integration with a client system.

6. The system architecture of claim 2, wherein the parameter-based configuration includes base data attributes that are date effective.

7. The system architecture of claim 6, wherein the base data includes at least one of a business associate, facility, point, and accounts.

8. The system architecture of claim 7, wherein the base data further includes at least one of contract party data, deal party data, and transactional data that are rendered date effective.

9. The system architecture of claim 2, wherein the applications server includes a Java 2 Platform, Enterprise Edition architecture.

10. The system architecture of claim 2, wherein the database server is configured to operate in an application service provider (ASP) mode.

11. The system architecture of claim 2, wherein the database server further includes security features for partitioning data within the database, and wherein the applications server is configured to communicate to the database server through database connectivity drivers.

12. The system architecture of claim 2, wherein said business logic layer further includes an object-relational mapping tool configured to provide access between said business logic layer and said database layer.

13. The system architecture of claim 12, wherein objects created by the object-relational mapping tool are used to query data in the database and to get query results back.

14. The system architecture of claim 1, wherein said business logic layer includes an applications server for running an applications program of a hierarchy of modules, the applications server including a configuration file adapted to configure the hierarchy of modules for use in the parameter-based configuration of the at least one business logic service, the hierarchy of modules including at least a base module.

15. The system architecture of claim 14, wherein the base module is configured to maintain information about baseline data required by said system architecture, including at least one selected from the group consisting of counter-parties, pipelines, nomination points, meters, and units.

16. The system architecture of claim 14, wherein a next module in the hierarchy of modules includes a deals module.

17. The system architecture of claim 16, wherein the deals module includes a contract sub-module configured to maintain information about at least one selected from the groups consisting of buy/sell, transportation, storage, pooling, and capacity release contracts that a client has with the client'"'"'s customers;

contracts and custody contracts containing base agreement information;

specifications representing terms, points, quantities, and pricing details that are used for billings and payments; and

pricing indices.

18. The system architecture of claim 16, wherein the deals module includes a deal making sub-module configured to maintain information about transactions and deals of a client, the transactions and deals including at least one selected from the groups consisting of buy and sell deals, broker commissions, multiple pipelines, point-level pricing, multi-component formula-base price calculations, and deal points, quantities and pricing details used for invoices and remittances.

19. The system architecture of claim 16, wherein a next module in the hierarchy of modules includes an operations module.

20. The system architecture of claim 19, wherein the operations module includes a nomination sub-module configured to receive and/or create transportation, storage, pooling, and interconnection nominations, and to perform pool-to-pool transfers, the nomination sub-module further configured to process various nomination models, including at least one of GISB and international requirements.

21. The system architecture of claim 19, wherein the operations module includes a capacity management and confirmations sub-module configured to perform at least one selected from the groups consisting of schedule pipeline capacity and prioritize contractual volumes based on parameter driven scheduling and curtailment rules;

enable a user to model a pipeline and to set constraint points and other criteria that permit tariff compliant reduction of flowing volumes; and

obtain confirmation of nominated and/or scheduled quantities at the nomination point level by operator, agent, or shipper.

22. The system architecture of claim 19, wherein the operations module includes an allocations and balancing sub-module configured to perform at least one selected from the groups consisting of maintain allocations information including configurations of tiers, PDA Rules, and rules;

and accept meter and point information and calculate imbalances and point variances based on nominated, scheduled, and measured volumes.

23. The system architecture of claim 19, wherein a next module in the hierarchy of modules includes an accounting module.

24. The system architecture of claim 23, wherein the accounting module includes an accounting and settlement module configured to provide at least one selected from the groups consisting of provide necessary processing to consolidate all the contracts, deals, scheduling and allocations information for generating invoices and/or remittances for a client;

support external penalty calculations configurable for differing pipeline tariffs;

specify override rates and prices, process prior month adjustments, and calculate taxes;

G/L account assignment, calculation of accruals for business not yet finalized, and support of interfaces to external General Ledger and Accounts Receivable systems.

25. The system architecture of claim 14, wherein the applications server includes a Java 2 Platform, Enterprise Edition architecture.

26. The system architecture of claim 25, wherein at least one module of the hierarchy of modules includes:

(i) a class factory, wherein the class factory is configured to establish for the respective module a category of objects defined by common properties of different objects that belong to the class, and

(ii) at least one selected from the group consisting of;

(a) an API enterprise java bean component operatively connected to an object-relational mapping tool, and

(b) an API enterprise java bean component operatively connected to at least one selected from the group consisting of;

(b1) an EJB enterprise java bean object,

(b2) a data layer (DL) object, and

(b3) at least one selected from the group consisting of a class factory and an API enterprise java bean component of another of the modules in the hierarchy of modules.

27. The system architecture of claim 26, wherein the class factory includes a base class factory configured to establish a category of base objects defined by common properties of different objects that belong to a the base class, wherein the base objects include at least one selected from the group consisting of counter-parties, pipelines, nomination points, meters, and units.

28. The system architecture of claim 26, wherein the class factory includes a deals class factory configured to establish a category of deals objects defined by common properties of different objects that belong to the deals class, wherein the deals objects include at least one selected from the group consisting of contracts, pricing, deal making, and transactions.

29. The system architecture of claim 26, wherein the class factory includes an operations class factory configured to establish a category of operations objects defined by common properties of different objects that belong to the operations class, wherein the operations objects include at least one selected from the group consisting of nominations, capacity management, capacity confirmations, allocations, and balancing.

30. The system architecture of claim 26, wherein the class factory includes an accounting class factory configured to establish a category of accounting objects defined by common properties of different objects that belong to the accounting class, wherein the accounting objects include at least one selected from the group consisting of invoices and remittances.

31. The system architecture of claim 26, wherein the object-relational mapping tool is configured to map objects to database tables in the database.

32. The system architecture of claim 26, wherein the data layer (DL) object is configured to communicate data to and from the database via database connectivity drivers.

33. The system architecture of claim 26, wherein the API enterprise java bean component is configured to establish a common interface of EJB enterprise java bean components.

34. The system architecture of claim 33, wherein the API enterprise java bean component is further configured to execute an entity validation utility for validating incoming data prior to routing the data to an EJB enterprise java bean component.

35. The system architecture of claim 26, wherein the EJB enterprise java bean component is configured to act as a remote object to a calling API enterprise java bean component.

36. The system architecture of claim 35, wherein the EJB enterprise java bean component is further configured to carry out a parameter based business rule for a respective class.

37. The system architecture of claim 14, wherein the configuration file contains configuration information for the applications program, and responsive to an execution of the applications program, the applications program accesses the configuration file to identify parameters that are in effect for the at least one business logic service.

38. The system architecture of claim 1, wherein said business logic layer includes at least one module for performing the at least one business logic service, the business logic service including a parameter based configuration.

39. The system architecture of claim 38, wherein the parameter based configuration includes date and time effective attributes.

40. The system architecture of claim 1, wherein an event can include at least one of a client customer request, a transaction event, a third party event, and a system event.

45. The system architecture of claim 1, further comprising a simple object application protocol (SOAP) server operatively connected to said presentation layer and said messaging layer and configured to provide a message based protocol to carry an XML based payload for accessing the business logic layer.

46. The system architecture of claim 1, wherein said presentation layer includes a browser based web server presentation layer configured to construct Java Server Pages, handle JSP requests, and provide a functional graphical user interface for handling web requests, said presentation layer further including a class factory and a configuration file, wherein the class factory is configured to establish a category of objects defined by common properties of different objects that belong to the class, and wherein a path of an incoming request to the business logic layer is dynamically determined as a function of the configuration file and the class factory, the path including either a direct call from the web server to the applications server or a proxy call from the web server, through said messaging layer, to the applications server.

47. The system architecture of claim 46, wherein the browser based web server presentation layer is further configured to deploy at least one item of web browser page content in a manner wherein the deployment of the content mimics a client/server operation.

48. The system architecture of claim 47, wherein deployment of the at least one item includes placing the at least one item into an ActiveX component within an HTML component.

49. The system architecture of claim 1, wherein said messaging layer is configured for one selected from the group consisting of:

to enable an integration of an existing business system into said system architecture;

to process at least one of a client request and a system request, wherein processing the request includes at least one of capturing the request, transforming the request, and routing the request to at least one destination selected from the group consisting of a legacy system destination and a system architecture destination;

to implement a client specified business rule prior to accessing core business functionality within said business logic layer;

to enable bi-directional communication between incompatible enterprise applications of a third party and said system architecture via messages across a common platform; and

to enable bi-directional communications between enterprise java beans (EJBs) of said business logic layer and an external application.

50. The system architecture of claim 1, further comprising:

a security layer operatively connected to said presentation layer and said business logic layer for providing a secure access to said presentation layer and said business layer.

51. The system architecture of claim 50, wherein said security layer is an LDAP compliant database server-based security layer configured to manage userids, passwords, and roles in said system.

52. The system architecture of claim 51, wherein said business logic layer includes a J2EE applications server, and wherein said database layer includes a database server separate from the application server, said security layer further including a means for handling EJB security, the security means operatively connected to said J2EE applications server for filtering requests to said J2EE application server, said security layer still further including an application level security means configured to render method level security on objects processed within the applications server.

53. The system architecture of claim 46, further including a secure sockets layer connection operatively connected between a client browser and a presentation layer GUI, wherein the secure SSL connection creates a unique session id and wherein said messaging layer is further configured to call an appropriate enterprise bean within the business logic layer under correct credentials in response to the userid, password, and session id.

54. The system architecture of claim 1, wherein said business logic layer includes an applications server, the applications server including a Java 2 Platform, Enterprise Edition architecture, the applications server for running an applications program of a hierarchy of modules, the applications server further including a configuration file adapted to configure the hierarchy of modules for use in the parameter-based configuration of the at least one business logic service, the hierarchy of modules including a base module, a deals module, an operations module, and an accounting module, and

wherein said database layer includes a database server separate from the application server, said system architecture further comprising:

a presentation layer configured to receive at least one of a client request, a reporting request, a migration request, and a third party request;

a messaging layer operatively connected between said presentation layer and said business logic layer, said messaging layer configured to facilitate an XML-based interchange and open messaging transport communication link between said presentation layer and said business logic layer; and

a security layer operatively connected to said presentation layer and said business logic layer for providing a secure access to said presentation layer and said business layer.

55. The system architecture of claim 16, wherein the deals module includes a pricing engine configured to perform at least one of price formulas, quantity formulas, indexes, tiers, and a price resolver, the pricing engine further configured to be common across multiple aspects of a respective business.

56. The system architecture of claim 16, wherein the deals module includes an inventory engine configured to perform at least one of tracking inventory, valuing inventory, accessing charges, and assessing penalties, the inventory engine further configured to cover multiple inventory requirements across a respective business.

41. (canceled)

42. (canceled)

43. (canceled)

44. (canceled)

57. A method for energy industry trading and transaction management comprising:

utilizing a business logic server-based layer having a parameter-based configuration of at least one business logic service configurable to enable a deployment of said method system to be compatible with a respective business practice of at least one client customer;

configuring the at least one business logic service to support energy trading and transaction management;

utilizing business rules operable on an event basis for processing via an API at least one of energy trading and transaction management data, including data specific to the at least one client customer;

storing the data processed by the business logic layer in a database;

operatively connecting a security layer to the configurable business logic server-based layer and configuring the security layer to filter requests to the configurable business logic layer according to a system security,

operatively connecting a messaging layer to the business logic layer and configuring the messaging layer to facilitate an XML-based interchange and open messaging transport communication link between the business logic layer and another layer,

configuring a presentation layer to receive at least one of a client request, a reporting request, a migration request, and a third party request; and

operatively connecting a messaging layer between the presentation layer and the business logic layer, and

configuring the messaging layer to facilitate an XML-based interchange and open messaging transport communication link between the presentation layer and the business logic layer.

58. The method of claim 57, wherein the business logic layer includes utilizing an applications server for running an applications program of a hierarchy of modules, the applications server including a configuration file adapted to configure the hierarchy of modules for use in the parameter-based configuration of the at least one business logic service, the hierarchy of modules including at least a base module.

59. The method of claim 58, wherein the applications server includes a Java 2 Platform, Enterprise Edition architecture.

60. The method of claim 59, wherein at least one module of the hierarchy of modules includes:

(i) a class factory, wherein the class factory is configured to establish for the respective module a category of objects defined by common properties of different objects that belong to the class, and

(ii) at least one selected from the group consisting of;

(a) an API enterprise java bean component operatively connected to an object-relational mapping tool, and

(b) an API enterprise java bean component operatively connected to at least one selected from the group consisting of;

(b1) an EJB enterprise java bean object,

(b2) a data layer (DL) object, and

(b3) at least one selected from the group consisting of a class factory and an API enterprise java bean component of another of the modules in the hierarchy of modules.

61. The method of claim 60, wherein the API enterprise java bean component is configured to establish a common interface of EJB enterprise java bean components.

62. The method of claim 57, wherein the business logic layer includes at least one module for performing the at least one business logic service, the business logic service including a parameter based configuration.

63. The method of claim 61, wherein the parameter based configuration includes date and time effective attributes.

64. (canceled)

65. (canceled)

66. (canceled)

67. A method for energy industry trading and transaction management comprising:

utilizing a business logic server-based layer having a parameter-based configuration of at least one business logic service configurable to enable a deployment of said method system to be compatible with a respective business practice of at least one client customer;

configuring the at least one business logic service to support energy trading and transaction management;

utilizing business rules operable on an event basis for processing via an API at least one of energy trading and transaction management data, including data specific to the at least one client customer; and

storing the data processed by the business logic layer in a database, wherein the business logic layer includes utilizing an applications server, the applications server including a Java 2 Platform, Enterprise Edition architecture, the applications server for running an applications program of a hierarchy of modules, the applications server further including a configuration file adapted to configure the hierarchy of modules for use in the parameter-based configuration of the at least one business logic service, the hierarchy of modules including a base module, a deals module, an operations module, and an accounting module, and

wherein storing the data in a database includes utilizing a database layer that includes a database server separate from the application server, said method further comprising;

configuring a presentation layer to receive at least one of a client request, a reporting request, a migration request, and a third party request;

operatively connecting the presentation layer to the business logic layer via a messaging layer, the messaging layer configured to facilitate an XML-based interchange and open messaging transport communication link between the presentation layer and the business logic layer; and

operatively connecting a security layer to the presentation layer and the business logic layer for providing a secure access to the presentation layer and the business layer.