Application server configured for dynamically generating web forms based on extensible markup language documents and retrieved subscriber data

[0001] 1. Field of the Invention

[0002] The present invention relates to dynamic generation of a hypertext markup language (HTML) form by an application server configured for executing applications based on extensible markup language documents.

[0003] 2. Description of the Related Art

[0004] An open standards-based Internet protocol (IP) network, such as the World Wide Web, the Internet, or a corporate intranet, provides client-server type application services for clients by enabling the clients to request application services from remote servers using standardized protocols, for example hypertext transport protocol (HTTP). The web server application environment can include web server software, such as Apache, implemented on a computer system attached to the IP network. Web-based applications are composed of HTML pages, logic, and database functions accessible by a Common Gateway Interface (CGI) script. In addition, the web server may provide logging and monitoring capabilities.

[0005] Typically web applications display HTML forms in the form of static HTML pages from stored HTML files, alternately the HTML pages are generated dynamically using CGI scripts. In both these cases it becomes difficult to customize HTML forms because such customization requires either modifying the stored HTML files or modifying the CGI script code.

[0006] Commonly-assigned, copending application Ser. No. 09/480,485, filed Jan. 11, 2000, entitled Application Server Configured for Dynamically Generating Web Pages for Voice Enabled Web Applications, the disclosure of which is incorporated in its entirety herein by reference, discloses an application server that executes a voice-enabled web application by runtime execution of extensible markup language (XML) documents that define the voice-enabled web application to be executed. The application server, in response to receiving a user request from a user, accesses a selected XML page that defines at least a part of the voice application to be executed for the user. The application server then parses the XML page, and executes the operation described by the XML page, for example dynamically generating an HTML page having voice application control content, or fetching another XML page to continue application processing.

[0007] Commonly-assigned, copending application Ser. No. 09/559,637, filed Apr. 28, 2000, entitled Browser Based Arrangement for Developing Voice Enabled Web Applications Using Extensible Markup Language Documents, the disclosure of which is incorporated in its entirety herein by reference, discloses generation of an HTML document usable by a user to create or modify a stored XML document to define a voice application operation. The application server generates a prescribed HTML form and inserts selected application parameters from the XML document. The HTML form is supplied to a browser, enabling a user to input or modify application parameters for the corresponding XML document into the form. The application server, upon receiving the form from the web browser, inserts the input application parameters into the XML document, and stores the XML application document for execution.

[0008] As described previously, a primary concern is the ability to customize HTML forms. The use of customize HTML forms is particularly important in developing customizable web applications, for example self-administered user applications that enables a user to self-customize his or her web application, for example in the case of a subscriber desiring to adjust his or her settings in a unified communications system such as the commercially-available Cisco uOne system (4.1S).

[0009] There is a need for an arrangement that enables HTML forms to be customizable on a per-user basis, without the necessity of modifying static HTML files or modification of CGI scripts.

[0010] There also is a need for arrangement that enables HTML pages to be dynamically generated by an application server, on a user-specific basis, without the use of a common gateway interface that may affect the scalability of the application server.

[0011] There is also a need for an arrangement that enables an application server to dynamically generate HTML pages based on stored XML data and stored user data accessible by the application server.

[0012] These and other needs are attained by the present invention, where an application server, configured for dynamically generating a web page (e.g., HTML) document based on execution of XML documents, dynamically generates an HTML page having selected form elements based on a stored XML document that defines available HTML form elements and respective attributes, and based on user attributes retrieved by the application server from an open network database server (such as LDAP). The application server, in response to a request from a user, accesses an XML document configured for specifying attributes associated with the request; the XML document may specify as form elements menus that are available for generation based on qualified user attributes, or may specify HTML fields that can be generated for display on the HTML page based on the qualified user attributes. The application server also retrieves the user attributes, and dynamically generates the HTML page based on identifying the user attributes matching the qualified user attributes of the accessed XML document. Hence, HTML pages having form elements can be dynamically generated, providing personalized HTML pages without the necessity of modifying CGI scripts or stored HTML pages.

