Abstract: A work flow manager (1) of a gateway comprises a process automation component (2), a policy engine (3), and a traffic gateway (4). The work flow manager (1) communicates via the internet (5) over IP with content providers (6) and content aggregators (7). On the other side it communicates over the Internet or over a private IP network, using diverse proprietary and known protocols with service enabler resources (20) including mobile network SMSCs, MMSCs and IMSs (IP Multi-Media Sub-systems). The process automation component (2) presents a GUI to generate a work flow definition in a high level business process execution language (BPEL), with interaction with the service enabler resources (20) which implement the process. The policy engine (3) interprets the BPEL to provide lower-level policy enforcement work, flows in a policy enforcement execution language (PEEL).

Abstract: A gateway (1) interfaces between application providers (APs, (4)) and at least one aggregate AP (3) which in turn is linked to multiple APs (4). The gateway (1) manages cascading of access control rights by the APs (4) to reflect links via aggregate APs (3). On the other side the gateway (1) is linked with mobile network enablers (10-15) for communication with users. The gateway (1) performs convergence by conditionally processing or rendering content with multiple content and/or bearer formats. Internally, the gateway (1) comprises a CORBA middleware mechanism (20), and multiple services (21-23) communicating with each other via the middleware mechanism.

Abstract: A gateway (1) has a platform on which resides a CORBA bus (22) an inner layer (23) of Parlay APIs, and an outer layer (24) of network service interfaces for controlling network resources (2). The gateway (1) also comprises application interfaces (20) and Parlay APIs (21) residing on remote platforms which also host applications (10, 13, 14) wishing to access the network resources (2). The network resources (2) interface directly with the Parlay APIs (23) if they have Parlay APIs themselves, or otherwise with the interfaces (24). On the application side, the application interfaces (20) are provided as Java Beans which may be instantiated by an XML interpreter in response to high level XML commands defining application-side interfacing requirements.