US20030060228A1

US20030060228A1 - Presentation services software development system and methods

Info

Publication number: US20030060228A1
Application number: US09/965,475
Authority: US
Inventors: Karen Capers; Laura Wiggett
Original assignee: Siemens Information and Communication Mobile LLC
Current assignee: Siemens Communications Inc
Priority date: 2001-09-26
Filing date: 2001-09-26
Publication date: 2003-03-27

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

The following related cases are co-pending, co-owned patent applications—herein incorporated by reference—filed on even date as the present application: [0001]
Ser. No. ______ entitled “OBJECT COMMUNICATION SERVICES SOFTWARE DEVELOPMENT SYSTEM AND METHODS” to Karen Capers and Peter Alvin. [0002]
Ser. No. _______ entitled “INTEGRATED DIAGNOSTIC CENTER” to Karen Capers and Michael Brooking.[0003]

BACKGROUND OF THE INVENTION

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.

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.

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.

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

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

FIG. 1 is a typical embodiment of an OLMN architecture. [0009]
FIG. 2 is a diagram of the structural and functional components of an embodiment made in accordance with the principles of the present invention. [0010]
FIG. 3 is use-case diagram of an embodiment of the presentation services framework made in accordance with the principles of the present invention.[0011]

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 depicts a typical architecture of an Office Land Mobile Network (e.g. Corporate GSM or “C-GSM”)—illustrating a [0012] 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.
The [0013] 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.
Authorized [0014] 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.
The WARP [0015] 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.
The [0016] 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.
The ICS [0017] 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.
Each of the [0018] 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.
The [0019] 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.
The [0020] 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.
The [0021] 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.
The [0022] 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.
The [0023] 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.
The [0024] 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.
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. [0025]
Structural Components [0026]
Presentation Services System (or Framework) [0027] 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's session will be established by the session framework and used by the Presentation Services System for displaying a user's view of the system, based on the user'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.
The interface to [0029] httpSession component 202 is as follows:
public interface ImanageHttpSession [0030]
IManageHttpSession is supported by the httpSession component. It provides access to HTTP session handling. [0031]
The [0032] 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.
The interface of [0033] presentationEngine component 204 is as follows:
public interface IHttp [0034]
This interface serves as a logical entry point for all ICS system web-based access (e.g. HTTP access). [0035]
The presentationLogic component [0036] 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.
The presentationLogic component [0037] 206 comprises two Class Nodes:
com.opuswave.ics.serviceEngine.presentationServices.presentationLogic.LoginAction [0038]
com.opuswave.ics.serviceEngine.presentationServices.presentationLogic.LoginForm [0039]
The class node “LogicAction” is described by: [0040]
public class LoginAction [0041]
Extends: [0042]
org.apache.struts.action.Action [0043]
This Action bean will perform the login handling. [0044]
Operation Detail [0045]
authenticateUser [0046]
public String authenticateUser(String userid, String password) [0047]
This method is pulled out of the perform method in order for the [0048] CLI 208 to use this class.
perform [0049]
public ActionForward perform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) [0050]
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”. [0051]
The class node “LoginForm” is described by: [0052]
public class LoginForm [0053]
Extends: [0054]
org.apache.struts.action.ActionForm [0055]
The LoginForm will perform data gathering and validation of login information. [0056]
Attribute Detail [0057]
password [0058]
private String password [0059]
userid [0060]
private String userid [0061]
Operation Detail [0062]
getPassword [0063]
public String getpassword( ) [0064]
getuserid [0065]
public String getuserid( ) [0066]
setPassword [0067]
public void setPassword(String password) [0068]
setUserid [0069]
public void setUserid(String userid) [0070]
validate [0071]
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) [0072]
Interface Detail [0073]
Interface [0074]
public interface IServiceRequest [0075]
This interface allows the [0076] presentationEngine component 204 to pass service requests to the presentationLogic component 206 for validation and application processing.
The [0077] 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.
Class Nodes [0078]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.AlarmObserver [0079]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.AlarmSubscriber [0080]
Interface Nodes [0081]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.IClientSubscribe [0082]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer [0083]
Class Detail [0084]
AlarmObserver Class [0085]
public class AlarmObserver [0086]
Implements: [0087]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer [0088]
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's update( ) method will be called when an alarm is generated by the OAMPManager. [0089]
Operation Detail [0090]
update [0091]
public void update( ) [0092]
Class [0093]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.AlarmSubscriber [0094]
public class AlarmSubscriber [0095]
Implements: [0096]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.IClientSubscribe [0097]
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. [0098]
Interface Detail [0099]
Interface [0100]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.IClientSubscribe [0101]
public interface IClientSubscribe [0102]
This interface allows the presentationLogic component to subscribe and receive events through the subscriptionEngine component. [0103]
Class [0104]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer [0105]
Interface [0106]
com.opuswave.ics.serviceEngine.presentationServices.subscriptionEngine.Observer [0107]
public interface Observer [0108]
This is the interface as presented in the GoF Observer pattern. [0109]
Operation Detail [0110]
update [0111]
public abstract void update( ) [0112]
FIG. 3 is a diagram of a use-case description in UML of one embodiment of the presently claimed system. The [0113] 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.
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. [0114]
System Use Case—Process Request And Generate UI [0115]
The [0116] 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.
System Actors [0117]
Primary: [0118] PLMN Operator 302
Primary: [0119] Corporate Operator 304
Primary: C-[0120] GSM Subscriber 306
Secondary: [0121] OAMP Manager Framework 310
Secondary: [0122] Application Processing Framework 314
Secondary: [0123] XML Processing Framework 312
Pre-conditions [0124]
The user navigates to the interface that provides access to the ICS feature they wish to use. [0125]
Flow of Events [0126]
Scenario: Basic Flow [0127]
1. The user shall enter appropriate data and submit the request. [0128]
2. The system shall collect the data from the request. [0129]
3. The “Validate data” use case will be executed. [0130]
4. If the previous step is successful, the data may be formatted into an XML string or some other suitable structure. [0131]
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. [0132]
6. The request data shall be submitted to the appropriate framework for application processing. [0133]
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. [0134]
Scenario: Provide user interfaces for Operations, Administration, Maintenance and Provisioning (OAMP) [0135]
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: [0136]
Configuration Management and State Management [0137]
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. [0138]
Add Subsystem (Network Element) [0139]
Remove Subsystem (Network Element) [0140]
Modify Subsystem Network Element) [0141]
View Subsystem (Network Element) [0142]
Shutdown Subsystem (Network Element) [0143]
Software Management [0144]
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. [0145]
Download Software [0146]
Upload Software [0147]
Activate Software [0148]
Activate Software (Network Element) [0149]
Deactivate Software (Network Element) [0150]
Fault Management [0151]
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. [0152]
Display List of Alarms [0153]
View Alarm [0154]
Filter Alarms [0155]
Clear Alarm [0156]
Acknowledge Alarm [0157]
Terminate Alarm [0158]
Scenario: Provide User Interfaces for Subscriber Provisioning [0159]
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: [0160]
Subscriber Database Management [0161]
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. [0162]
Create Subscriber Database [0163]
Delete Subscriber Database [0164]
Backup Subscriber Database [0165]
Schedule Subscriber Database Backup [0166]
Restore Subscriber Database [0167]
Upload Subscriber Database [0168]
Download Subscriber Database [0169]
Bulk Upload Data to Subscriber Database [0170]
C-GSM Subscriber Provisioning [0171]
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. [0172]
Add New Subscriber [0173]
Modify Subscriber [0174]
View Subscriber [0175]
Delete Subscriber [0176]
Activate Subscriber [0177]
ICS Profile Management [0178]
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 & email alert filters and changing passwords. [0179]
Manage Message Notification Filters [0180]
Manage E-mail Notification Filters [0181]
Change Password [0182]
Scenario: Provide Instant Messaging User Interface [0183]
The system requests the [0184] 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's pre-defined subset of C-GSM Subscribers.
The system shall present an ICS instant message-editing screen with the list of valid C-GSM Subscribers and the user'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 [0185] 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.
Post-conditions [0186]
The system requested an action be performed based on the user's request and has displayed a screen with the result of the user's request. [0187]
Related Use Cases [0188]
Include: Validate [0189] data 332
Extend: Create XML from [0190] data 326
Extend: [0191] Request ICS session 322
Extend: Request [0192] ICS session information 324
Extend: Subscribe to [0193] events 328
System Use Case: Validate Data [0194]
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. [0195]
Related Use Cases [0196]
Included by: Process request and generate [0197] UI 320
System Use Case: Request ICS Session [0198]
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. [0199]
System Actors [0200]
Primary: C-[0201] GSM Subscriber 306
Primary: [0202] PLMN Operator 302
Primary: [0203] Corporate Operator 304
Secondary: [0204] Session Framework 316
Pre-conditions [0205]
The user has submitted the initial userid/password combination to login to the ICS system. [0206]
Flow of Events [0207]
Scenario: Basic flow [0208]
1. The system reads in the userid and password from the login request. [0209]
2. A request for an ICS Session is sent to the Session Framework with the userid and password. [0210]
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. [0211]
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. [0212]
Post-conditions [0213]
The user has logged into the ICS system, or has been presented an option to create a login profile. [0214]
Related Use Cases [0215]
Extends: Process request and generate [0216] UI 320
System Use Case: Request ICS Session Information [0217]
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. [0218]
System Actors [0219]
Primary: C-[0220] GSM Subscriber 306
Primary: [0221] PLMN Operator 302
Primary: [0222] Corporate Operator 304
Secondary: [0223] Session Framework 316
System Objects [0224]
Pre-conditions [0225]
The user has logged into the ICS system and a valid ICS session exists for this user. [0226]
Flow of Events [0227]
Scenario: Basic flow [0228]
1. A request is sent to the Session Framework for the information about the session (such as role, timeout information, etc.). [0229]
2. This information is returned to the Presentation Services Framework for use in processing requests. [0230]
Post-conditions [0231]
The Presentation Services Framework has the requested information. [0232]
Related Use Cases [0233]
Extends: Process request and generate [0234] UI 320
System Use Case: Create XML From Input Data [0235]
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). [0236]
Related Use Cases [0237]
Extends: Process request and generate [0238] UI 320
System Use Case: Subscribe To Events [0239]
In order for events to be displayed to the user, the web-based UI requests a subscription to events of interest. [0240]
System Actors [0241]
Primary: C-[0242] GSM Subscriber 306
Primary: [0243] PLMN Operator 302
Primary: [0244] Corporate Operator 304
Secondary: [0245] Event Service 308
Pre-conditions [0246]
The Event Service is available for subscriptions. [0247]
A user has submitted a request to receive notifications of events. [0248]
Flow of Events [0249]
Scenario: Basic Flow [0250]
1. The system subscribes to the channel of the Event Service that is publishing the events of interest. [0251]
Post-conditions [0252]
The web-based UIs interested in certain events have been registered to receive event notifications. [0253]
Related Use Cases [0254]
Extends: Process request and generate [0255] UI 320
System Use Case: Register Services With Name Service [0256]
At system start-up, or any time after the Presentation Services Framework or one of its services has been unavailable, the Presentation Services Framework's services shall be registered with the name service. [0257]
System Use Case: Process Event Notification [0258]
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. [0259]
System Actors [0260]
Primary: Event Service [0261]
Secondary: PLMN Operator [0262]
Secondary: Corporate Operator [0263]
Pre-conditions [0264]
The “Subscribe to events” use case has been successfully executed for the event type of interest. [0265]
An event has been generated by the system and has been published by the Event Service. [0266]
Flow of Events [0267]
Scenario: Basic Flow [0268]
1. The system receives the event notification. [0269]
2. The system delivers this notification to every web-based UI that has requested this form of notification. [0270]
Post-conditions [0271]
The web-based UIs interested in a type of event have received the notification. [0272]
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. [0273]