[0013] One aspect of the present invention provides a method in an application server. The method includes accessing a stored extensible markup language (XML) document based on receiving a web page request from a browser serving a user, the stored XML document specifying available web page form elements and respective attributes. The method also includes obtaining subscriber attribute information for the user from an Internet Protocol (IP) based database server configured for storing subscriber attributes for users, and generating a web page. The generated web page has selected form elements based on the available web page form elements specified in the stored XML document and the subscriber attribute information for the user. The accessing of the stored XML document enables an application runtime environment parsing the XML document to identify available web page form elements and the respective attributes for generation of a web page. Moreover, the access of subscriber attribute information enables the web page to be dynamically generated based on selection of form elements having attributes that satisfy prescribed conditions relative to the subscriber attribute information. Hence, a web page having user-specific menus and/or input fields can be dynamically generated within an application runtime environment, without the necessity of modifying a CGI script or a statically stored HTML document.

[0014] Another aspect of the present invention provides an application server configured for generating a web page. The application server includes HTTP interface configured for receiving a web page request from a browser serving a user and outputting to the browser a web page, and an interface configured for generating a query for subscriber attribute information for the user to an Internet protocol (IP) based database server configured for storing subscriber attributes for users. The application server also includes an application runtime environment configured for accessing a stored extensible markup language (XML) document based on the received web page request, the application runtime environment configured for generating the web page by inserting selected form elements based on available web page form elements specified within the stored XML document, and the selected form elements selected based on the subscriber attribute information.

[0015] Additional advantages and novel features of the invention will be set forth in part in the description which follows and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The advantages of the present invention may be realized and attained by means of instrumentalities and combinations particularly pointed out in the appended claims.

[0024] The disclosed embodiment is directed to the dynamic generation of HTML forms pages based on XML specifications, enabling a subscriber to customize his or her web application based on inputting or modifying a custom HTML form. In addition, HTML forms can easily be modified by modifying the XML documents describing the HTML forms. A description will first be given of the unified messaging architecture used to provide unified messaging services for subscribers, followed by a detailed description of the arrangement for dynamically generating HTML forms for self administration by unified messaging subscribers according to an embodiment of the present invention.

[0025] FIG. 1 is a block diagram illustrating an architecture that provides unified voice messaging services and data services via an IP network using browser audio control according to an embodiment of the present invention, reproduced from FIG. 3 of the above-incorporated application Ser. No. 09/480,485. The clients 42a and 42b, referred to herein as “fat clients” and “thin clients”, respectively, have the distinct advantage that they can initiate requests using IP protocol to any connected web server 64 to execute part or most of the applications 44 on behalf of the clients. An example of a fat client 42a is an e-mail application on a PC that knows how to run the application 44 and knows how to run the IP protocols to communicate directly with the messaging server via the packet switched network 50. An example of a thin client 42b is a PC that has a web browser; in this case, the web browser 56 can use IP protocols such as HTTP to receive and display web pages generated according to hypertext markup language (HTML) from server locations based on uniform resource locators (URLs) input by the user of the PC.

[0026] As shown in FIG. 1, each of the clients (tiny clients, skinny clients, thin clients and fat clients) are able to communicate via a single, unified architecture 60 that enables voice communications services between different clients, regardless of whether the client actually has browser capabilities. Hence, the fat client 42a and the thin client 42b are able to execute voice enabled web applications without any hardware modification or any modification to the actual browser; rather, the browsers 56 in the clients 42a and 42b merely are provided with an executable voice resource configured for providing browser audio control, described below.

[0027] The user devices 18a, 18b, and 18c, illustrated as a cordless telephone 18a, a fax machine 18b having an attached telephone, and an analog telephone 18c, are referred to herein as “skinny clients”, defined as devices that are able to interface with a user to provide voice and/or data services (e.g., via a modem) but cannot perform any control of the associated access subnetwork.

[0028] The wireless user devices 18d, 18e, and 18f, illustrated as a cellular telephone (e.g., AMPS, TDMA, or CDMA) 18d, a handheld computing device (e.g., a 3-Com Palm Computing or Windows CE-based handheld device) 18e, and a pager 18f, are referred to as tiny clients. “Tiny clients” are distinguishable from skinny clients in that the tiny clients tend to have even less functionality in providing input and output interaction with a user, rely exclusively on the executable application in an access subnetwork to initiate communications; in addition, tiny clients may not be able to send or receive audio signals such as voice signals at all.

