Abstract:
A novel system and method is herein described for creating user interfaces for a plurality of users of an office land mobile network (OLMN), said system and method comprising means and steps for receiving a request from said user for service from said OLMN, said request comprising data pertaining to said service; validating said data received from said request; if said data is valid for said request, formatting said data into an internal format; submitting said formatted request to an appropriate framework for application processing; and returning a user interface, said user interface being appropriate for the particular request received.

Description:
STATEMENT OF RELATED CASES  
       [0001]    The following related cases are co-pending, co-owned patent applications—herein incorporated by reference—filed on even date as the present application:  
         [0002]    Ser. No. ______ entitled “OBJECT COMMUNICATION SERVICES SOFTWARE DEVELOPMENT SYSTEM AND METHODS” to Karen Capers and Peter Alvin.  
         [0003]    Ser. No. _______ entitled “INTEGRATED DIAGNOSTIC CENTER” to Karen Capers and Michael Brooking. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0004]    The convergence between legacy PBX, corporate IP Networks, on the one hand, and wireless communications, on the other, is continuing apace. Corporate GSM (or more generally, Office Land Mobile Network, or OLMN) systems that allow a subscribed user to roam onto a corporate wireless subsystem “campus” from the public land mobile network (PLMN) are known in the art.  
           [0005]    With newer generations of such OLMNs rolling out, new services are being expected and demanded by the users of such systems. It is typically desirable to have such services—from new communications services to enhancing existing legacy services—seemlessly presented to the user (across the various platforms—PBX, network and wireless—within a given campus). Additionally, it is desirable to have these new services interoperating across various legacy PBX, networks and wireless subsystems—perhaps involving multiple manufacturers, protocols, operating systems and like.  
           [0006]    It is additionally desirable to for these services to run robustly. Thus, messages can be delivered to end users even though there may be point failures in the OLMN. Additionally, it may be the case that, for communication systems developers, the location of the components that need to communicate on the network is not static, but changes often. Thus, it is desirable to have a development system that anticipates situations that require a wide variety of communication delivery modes and service. It is also desirable to have a development system that anticipates a wide variety of message formats that may differ in both their semantics and syntax.  
           [0007]    In addition to new communications services, it is also desirable to provide a flexible way to create new user interfaces for clients of OLMN, other private networks the Web, as well as command line and platform specific deployments. The extensibility of creating new user interfaces should also provide little or no hardship to administrators of such networks. Thus, any change to user interfaces should ideally have minimal impact on the business logic of the underlying applications.  
         SUMMARY OF THE INVENTION  
         [0008]    The present invention discloses a novel system and method for creating user interfaces for a plurality of users of an office land mobile network (OLMN), said system and method comprising means and steps for receiving a request from said user for service from said OLMN, said request comprising data pertaining to said service; validating said data received from said request; if said data is valid for said request, formatting said data into an internal format; submitting said formatted request to an appropriate framework for application processing; and returning a user interface, said user interface being appropriate for the particular request received. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]    [0009]FIG. 1 is a typical embodiment of an OLMN architecture.  
         [0010]    [0010]FIG. 2 is a diagram of the structural and functional components of an embodiment made in accordance with the principles of the present invention.  
         [0011]    [0011]FIG. 3 is use-case diagram of an embodiment of the presentation services framework made in accordance with the principles of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0012]    [0012]FIG. 1 depicts a typical architecture of an Office Land Mobile Network (e.g. Corporate GSM or “C-GSM”)—illustrating a communication system  10  in accordance with one embodiment of the present invention. The system  10  comprises a private network  12  for providing communication for a plurality of authorized subscribers. According to one embodiment, the private network  12  comprises a communication network for a particular business enterprise and the authorized subscribers comprise business personnel. The private network  12  comprises an office network  14  for providing communication between a plurality of mobile devices  16 , a private branch exchange (PBX) network  18 , and an Internet Protocol (IP) network  20 .  
         [0013]    The office network  14  comprises a wireless subsystem  22  for communicating with the mobile devices  16  and a packet switching subsystem  24  for providing operations, administration, maintenance and provisioning (OAMP) functionality for the private network  12 . The wireless subsystem  22  comprises one or more base station subsystems (BSS)  26 . Each base system subsystem  26  comprises one or more base transceiver stations (BTS), or base stations,  28  and a corresponding wireless adjunct Internet platform (WARP) (alternatively called “IWG”)  30 . Each base station  28  is operable to provide communication between the corresponding WARP  30  and mobile devices  16  located in a specified geographical area.  
         [0014]    Authorized mobile devices  16  are operable to provide wireless communication within the private network  12  for authorized subscribers. The mobile devices  16  may comprise cellular telephones or other suitable devices capable of providing wireless communication. According to one embodiment, the mobile devices  16  comprise Global System for Mobile communication (GSM) Phase 2 or higher mobile devices  16 . Each mobile device  16  is operable to communicate with a base station  28  over a wireless interface  32 . The wireless interface  32  may comprise any suitable wireless interface operable to transfer circuit-switched or packet-switched messages between a mobile device  16  and the base station  28 . For example, the wireless interface  32  may comprise a GSM/GPRS (GSM/general packet radio service) interface, a GSM/EDGE (GSM/enhanced data rate for GSM evolution) interface, or other suitable interface.  
         [0015]    The WARP  30  is operable to provide authorized mobile devices  16  with access to internal and/or external voice and/or data networks by providing voice and/or data messages received from the mobile devices  16  to the IP network  20  and messages received from the IP network  20  to the mobile devices  16 . In accordance with one embodiment, the WARP  30  is operable to communicate with the mobile devices  16  through the base station  28  using a circuit-switched protocol and is operable to communicate with the IP network  20  using a packet-switched protocol. For this embodiment, the WARP  30  is operable to perform an interworking function to translate between the circuit-switched and packet-switched protocols. Thus, for example, the WARP  30  may packetize messages from the mobile devices  16  into data packets for transmission to the IP network  20  and may depacketize messages contained in data packets received from the IP network  20  for transmission to the mobile devices  16 .  
         [0016]    The packet switching subsystem  24  comprises an integrated communication server (ICS)  40 , a network management station (NMS)  42 , and a PBX gateway (GW)  44 . The ICS  40  is operable to integrate a plurality of network elements such that an operator may perform OAMP functions for each of the network elements through the ICS  40 . Thus, for example, an operator may perform OAMP functions for the packet switching subsystem  24  through a single interface for the ICS  40  displayed at the NMS  42 .  
         [0017]    The ICS  40  comprises a plurality of network elements. These network elements may comprise a service engine  50  for providing data services to subscribers and for providing an integrated OAMP interface for an operator, a subscriber location register (SLR)  52  for providing subscriber management functions for the office network  14 , a teleworking server (TWS)  54  for providing PBX features through Hicom Feature Access interfacing and functionality, a gatekeeper  56  for coordinating call control functionality, a wireless application protocol server (WAPS)  58  for receiving and transmitting data for WAP subscribers, a push server (PS)  60  for providing server-initiated, or push, transaction functionality for the mobile devices  16 , and/or any other suitable server  62 .  
         [0018]    Each of the network elements  50 ,  52 ,  54 ,  56 ,  58 ,  60  and  62  may comprise logic encoded in media. The logic comprises functional instructions for carrying out program tasks. The media comprises computer disks or other computer-readable media, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), other suitable specific or general purpose processors, transmission media or other suitable media in which logic may be encoded and utilized. As described in more detail below, the ICS  40  may comprise one or more of the servers  54 ,  58 ,  60  and  62  based on the types of services to be provided by the office network  14  to subscribers as selected by an operator through the NMS  42 .  
         [0019]    The gateway  44  is operable to transfer messages between the PBX network  18  and the IP network  20 . According to one embodiment, the gateway  44  is operable to communicate with the PBX network  18  using a circuit-switched protocol and with the IP network  20  using a packet-switched protocol. For this embodiment, the gateway  44  is operable to perform an interworking function to translate between the circuit-switched and packet-switched protocols. Thus, for example, the gateway  44  may packetize messages into data packets for transmission to the IP network  20  and may depacketize messages contained in data packets received from the IP network  20 .  
         [0020]    The communication system  10  may also comprise the Internet  70 , a public land mobile network (PLMN)  72 , and a public switched telephone network (PSTN)  74 . The PLMN  72  is operable to provide communication for mobile devices  16 , and the PSTN  74  is operable to provide communication for telephony devices  76 , such as standard telephones, clients and computers using modems or digital subscriber line connections. The IP network  20  may be coupled to the Internet  70  and to the PLMN  72  to provide communication between the private network  12  and both the Internet  70  and the PLMN  72 . The PSTN  74  may be coupled to the PLMN  72  and to the PBX network  18 . Thus, the private network  12  may communicate with the PSTN  74  through the PBX network  18  and/or through the IP network  20  via the PLMN  72 .  
         [0021]    The PBX network  18  is operable to process circuit-switched messages for the private network  12 . The PBX network  18  is coupled to the IP network  20 , the packet switching subsystem  24 , the PSTN  74 , and one or more PBX telephones  78 . The PBX network  18  may comprise any suitable network operable to transmit and receive circuit-switched messages. In accordance with one embodiment, the gateway  44  and the gatekeeper  56  may perform the functions of a PBX network  18 . For this embodiment, the private network  12  may not comprise a separate PBX network  18 .  
         [0022]    The IP network  20  is operable to transmit and receive data packets to and from network addresses in the IP network  20 . The IP network  20  may comprise a local area network, a wide area network, or any other suitable packet-switched network. In addition to the PBX network  18 , the Internet  70  and the PLMN  72 , the IP network  20  is coupled to the wireless subsystem  22  and to the packet switching subsystem  24 .  
         [0023]    The IP network  20  may also be coupled to an external data source  80 , either directly or through any other suitable network such as the Internet  70 . The external data source  80  is operable to transmit and receive data to and from the IP network  20 . The external data source  80  may comprise one or more workstations or other suitable devices that are operable to execute one or more external data applications, such as MICROSOFT EXCHANGE, LOTUS NOTES, or any other suitable external data application. The external data source  80  may also comprise one or more databases, such as a corporate database for the business enterprise, that are operable to store external data in any suitable format. The external data source  80  is external in that the data communicated between the IP network  20  and the external data source  80  is in a format other than an internal format that is processable by the ICS  40 .  
         [0024]    The PLMN  72  comprises a home location register (HLR)  82  and an operations and maintenance center (OMC)  84 . The HLR  82  is operable to coordinate location management, authentication, service management, subscriber management, and any other suitable functions for the PLMN  72 . The HLR  82  is also operable to coordinate location management for mobile devices  16  roaming between the private network  12  and the PLMN  72 . The OMC  84  is operable to provide management functions for the WARPs  30 . The HLR  82  may be coupled to the IP network  20  through an SS7-IP interworking unit (SIU)  86 . The SIU  86  interfaces with the WARPs  30  through the IP network  20  and with the PLMN  72  via a mobility-signaling link.  
         [0025]    [0025]FIG. 2 is a diagram of the structural and functional components of one embodiment of a system made in accordance with the principles of the present invention.  
         [0026]    Structural Components  
         [0027]    Presentation Services System (or Framework)  200  comprises several components as depicted and is responsible for the web-based user interface into the ICS system. It provides the interfaces for user operations and validates basic user-input data. It further sends user-input data to other frameworks for application specific processing and displays the returned results to the user. System  200  also performs HTTP session management. A user&#39;s session will be established by the session framework and used by the Presentation Services System for displaying a user&#39;s view of the system, based on the user&#39;s role. Features available include subscriber provisioning, profile management, instant messaging and OAMP.  
         [0028]    HttpSession component  202  will provide browser session handling. This component could be provided by the third-party product used to implement the presentationEngine component  204 .  
         [0029]    The interface to httpSession component  202  is as follows:  
         [0030]    public interface ImanageHttpSession  
         [0031]    IManageHttpSession is supported by the httpSession component. It provides access to HTTP session handling.  
         [0032]    The presentation Engine component  204  will provide user interface displays for web-based ICS system access. Elements of the presentationLogic component  206  will run on this engine. These elements could include, but are not limited to, applets, JSPs, servlets, etc. PresentationEngine component  204  provides the functionality of a web server, a servlet engine and/or an application server, and could be supplied by known off-the-shelf products. It will provide HTTP and/or HTTPS access to the client browser.  
         [0033]    The interface of presentationEngine component  204  is as follows:  
         [0034]    public interface IHttp  
         [0035]    This interface serves as a logical entry point for all ICS system web-based access (e.g. HTTP access).  
         [0036]    The presentationLogic component  206  contains the library of classes to support the business logic and application processing necessary for this system or framework to do its job. This could include applets, servlets, JavaBeans or any other collection of classes needed to process and perform simple validation of data. This component supports the IServiceRequest interface.  
         [0037]    The presentationLogic component  206  comprises two Class Nodes:  
         [0038]    com.opuswave.ics.serviceEngine.presentationServices.presentationLogic.LoginAction  
         [0039]    com.opuswave.ics.serviceEngine.presentationServices.presentationLogic.LoginForm  
         [0040]    The class node “LogicAction” is described by:  
         [0041]    public class LoginAction  
         [0042]    Extends:  
         [0043]    org.apache.struts.action.Action  
         [0044]    This Action bean will perform the login handling.  
         [0045]    Operation Detail  
         [0046]    authenticateUser  
         [0047]    public String authenticateUser(String userid, String password)  
         [0048]    This method is pulled out of the perform method in order for the CLI  208  to use this class.  
         [0049]    perform  
         [0050]    public ActionForward perform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response)  
         [0051]    This method is called on by ActionServlet when a request is made for login action. “mapping” is a class representation of our logon action as defined in action.xml. “form” is our form bean that we created for this action, it should be an instance of “LoginForm”.  
         [0052]    The class node “LoginForm” is described by:  
         [0053]    public class LoginForm  
         [0054]    Extends:  
         [0055]    org.apache.struts.action.ActionForm  
         [0056]    The LoginForm will perform data gathering and validation of login information.  
         [0057]    Attribute Detail  
         [0058]    password  
         [0059]    private String password  
         [0060]    userid  
         [0061]    private String userid  
         [0062]    Operation Detail  
         [0063]    getPassword  
         [0064]    public String getpassword( )  
         [0065]    getuserid  
         [0066]    public String getuserid( )  
         [0067]    setPassword  
         [0068]    public void setPassword(String password)  
         [0069]    setUserid  
         [0070]    public void setUserid(String userid)  
         [0071]    validate  
         [0072]    public ActionErrors validate(ActionMapping mapping, HttpServletRequest request)  
         [0073]    Interface Detail  
         [0074]    Interface  
         [0075]    public interface IServiceRequest  
         [0076]    This interface allows the presentationEngine component  204  to pass service requests to the presentationLogic component  206  for validation and application processing.  
         [0077]    The subscriptionEngine component  210  provides access to the event component in the Object Communication Services framework. This allows clients to subscribe to real-time data such as alarms and event notifications. This component supports the interface IClientSubscribe.  
         [0078]    Class Nodes  
         [0079]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.AlarmObserver  
         [0080]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.AlarmSubscriber  
         [0081]    Interface Nodes  
         [0082]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.IClientSubscribe  
         [0083]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer  
         [0084]    Class Detail  
         [0085]    AlarmObserver Class  
         [0086]    public class AlarmObserver  
         [0087]    Implements:  
         [0088]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer  
         [0089]    The AlarmObserver class implements the abstract interface Observer as described in the GoF Observer pattern. The AlarmObserver plays the role of the ConcreteObserver. The AlarmObserver&#39;s update( ) method will be called when an alarm is generated by the OAMPManager.  
         [0090]    Operation Detail  
         [0091]    update  
         [0092]    public void update( )  
         [0093]    Class  
         [0094]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.AlarmSubscriber  
         [0095]    public class AlarmSubscriber  
         [0096]    Implements:  
         [0097]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.IClientSubscribe  
         [0098]    This is the class for the client subscribers. Each instance will be notified by their notify( ) method when an alarm meeting their request is received by the subscription engine. This class implements the IClientSubscribe interface.  
         [0099]    Interface Detail  
         [0100]    Interface  
         [0101]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.IClientSubscribe  
         [0102]    public interface IClientSubscribe  
         [0103]    This interface allows the presentationLogic component to subscribe and receive events through the subscriptionEngine component.  
         [0104]    Class  
         [0105]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer  
         [0106]    Interface  
         [0107]    com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer  
         [0108]    public interface Observer  
         [0109]    This is the interface as presented in the GoF Observer pattern.  
         [0110]    Operation Detail  
         [0111]    update  
         [0112]    public abstract void update( )  
         [0113]    [0113]FIG. 3 is a diagram of a use-case description in UML of one embodiment of the presently claimed system. The Presentation Services Framework  300  provides web access to the ICS system. All web-based user requests to the ICS system will enter through the Presentation Services Framework. These requests will be sent to the correct framework for further processing and the results will be displayed to the user.  
         [0114]    In what follows in the use-case description, system actors are shown vis-à-vis process objects and their pre-conditions, flow of events—including one or more scenarios—are given. It will be appreciated that the flow of events represents a flowchart of events and processing for the various process objects.  
         [0115]    System Use Case—Process Request And Generate UI  
         [0116]    The Presentation Services Framework  300  generates a user interface based on a request from a user (e.g. PLMN Operator  302 , Corporate Operator  304 , C-GSM Subscriber  306  and the like). This interface could be an HTML page, an applet, or any another form of user interface. When the UI is displayed, the user could have several options to choose from. Based on the option selected, the Presentation Services Framework  300  processes the request, send requests to other frameworks when required, and display the results to the user. Input data could be validated ( 332 ) and may be formatted for certain scenarios of this use case.  
         [0117]    System Actors  
         [0118]    Primary: PLMN Operator  302   
         [0119]    Primary: Corporate Operator  304   
         [0120]    Primary: C-GSM Subscriber  306   
         [0121]    Secondary: OAMP Manager Framework  310   
         [0122]    Secondary: Application Processing Framework  314   
         [0123]    Secondary: XML Processing Framework  312   
         [0124]    Pre-conditions  
         [0125]    The user navigates to the interface that provides access to the ICS feature they wish to use.  
         [0126]    Flow of Events  
         [0127]    Scenario: Basic Flow  
         [0128]    1. The user shall enter appropriate data and submit the request.  
         [0129]    2. The system shall collect the data from the request.  
         [0130]    3. The “Validate data” use case will be executed.  
         [0131]    4. If the previous step is successful, the data may be formatted into an XML string or some other suitable structure.  
         [0132]    5. If the previous step is not successful, an error screen shall be displayed and the user will have the option of correcting the error, and steps 2-4 will be executed again.  
         [0133]    6. The request data shall be submitted to the appropriate framework for application processing.  
         [0134]    7. The results of the request shall be returned to the system, and an appropriate screen will be displayed. This screen may be a success message, a request for further information or an error condition.  
         [0135]    Scenario: Provide user interfaces for Operations, Administration, Maintenance and Provisioning (OAMP)  
         [0136]    The following scenario describes the features of OAMP for ICS and the list of user interface required based upon the requirements of the ICS system:  
         [0137]    Configuration Management and State Management  
         [0138]    This deals with the collection of data to perform system provisioning and configuration operations for a subsystem. This includes the presentation of user interfaces for the creation, deletion, modification and viewing of subsystem managed object provisioning and configuration data.  
         [0139]    Add Subsystem (Network Element)  
         [0140]    Remove Subsystem (Network Element)  
         [0141]    Modify Subsystem Network Element)  
         [0142]    View Subsystem (Network Element)  
         [0143]    Shutdown Subsystem (Network Element)  
         [0144]    Software Management  
         [0145]    This deals with the collection of data to perform software configuration and management operations for a subsystem. This includes the presentation of user interfaces for specifying the target subsystem of the software upload, download or activation operation, the software component to be uploaded, downloaded, or activated.  
         [0146]    Download Software  
         [0147]    Upload Software  
         [0148]    Activate Software  
         [0149]    Activate Software (Network Element)  
         [0150]    Deactivate Software (Network Element)  
         [0151]    Fault Management  
         [0152]    This deals with the collection of data to view and manage system alarms. This includes the presentation of user interfaces for setting the filters for alarms to be viewed.  
         [0153]    Display List of Alarms  
         [0154]    View Alarm  
         [0155]    Filter Alarms  
         [0156]    Clear Alarm  
         [0157]    Acknowledge Alarm  
         [0158]    Terminate Alarm  
         [0159]    Scenario: Provide User Interfaces for Subscriber Provisioning  
         [0160]    The following scenario describes the features of subscriber provisioning for ICS and the list of user interface required based upon the requirements of the ICS system:  
         [0161]    Subscriber Database Management  
         [0162]    This deals with the collection of data to perform operations on the subscriber database. The subscriber database could be comprised of several different data sources (an ICS repository, the SLR, TWS, etc.), but to this system it might appear as a single data source. All intelligence for data routing and type and location of physical storage could be provided by other frameworks within the Service Engine. Subscriber database management includes the presentation of user interfaces for creation, deletion, backup, restoration, upload, download and bulk upload of the subscriber database.  
         [0163]    Create Subscriber Database  
         [0164]    Delete Subscriber Database  
         [0165]    Backup Subscriber Database  
         [0166]    Schedule Subscriber Database Backup  
         [0167]    Restore Subscriber Database  
         [0168]    Upload Subscriber Database  
         [0169]    Download Subscriber Database  
         [0170]    Bulk Upload Data to Subscriber Database  
         [0171]    C-GSM Subscriber Provisioning  
         [0172]    This deals with the collection of data to perform provisioning and configuration operations for a C-GSM Subscriber. This includes C-GSM Subscriber profile information. C-GSM Subscriber provisioning includes the presentation of user interfaces for adding, deleting, modifying, viewing and activation of subscriber provisioning and configuration data.  
         [0173]    Add New Subscriber  
         [0174]    Modify Subscriber  
         [0175]    View Subscriber  
         [0176]    Delete Subscriber  
         [0177]    Activate Subscriber  
         [0178]    ICS Profile Management  
         [0179]    This deals with the collection of data to perform ICS profile operations for a C-GSM Subscriber. This includes the presentation of user interfaces for managing message &amp; email alert filters and changing passwords.  
         [0180]    Manage Message Notification Filters  
         [0181]    Manage E-mail Notification Filters  
         [0182]    Change Password  
         [0183]    Scenario: Provide Instant Messaging User Interface  
         [0184]    The system requests the Application Processing Framework  314  to provide a list of valid C-GSM subscribers for the user to select from. The Application Processing Framework  314  also provides a list of ‘groups’, a user&#39;s pre-defined subset of C-GSM Subscribers.  
         [0185]    The system shall present an ICS instant message-editing screen with the list of valid C-GSM Subscribers and the user&#39;s groups. When the request has been submitted, the system shall collect the message text and the entries from the ‘to’ list and submit the request to the Application Processing Framework  314 . The system shall present a screen displaying a “message submitted” message to the user, or if the Application Processing Framework is unavailable, the system shall present a screen displaying an error message.  
         [0186]    Post-conditions  
         [0187]    The system requested an action be performed based on the user&#39;s request and has displayed a screen with the result of the user&#39;s request.  
         [0188]    Related Use Cases  
         [0189]    Include: Validate data  332   
         [0190]    Extend: Create XML from data  326   
         [0191]    Extend: Request ICS session  322   
         [0192]    Extend: Request ICS session information  324   
         [0193]    Extend: Subscribe to events  328   
         [0194]    System Use Case: Validate Data  
         [0195]    The Presentation Services Framework provides basic data validation. This might include field type checking (such as phone number formatting, numeric fields, etc.). Application data validation, such as range checking and text field value checking, could be done in other frameworks.  
         [0196]    Related Use Cases  
         [0197]    Included by: Process request and generate UI  320   
         [0198]    System Use Case: Request ICS Session  
         [0199]    When a user logs into the ICS system using a web browser, they require an ICS session. The Session Framework provides this ICS session. The reference to this session could be requested and stored in the Presentation Services Framework.  
         [0200]    System Actors  
         [0201]    Primary: C-GSM Subscriber  306   
         [0202]    Primary: PLMN Operator  302   
         [0203]    Primary: Corporate Operator  304   
         [0204]    Secondary: Session Framework  316   
         [0205]    Pre-conditions  
         [0206]    The user has submitted the initial userid/password combination to login to the ICS system.  
         [0207]    Flow of Events  
         [0208]    Scenario: Basic flow  
         [0209]    1. The system reads in the userid and password from the login request.  
         [0210]    2. A request for an ICS Session is sent to the Session Framework with the userid and password.  
         [0211]    3. If the request is successful (the userid/password combination is valid), the Session Framework returns a reference to the ICS session which will be saved in the HTTP session.  
         [0212]    4. If the request returns null, an error screen is generated to provide the user the option to either retype their userid/password combination or a link to an initial profile setup.  
         [0213]    Post-conditions  
         [0214]    The user has logged into the ICS system, or has been presented an option to create a login profile.  
         [0215]    Related Use Cases  
         [0216]    Extends: Process request and generate UI  320   
         [0217]    System Use Case: Request ICS Session Information  
         [0218]    Once a user has logged on to the ICS system, an ICS session object is created and a reference to it is stored in the Presentation Services Framework. This reference can then be used to access role and privilege information about the user, as well as information about the session itself.  
         [0219]    System Actors  
         [0220]    Primary: C-GSM Subscriber  306   
         [0221]    Primary: PLMN Operator  302   
         [0222]    Primary: Corporate Operator  304   
         [0223]    Secondary: Session Framework  316   
         [0224]    System Objects  
         [0225]    Pre-conditions  
         [0226]    The user has logged into the ICS system and a valid ICS session exists for this user.  
         [0227]    Flow of Events  
         [0228]    Scenario: Basic flow  
         [0229]    1. A request is sent to the Session Framework for the information about the session (such as role, timeout information, etc.).  
         [0230]    2. This information is returned to the Presentation Services Framework for use in processing requests.  
         [0231]    Post-conditions  
         [0232]    The Presentation Services Framework has the requested information.  
         [0233]    Related Use Cases  
         [0234]    Extends: Process request and generate UI  320   
         [0235]    System Use Case: Create XML From Input Data  
         [0236]    The data collected from the user interface is converted into an XML format before it is sent to another framework for processing. The Presentation Services Framework can do this conversion based on an agreed-upon XML format (such as an XML DTD or schema or the like).  
         [0237]    Related Use Cases  
         [0238]    Extends: Process request and generate UI  320   
         [0239]    System Use Case: Subscribe To Events  
         [0240]    In order for events to be displayed to the user, the web-based UI requests a subscription to events of interest.  
         [0241]    System Actors  
         [0242]    Primary: C-GSM Subscriber  306   
         [0243]    Primary: PLMN Operator  302   
         [0244]    Primary: Corporate Operator  304   
         [0245]    Secondary: Event Service  308   
         [0246]    Pre-conditions  
         [0247]    The Event Service is available for subscriptions.  
         [0248]    A user has submitted a request to receive notifications of events.  
         [0249]    Flow of Events  
         [0250]    Scenario: Basic Flow  
         [0251]    1. The system subscribes to the channel of the Event Service that is publishing the events of interest.  
         [0252]    Post-conditions  
         [0253]    The web-based UIs interested in certain events have been registered to receive event notifications.  
         [0254]    Related Use Cases  
         [0255]    Extends: Process request and generate UI  320   
         [0256]    System Use Case: Register Services With Name Service  
         [0257]    At system start-up, or any time after the Presentation Services Framework or one of its services has been unavailable, the Presentation Services Framework&#39;s services shall be registered with the name service.  
         [0258]    System Use Case: Process Event Notification  
         [0259]    When an event is published by the Event Service that is of the type the Presentation Services Framework has subscribed to, the notification is received by the Presentation Services Framework and is distributed to the interested web-based UIs for display to the user.  
         [0260]    System Actors  
         [0261]    Primary: Event Service  
         [0262]    Secondary: PLMN Operator  
         [0263]    Secondary: Corporate Operator  
         [0264]    Pre-conditions  
         [0265]    The “Subscribe to events” use case has been successfully executed for the event type of interest.  
         [0266]    An event has been generated by the system and has been published by the Event Service.  
         [0267]    Flow of Events  
         [0268]    Scenario: Basic Flow  
         [0269]    1. The system receives the event notification.  
         [0270]    2. The system delivers this notification to every web-based UI that has requested this form of notification.  
         [0271]    Post-conditions  
         [0272]    The web-based UIs interested in a type of event have received the notification.  
         [0273]    It has now been described a novel system and method for the creation of new user interfaces for an integrated communications server on a private network. It will be appreciated that the foregoing description of several embodiments are illustrative of the principles of the present invention and that the scope of the present invention should not be limited to the recitation of such embodiments. Additionally, the scope of the present invention contemplates all obvious extensions of the foregoing embodiments.