Claims

1. In an office land mobile network (OLMN) system, a method for creating user interfaces for a plurality of users of said OLMN, the steps of said method comprising:

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.

2. The method as recited in claim 1 wherein one of said plurality of users making service requests is a PLMN operator.

3. The method as recited in claim 1 wherein one of said plurality of users making service requests is a corporate operator.

4. The method as recited in claim 1 wherein one of said plurality of users making service requests is a OLMN subscriber.

5. The method as recited in claim 1 wherein said internal format comprises extensible markup language.

6. The method as recited in claim 1 wherein said request is made for OAMP services; and

further wherein said data pertains to system provisioning for a subsystem of said OLMN.

7. The method as recited in claim 6 wherein said step of returning a user interface further comprises returning a user interface appropriate for operations upon subsystem managed objects.

8. The method as recited in claim 7 wherein said operations comprises a group, said group further comprising one of creation, deletion, modification and viewing said objects.

9. The method as recited in claim 6 wherein said system provisioning data comprises data for software configuration for a subsystem.

10. The method as recited in claim 9 wherein said data for software configuration further comprises data for one of a group, said group further comprising download, upload, activate, and deactivate software.

11. The method as recited in claim 6 wherein said system provisioning data comprises data for subscriber provisioning.

12. The method as recited in claim 11 wherein said data for subscriber provisioning further comprises data for one of a group, said group further comprising create, delete, backup, schedule, restore, upload, download, and bulk upload subscriber database.