[0029] Hence, the skinny clients 18a, 18b, and 18c and the tiny clients 18d, 18e, and 18f access the unified voice messaging services in the unified network 60 via a proxy browser 62, configured for providing an IP and HTTP interface for the skinny clients and the tiny clients. In particular, browsers operate by interpreting tags within a web page supplied via an HTTP connection, and presenting to a user media content information (e.g., text, graphics, streaming video, sound, etc.) based on the browser capabilities; if a browser is unable to interpret a tag, for example because the browser does not have the appropriate executable plug-in resource, then the browser typically will ignore the unknown tag. Hence, the proxy browser 62 can provide to each of the skinny clients and tiny clients the appropriate media content based on the capabilities of the corresponding client, such that the cordless telephone 18a and telephone 18c would receive analog audio signals played by the proxy browser 62 and no text information (unless a display is available); the fax machine 18b and pager 18f would only receive data/text information, and the cellular telephone 18d and the handheld computing device 18e would receive both voice and data information. Hence, the proxy browser 62 interfaces between the IP network and the respective local access devices for the skinny clients and the tiny clients to provide access to the unified messaging network 60.

[0030] The proxy browser 62 and the web browsers 56 within the fat client 42a and the thin client 42b execute voice enabled web applications by sending data and requests to a web server 64, and receiving hypertext markup language (HTML) web pages from the web server 64, according to hypertext transport protocol (HTTP). The web server 64 serves as an interface between the browsers and an application server 66 that provides an executable runtime environment for XML voice applications. The application server 66, in response to receiving a request from the web server 64, may either supply the requested information in the form of an HTML page having XML tags for audio control by a voice resource within the browser, or may perform processing and return a calculated value to enable the browser 56 or 62 to perform additional processing.

[0031] The application server 66 accesses selected stored XML application pages (i.e., XML pages that define an application) and in response generates new HTML pages having XML tags during runtime and supply the generated HTML pages having XML tags to the web server 64. Since multiple transactions may need to occur between the browser 56 or 62 and the application server 66, the application server 66 is configured for storing for each existing user session a data record, referred to as a “brownie”, that identifies the state of the existing user session; hence, the application server 66 can instantiate a procedure, return the necessary data, and terminate the procedure without the necessity of maintaining the instance running throughout the entire user session.

[0032] Hence, the application server 66 executes voice application operations from a stored XML document based on a transient application state, where the application server 66 terminates the application instance after outputting the generated XML media information to the browser 18 or 42.

[0033] FIG. 2 is a diagram illustrating in further detail the interaction between the application server 66 and a browser 42c receiving an HTML page 10 during a self-administered subscriber provisioning session. In particular, the above description with respect to the browsers 42a and 42b and the application server 66 contemplate generation of an HTML web page 12 having XML control tags 14 for control of media content, for example during a messaging session with a subscriber. In contrast, the self-administered subscriber provisioning session described below provides a web-based tool that enables administrators to provision new services having respective configuration settings, or new accounts, within a subscriber directory server, for example an LDAP server, or a messaging server such as an IMAP message store. The self-administered subscriber provisioning session also provides a web-based tool that enables subscribers to change their personal settings and modify their subscriber profiles stored in the subscriber directory server.

[0034] The HTML pages 10 generated by the application server 66 and supplied to the browser 42c include form elements that enable the user to self-administer subscriber profile information for establishment and maintenance of the unified messaging service. A “form element” is defined as an element of a displayed web page that enables a user to post a corresponding request that affects access or storage of subscriber profile information. For example, the application server 66 may generate an HTML document 10a having selected form elements, implemented as menu elements 16 for a user menu 24, that enable a user to request retrieval of specific profile information such as attendant call coverage 16a, telephone access password 16b, e-mail access password 16c, or message playback preferences 16d. The menu 24 also may be displayed as a pull-down menu. Alternately the application server 66 may generate an HTML document 10b having selected form elements, implemented as HTML form fields 20 having respective input form elements 22, enabling the user to review, edit, and post the revised subscriber profile settings for storage in the subscriber profile directory 88.

[0035] As described below, the menu elements 16 are selected for dynamic generation of the web page 10a based on the user privileges, enabling the application server 66 to dynamically generate different user menus 24 depending on whether the user is an administrator, a user, etc. Similarly, the HTML form fields 20 are selected for dynamic generation of the web page 10b based on identification of relevant subscriber attributes between an XML document 30, used to specify the available form fields, and the retrieved subscriber profile information for the user.

[0036] Hence, the application server 66 is able to provide a personalized menu 24 of available operations that a subscriber may use during self-administration. Upon selecting a menu element 16, the browser 42c posts an HTTP request that specifies the requested operation, for example another submenu, or a dynamically generated HTML form page 10b.

[0037] FIG. 3 is a diagram illustrating in further detail the application server 66. One exemplary implementation of the application server 66 is the commercially-available Cisco Unified Open Network Exchange (Cisco uOne) (Products UONE-FOUND 4.1S, and UONE-VOICEMSG4.1S) including the uPower web-based administration tools from Cisco Systems, Inc. As described below, the disclosed embodiment provides an improvement to the existing uPower web-based administration tools by providing dynamically generated HTML documents.

[0038] The application server 66 receives via the web server 64 HTTP requests from either a PC-based web browser 42 capable of supplying full media content (e.g., audio, text, images, and streaming video), or a proxy browser 62 configured for serving as an HTTP interface for a user input device, such as a telephone 18, having limited media capabilities (e.g., audio only). In response to receiving the HTTP requests, the application server 66 accesses a selected XML document based on parameters specified within the HTTP request (e.g., commands specified within the URL), and based on application state determined from accessing a brownie, assuming the HTTP request specifies a valid session identifier. As described below, the application runtime environment within the application server 66 parses the XML tags within the accessed XML document, and dynamically generates an HTML page having selected form elements based on the available web page form elements specified in the stored XML document, and the subscriber attribute information retrieved for a corresponding subscriber.