13. The method as recited in claim 11 wherein said subscriber provisioning data comprises further comprises data for one of a group, said group further comprising add, modify, view, delete, and activate subscriber.

14. The method as recited in claim 1 further comprising the steps:

requesting a list of valid subscribers;

presenting an instant messaging screen comprising said list of valid subscribers to said user;

collecting message text and subscriber selection from said user;

submitting said instant message request to an appropriate framework.

15. The method as recited in claim 1 wherein the step of receiving a request from a user further comprises:

receiving a request to logon to said OLMN system;

sending said request to logon to an appropriate framework; and

if said logon request is valid, return a reference to new session for said user.

16. The method as recited in claim 1 further comprising:

subscribing to one or more events;

displaying to said user said one or more event; and

delivering to said user notification of said one or more events.

17. A OLMN system comprising:

one or more subscribed users of said system;

an integrated communications server; wherein said users submit requests for services;

a presentation services framework, said framework receiving said requests from said users; formatting said requests from users; forwarding said requests to appropriate frameworks for further processing; and presenting an appropriate user interface to said user.

18. The OLMN system as recited in claim 17 wherein said one of more subscribed user comprises a PLMN operator.

19. The OLMN system as recited in claim 17 wherein said one of more subscribed user comprises a corporate operator.

20. The OLMN system as recited in claim 17 wherein said one of more subscribed user comprises a OLMN subscriber.

21. A system for creating user interfaces for a plurality of users of an OLMN, comprising:

a computer-processable medium; and

logic stored on the computer-processable medium, the logic operable to receive a request from said user for service from said OLMN, said request comprising data pertaining to said service; to validate said data received from said request; if said data is valid for said request, to format said data into an internal format; to submit said formatted request to an appropriate framework for application processing; and to return a user interface, said user interface being appropriate for the particular request received.