[0039] The voice application server 66 is configured for accessing service application programming interfaces (API's) 82 to external resources based on prescribed procedures that may be called during parsing of an XML tags in a selected XML document. As described below, the application server 66 issues function calls to an API 82 for accessing the external resources for prescribed operations, enabling the deployment of a robust, scalable unified messaging system having messaging operations distributed across multiple platforms. In particular, the application server 66 accesses subscriber profile information from an IP-based database server 84 according to LDAP protocol. The application server 66 also is configured for storing and retrieving messages in a standardized format (e.g., e-mail with binary encoded attachments) in an IMAP messaging server 86 during messaging sessions.

[0040] The application server 66 is implemented as a server executing a PHP hypertext processor with XML parsing and processing capabilities, available open source on the Internet at http://www.php.net. As shown in FIG. 3, the server system 66 includes an XML parser 94 configured for parsing the application-defining XML documents stored in the XML document database 72, or the XML documents (i.e., “brownies”) stored in the registry 92 and configured for specifying the state and attributes for respective user sessions. The application server 66 also includes a high speed interface 96 that establishes a high-speed connection between the application server 66 and the web server 64. For example, the PHP hypertext processor includes a high-speed interface for Apache Web servers.

[0041] The application server 66 also includes a runtime environment 100 for execution of the parsed XML documents. As described above, the runtime environment 100 may selectively execute any one of user interface operation 98, a logic operation 102, or a procedure call 104 as specified by the parsed XML document by executing a corresponding set of executable functions based on the rule set for the corresponding operation. In particular, the application runtime environment 100 includes a tag implementation module 110 that implements the XML tags parsed by the XML parser 94. The tag implementation module 110 performs relatively low-level operations, for example dynamically generating an XML menu page using executable functions specified by a menu rule set in response to detecting a menu tag, performing a logical operation using executable functions specified by a logic rule set in response to a decision tag, or fetching an audio (.wav) file in response to detecting a sound tag. Hence, the tag implementation module 110 implements the tag operations that are specified within the XML framework of the stored XML documents.

[0042] The application server 66 also includes a set of libraries 82 that may be implemented as dynamically linked libraries (DLLs) or application programming interface (API) libraries. The libraries 82 enable the runtime environment 100 to implement the procedures 104 as specified by the appropriate XML document. For example, the application server 66 may issue a function call to one of a plurality of IP protocol compliant remote resources 86, 88, or 106 according to IMAP protocol, LDAP Protocol, or SMTP protocol, respectively. For example, the PHP hypertext processor includes executable routines capable of accessing the IMAP or LDAP services. Note that the mechanisms for accessing the services 86, 88, or 106 should be established within the application server before use of XML documents that reference those services. Once the services 86, 88, or 106 are established, the application runtime environment 100 can perform a function operation by using executable functions specified by a function call rule set.

[0043] FIGS. 4A and 4B are diagrams illustrating self-provisioning operations executed by the application server 66 for dynamic generation of web pages 10 according to an embodiment of the present invention. The steps described in FIGS. 4A and 4B can be implemented as executable code stored on a computer readable medium (e.g., a hard disk drive, a floppy drive, a random access memory, a read only memory, an EPROM, a compact disc, etc.).

[0044] As shown in FIG. 4A, the method begins in step 200 by the application server 66 receiving from the browser 42c a subscriber login request for self administration, for example by posting to a prescribed uniform resource locator (URL). The application server retrieves in step 202 the subscriber profile information (set to default values for new users) from the LDAP directory 88 and locally stores the subscriber profile information, for example in a locally stored XML document.

[0045] The application server 66 retrieves in step 204 a top-level menu XML document 30a, illustrated in FIG. 5, and parses the menu XML document 30a to identify available menu elements to be selected as menu elements 16. In particular, the XML elements 300a, 300b, and 300c specify attributes for a top-level menu “Subscriber Provisioning” 302a, and sub-menu elements “Add Subscriber” 304a and “Add Message Notification Information” 304b, respectively. The sub menu elements 304 each specify a parent attribute 306 that identifies the parent menu 302, and a locator 308 that specifies another XML document to be accessed if the corresponding menu element is selected by the user.

[0046] The application server 66 retrieves in step 206 a menu rules XML document 30b, illustrated in FIG. 6, and parses for menu element rules 310 in order to compare a qualified user attribute 312 for a specified menu element 316 to a prescribed value 314. For example, the rule 310a specifies that the generation of the menu element 302a identified as “Subscriber Provisioning” by the name attribute 316 requires that the qualified user attribute 312a, identified within the LDAP directory as “xamtevatitle”, must have a value of “admin” as specified by the value tag 314a; hence, the rules 310a, 310b, 310c each require that the user be identified as an administrator for generation of the respective menu elements “Subscriber Provisioning”, “Class of Service” (COS), and “Global Administration”, respectively. In contrast, the rules 310e, 310f, 310g, and 310f each require that the user be identified as other than an administrator (e.g., messaging subscriber) for generation of the respective menu elements “Preferences”, “Reach Numbers”, “Message Notification”, and “Distribution Lists”, respectively.

[0047] Hence, the application server 66 initiates dynamic generation of an HTML page 10a having a menu 24 composed of menu elements 16 by determining in step 208 if the subscriber attribute information retrieved from the LDAP directory includes a subscriber attribute that matches a qualified user attribute 312 for the web page menu element 16; if there is a matching attribute, the application server 66 determines in step 210 whether the appropriate menu rule 310 is satisfied. If the appropriate menu rule is satisfied in step 210, the application server 66 adds in step 212 the menu element 16 specified by the corresponding XML element 300 and the corresponding locator 308. If certain menu elements are to be supplied to all users, then the menu rules XML document 30b need not specify rules for such menu elements. Additional details regarding the menu XML document 30a and the menu rules XML document 30b are described in the attached appendix.

[0048] If in step 214 additional web page menu elements 16 are available based on additional XML elements 300, the application server 66 continues parsing each of the elements 300 until evaluation of all of the available web page menu elements 16 is completed. The application server 66 then outputs the HTML page 10a having the menu 24 to the browser 42c. The user can then select one of the available menu options to perform a prescribed provisioning operation, described below. Moreover, the dynamic execution of the web page 10a enables a personalized menu 24 to be generated for the user, such that one menu can be generated for an administrator, and another menu can be generated for a messaging subscriber, etc.

[0049] FIG. 4B illustrates the dynamic generation of an HTML page 10b having dynamically selected HTML form fields according to an embodiment of the present invention. The application server 66 receives in step 218 a request, for example that specifies a locator for a subscriber data form 10b. The locator specifies a selected XML document, summarized as document portions 30c and 30d in FIGS. 7A and 7B, respectively, that specifies available web page form elements for display as HTML form fields 20.

[0050] In particular, the document portion 30c illustrated in FIG. 7A specifies document type descriptors that define XML elements and XML attributes. Specifically, the document type descriptor 320 specifies that the web page form XML document portion 30d includes at least one cell 322 that specifies a corresponding available web page form element for display as an HTML form field 20 on the web page 10b. Each XML cell 322 specifies one the following elements: an INPUT element, a SELECT element, a HEADING element, a MESSAGE element, a TEXT element, or a BOLDTEXT element. For example, the cells 322a and 322b specify HEADING elements 324a and 324b, respectively; the cell 322c specifies a SELECT element 326 and a mapping attribute 328a used to identify the subscriber attribute to be modified based on user input, described below. The cell 322d and 322e specify INPUT elements 330a and 330b that define generation of an HTML input form element 22 for display, modification, and storage of respective selected subscriber attributes 22 in the HTML web page 10b. Additional details describing the XML tags used in the web forms XML document 30c/30d are disclosed in the attached appendix.

[0051] Generation of the HTML page 10b having the selected HTML form fields 20 for modifying selected subscriber attributes 22 will now be described with reference to FIG. 4B. The application server 66 retrieves the subscriber profile in step 220, for example by accessing a locally stored XML file storing the previously-retrieved subscriber profile information. The application server 66 retrieves in step 222 the web forms XML document 30c/30d as illustrated in FIGS. 7A and 7B, and parses the web forms XML document for available cells 322. The application server 66 also retrieves in step 224 a web forms rules XML document that specifies rules for validating respective inputs, described in detail in the attached appendix.

[0052] The application server 66 begins generation of the HTML page 10b by inserting in step 226 HTML tags for cells (e.g., 322a, 322b) that specify subscriber-independent attributes, such as text, messages, or commands with locators: if a message is subscriber specific is set by a global variable, other logical processing may occur. The application server 66 then selects user-dependent cells for insertion of the respective web pages by determining, for example, whether in step 228 the subscriber attribute matches a corresponding bind attribute 328 for an input form element 330: if there is a match between the subscriber attribute and the bind attribute, the application server 66 inserts in step 230 the input form field 20 and the corresponding matching subscriber attribute as an input entry (i.e., element) 22. If the accessed web forms rules XML document specifies a validation rule, the application server 66 inserts in step 232 an executable resource, for example a JavaScript resource, that enables the display browser 42c to validate the data input to a corresponding input form element 22. The application server continues in step 234 to parse any additional cells 322 until all available HTML form fields have been reviewed for selection. The application server 66 then outputs the completed HTML page in step 236.

[0053] Hence, the application server 66 is able to dynamically generate within an application runtime environment an HTML page 10b having selected form fields with respective matching attributes from the subscriber directory 88. The browser 42c displays the HTML page 10b, enabling the user to select, input, and modify subscriber preferences. In addition, the JavaScript resource inserted in step 232 automatically validates input entries once an input form field 20 is deselected (indicating data entry is complete for that field). If the JavaScript resource determines an error, the user is notified and prompted to re-enter the appropriate data in the correct format. Once the user completes the form, the user can post the web page to a prescribed URL.

[0054] The application server 66, upon receiving in step 238 the HTTP post with the modified input value and bind attribute in step 238, updates in step 240 the subscriber attribute information with the modified input value based on the corresponding bind attribute.

[0055] According to the disclosed embodiment, web pages can be dynamically generated based on XML pages defining available web page elements, and matching subscriber attributes retrieved from the subscriber profile directory. The dynamic generation of web pages by parsing the XML files provides scalability by use of the configured for XML processing; moreover, applications can easily be modified by editing XML files to change a user presentation for a particular installation. Hence, the disclosed arrangement provides flexibility and scalability in deployment of self-administered applications.

[0056] While this invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.