AU752622B2

Graphical user interface for web enabled applications

Abstract

A double firewalled system is disclosed for protecting remote enterprise servers that provide communication services to telecommunication network customers from unauthorized third parties. A first router directs all connection requests to one or more secure web servers, which may utilize a load balancer to efficiently distribute the session connection load among a high number of authorized client users. On the network side of the web servers, a second router directs all connection requests to a dispatcher server, which routes application server calls to a proxy server for the application requested. A plurality of data security protocols are also employed. The protocols provide for an identification of the user, and an authentication of the user to ensure the user is who he/she claims to be and a determination of entitlements that the user may avail themselves of within the enterprise system.

AU752622B2, drawing sheet 1 — Sheet 1 of 23

Term

Term ended

Expired 25 September 2018, 8 years ago.

5 claims: 1 independent, 4 dependent

1
WO 99/15984 PCT/US98/20095 -116CLAIMS Having thus described our invention, what we claim as new, and desire to secure by Letters Patent is:1. A system for integrating and managing one or more client application programs which enable a user to interact with one or more web enabled services subscribed by the user, comprising: a web browser, resident on a client platform, the web browser capable of receiving one or more web pages from a remote server;a backplane object downloaded with, and launched by the web page, the backplane object capable of launching the client application programs upon initiation by the user, the backplane object further enabling inter-application communications among the client application programs and also with the backplane object, whereby the backplane object and the client application programs interoperate with one another to provide an integrated customer interface to a plurality of communications network management services subscribed by the user.

853 paragraphs in 324 sections, as filed

WO 99/15984

PCT/US98/20095

GRAPHICAL USER INTERFACE FOR WEB ENABLED APPLICATIONS *’ The present invention relates in general to computer software, and more particularly to a user

- 5 interface software in a client - server network architecture.

A client-server software system having a graphical user interface front-end and one or more back-end legacy systems are generally known in the information systems industries. Worldwide Web (Web)based online systems are also starting to emerge as the use of the Internet proliferates world wide. These Web-based online systems usually employ a Web browser displaying Hypertext Markup Language (HTML) pages as graphical user interface (GUI), and often include Java applets and Common Gateway Interface (CGI) programs for customer interaction. In these systems, however the retrieval from a given Uniform Resource Locator (URL) and display on the customer's screen are often performed on a page by page basis. That is, each page retrieved and displayed is independent of any previous or subsequent pages. Because each page is displayed and run independently of one another, components existing on a page are limited in their ability to communicate with other components existing on other pages. Moreover, there is no backbone architecture for managing and overseeing GUI when screen displays are presented as independent HTML pages. Additionally, the HTML pages and Java applets are usually confined to a

Web browser within which they are running. Therefore, it is highly desirable to provide a Web-base GUI system which includes a backbone architecture for managing and ' enabling communications and interoperability among various processes or components comprising the GUI \ 35 system, and at the same time provide some independence h!

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

- -2Vfrom the Web browser within which the GUI is running.

* In conventional systems, a connection is made

-with a large legacy system via a dial-up connection from a customer owned personal computer or workstation.

This connection frequently, although not always, emulates a terminal addressable by the legacy systems. The dial-up access requires custom software on the customer workstation to provide dial-up services, communication services, emulation and/or translation 10 services and generally some resident custom form of the legacy application to interface with the midrange or mainframe computer running the legacy system.

There are several problems associated with the approach. First, the aforementioned software is 15 very hardware dependent, requiring multiple versions of software compatible with each of a wide range of workstations customers generally have. Therefore, extensive inventory for distribution becomes necessary. If the customer hardware platform changes through an 20 upgrade, the software licensing issues must be renegotiated. Moreover, installing the software generally requires an intensive effort on the customer and the software support team before any reliable and secure sessions are possible.

Secondly, dial-up, modem, and communications software interact with each other in many ways which are not always predictable to a custom application, requiring extensive trouble shooting and problem solving for an enterprise wishing to make the 'legacy 30 system available to the customer, particularly where . various telephone exchanges, dialing standards or ’ signal standards are involved.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-3Thirdly, although more businesses are turning to the Internet to improve customer service and lower costs by providing Web-based support systems, when an enterprise wishes to make more than one system available to the customer, the custom application for one legacy system is not able to connect to a different legacy system, and the customer must generally logoff and logon to switch from one to the other. The delivery technology used by the two legacy systems may 10 be different, requiring different interface standards, and different machine level languages may be used by the two system, as for example, the 96 character EBCDIC language used by IBM, and 127 ASCII character language used by contemporary personal computers. Therefore, an 15. integrated and unified Web-based system for providing an access to a number of different legacy systems in one session is desired.

Finally, the security and entitlement features of the various legacy systems may be 20 completely different, and vary from system to system . and platform to platform. It is therefore, desired to provide connectivity to enterprise legacy systems over the public Internet, as the Internet provides access connectivity world wide via the TCP/IP protocol, 25 without need to navigate various telephone exchanges, dialing standards or signal standards.

. The popularity of the public Internet provides a measure of platform independence for the customer, as the customer can run their own Internet 30 Web browser and utilize their own platform connection to the Internet to enable services. This resolves many of the platform hardware and connectivity issues in the

SUBSTITUTE SHEET (RULE 26)

-4customers favor, and leaves the choice of platform and operating system to the customer. Web-based programs can minimize the need for training and support since they utilize existing client software which the user 5 has already installed and already knows how to use.

Further, if the customer later changes that platform, then, as soon as the new platform is Internet enabled, service is restored to the customer. The connectivity and communications software burden is thus resolved in 10 favor of standard and readily available hardware and the browser and software used by the public Internet connection.

An Internet delivered paradigm obviates many of the installation and configuration problems involved 15 with initial setup and configuration of a customer workstation, since the custom application required to interface with the legacy system can be delivered via the pubic Internet and run within a standard Webbrowser, reducing application compatibility issues to 20 browser compatibility issues.

For the enterprise, the use of off-the-shelf Web browsers by the customer significantly simplifies the enterprise burden by limiting the client development side to screen layout designs and data 25 presentation tools that use a common interface enabled by the Web browser. Software development, and support ..- ., resources are thus available for the delivery of the enterprise legacy services and are not consumed by a need for customer support at the workstation level.

P:\OPER\GCJA96663-98 responsc.doc-04/07/02

According to the present invention there is provided a system for integrating and managing one or more client application programs which enable a user to interact with one or more web enabled services subscribed by the user, 5 comprising: .

a web browser, resident on a client platform, the web browser capable of receiving one or more web pages from a remote server;

a backplane object downloaded with, and launched by the 10 web page, the backplane object capable of launching the client application programs upon initiation by the user, the backplane object further enabling inter-application communications among the client application programs and also with the backplane object, whereby the backplane object and the client application programs interoperate with one another to provide an integrated customer interface to a plurality of communications network management services subscribed by the user.

The invention also provides a method for integrating and managing one or more client application programs for enabling a user to interact with one or more web enabled services to which the user has subscribed, the method 25 comprising:

receiving a web page having a backplane object from a remote server;

downloading a client application program associated with the web enabled services;

launching the backplane object;

presenting to the user the client application programs associated with the web enabled services to which the user

P:\OPER\GCP\96663-98 re$ponse.doc-04/07/02

-6has subscribed and which the user may select; and creating the client application program upon the user's request, whereby the backplane object and the client application 5 programs interoperate with one another and communicate with the remote server to provide an integrated customer interface to a plurality of communications network management services subscribed by the user.

The system may include a centralized user authentication feature to insure that the user has valid access to the system. The authentication procedure generally includes a logon object which prompts for and accepts the user's name and password. The logon object then 15 communicates the logon transaction to a remote server responsible for screening those users attempting to access remote services. Once a user has been authenticated by the system of the present invention, the user need not be validated again each time the user accesses another remote 20 server via the respective server's user interface program.

<td> 4</td><td> example, the backplane services layer 12 is programmed as a Java applet which may be loaded and launched by the web browser 14. With reference to Figure 3, a typical user session starts with a web browser 14</td>

<td> 5</td><td> creating a backplane 12, after a successful logon. The backplane 12, inter alia, presents a user with an interface for networkMCI Interact application management. A typical user display provided by the backplane 12 may show a number of applications the user</td>

<td> 10</td><td> is entitled to run, each application represented by buttons depicted in Figure 3 as buttons 58a,b,c selectable by the user. As illustrated in Figure 3, upon selection of an application, the backplane 12 launches that specific application, for example,</td>

<td> 15</td><td> Service Inquiry 54a or Event Monitor 54b, by creating the application object. In processing its functions, each application in turn, may utilize common object services provided by the backplane 12. Figure 3 shows graphical user interface objects 56a,b created and used</td>

<td> 20</td><td> by a respective application 54a,b for its own presentation purposes. Figure 4 illustrates an example client GUI presented to the client/customer as a browser web page 250 providing, for example, a suite 252 of network</td>

<td> 25</td><td> management reporting applications including: MCI Traffic Monitor 252c; Call Manager 252f; and Network Manager 252e. Access to network functionality is also provided ·through Report Requester 252b, which provides</td>

PCT/US98/20095

-17cached.

If the requestor is authorized to communicate with the target service, the message is forwarded to the desired service's proxy. Each application proxy is 5 an application specific daemon which resides on a specific Intranet server, shown in Figure 2 as a suite of mid-range servers 30. Each Intranet application server of suite 30 is generally responsible for providing a specific back-end service requested by the 10 client, and, is additionally capable of requesting services from other Intranet application servers by communicating to the specific proxy associated with that other application server. Thus, an application server not only can offer its browser a client to 15 server interface through the proxy, but also may offer all its services from its proxy to other application servers. In effect, the application servers requesting services are acting as clients to the application servers providing the services. Such mechanism increases the security of the overall system as well as reducing the number of interfaces.

The network architecture of Figure 2 may also include a variety of application specific proxies having associated Intranet application servers 25 including: a StarOE proxy for the StarOE application server 39 for handling authentication order entry/billing; an Inbox proxy for the Inbox application server 31, which functions as a container for completed reports, call detail data and marketing news messages; 30 a Report Manager proxy capable of communicating with a system-specific Report Manager server 32 for

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-18generation, management and receipt notification of customized reports; a Report Scheduler proxy for performing the scheduling and requests of the customized reports. The customized reports include, for example: call usage analysis information provided from the StarODS server 33; network traffic analysis/monitor information provided from the Traffic view server 34; virtual data network alarms and performance reports provided by Broadband server 35; trouble tickets for switching, transmission and traffic faults provided by Service Inquiry server 36; and toll free routing information provided by Toll Free Network Manager server 37.

As partially shown in Figure 2, it is understood that each Intranet server of suite 30 communicates with one or several consolidated network databases which include each customer's network management information and data. For example, the Services Inquiry server 36 includes communication with MCI's Customer Service Management legacy platform 40(a). Such network management and customer network data is additionally accessible by authorized MCI management personnel. As shown in Figure 2, other legacy platforms 40(b), 40(c) and 40(d) may also communicate individually with the Intranet servers for servicing specific transactions initiated at the client browser. The illustrated legacy platforms 40(a)-(d) are illustrative only and it is understood other legacy platforms may be interpreted into the network · architecture illustrated in Figure 2 through an intermediate midrange server 30.

Each of the individual proxies may be '

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

<td></td><td> maintained on the dispatch server 26, the related application server, or a separate proxy server situated between the dispatch server 26 and the midrange server 30. The relevant proxy waits for requests from an</td>

<td> 5</td><td> application client running on the customer's workstation 10 and then services the request, either by handling them internally or forwarding them to its associated Intranet application server 30. The proxies additionally receive appropriate responses back from an</td>

<td> 10</td><td> Intranet application server 30. Any data returned from the Intranet application server 30 is translated back to client format, and returned over the Internet to the client workstation 10 via the Dispatch Server 26 and at one of the web servers in the DMZ Services cluster 24</td>

<td> 15</td><td> and a secure sockets connection. When the resultant response header and trailing application specific data are sent back to the client browser from the proxy, the messages will cascade all the way back to the browser 14 in real time, limited only by the transmission</td>

<td> 20 '</td><td> latency speed of the network. The networkMCI Interact middle tier software includes a communications component offering three (3) types of data transport mechanisms: 1) Synchronous; 2) Asynchronous; and 3) Bulk transfer. Synchronous</td>

<td> 25</td><td> transaction is used for situations in which data will be returned by the application server 40 quickly. Thus, a single TCP connection will be made and kept open until the full response has been retrieved. Asynchronous transaction is supported</td>

<td> l· 30</td><td> generally for situations in which there may be a long</td>

<td> -</td><td> delay in application server 40 response. Specifically, a proxy will accept a request from a customer or client</td>

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-2010 via an SSL connection and then respond to the client 10 with a unique identifier and close the socket connection. The client 10 may then poll repeatedly on a periodic basis until the response is ready. Each poll will occur on a new socket connection to the proxy, and the proxy will either respond with the resultant data or, respond that the request is still in progress. This will reduce the number of resource consuming TCP connections open at any time and permit a user to close their browser or disconnect: a modem and return later to check for results.

Bulk transfer is generally intended for large data transfers and are unlimited in size. Bulk transfer permits cancellation during a transfer and allows the programmer to code resumption of a transfer at a later point in time.

Figure 5 is a diagram depicting the physical networkMCI Interact system architecture 10. As shown in Figure 5, the system is divided into three major architectural divisions including: 1) the customer workstation 20 which include those mechanisms enabling customer connection to the Secure web servers 24; 2) a secure network area 17, known as the DeMilitarized Zone DMZ set aside on MCI premises double firewalled between the both the public Internet 25 and the MCI Intranet to prevent potentially hostile customer attacks; and, 3) the MCI Intranet Midrange Servers 30 and Legacy Mainframe Systems 4 0 which comprise the back-end business logic applications.

As illustrated in Figure 5, the present invention includes a double or complex firewall system

SUBSTITUTE SHEET (RULE 26)

As shown in Figure 5, the most available Web server 24 receives subscriber HTTPS requests, for example, from the HydraWEB™ 45 over a connection 44a and generates the appropriate encrypted messages for routing the request to the appropriate MCI Intranet midrange web server over connection 44b, router 55 and connection 23. Via the HydraWEB™ unit 45, a TCP/IP connection 38 links the Secure Web server 24 with the MCI Intranet Dispatcher server 26.

Further as shown in the DMZ 17 is a second 25 RTM server 52 having its own connection to the public

Internet via a TCP/IP connection 48. This RTM server provides real-time session management for subscribers of the networkMCI Interact Real Time Monitoring system. An additional TCP/IP connection 48 links the RTM Web

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-24server 52 with the MCI Intranet Dispatcher server 26. With more particularity, as further shown in Figure 5, the networkMCI Interact physical architecture includes three routers: a first router 49 for routing encrypted messages from the Public Internet 15 to the HydraWEB™ 45 over a socket connection 44; a second router 55 for routing encrypted subscriber messages from a Secure Web server 24 to the Dispatcher server 26 located inside the second firewall 25b; and, a third router 65 for routing encrypted subscriber messages from the RTM Web server 52 to the Dispatcher server 26 inside the second firewall. Although not shown, each of the routers 55, 65 may additionally route signals through a series of other routers before eventually being routed to the nMCI Interact Dispatcher server 26. In operation, each of the Secure servers 24 function to decrypt the client message, preferably via the SSL implementation, and unwrap the session key and verify the users session from the COUser object authenticated at Logon.

After establishing that the request has come from a valid user and mapping the request to its associated session, the Secure Web servers 24 will reencrypt the request using symmetric RSA encryption and forward it over a second secure socket connection 23 to the dispatch server 26 inside the enterprise Intranet. As described herein, the data architecture component of networkMCI Interact reporting system is focused on the presentation of real time (un-priced) call detail data, such as provided by MCI's Trafficview

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-25Server 34, and priced call detail data and reports, such as provided by MCI's StarODS Server 33 in a -variety of user selected formats.

. All reporting is provided through a Report

Requestor GUI application interface which support spreadsheet, a variety of graph and chart type, or both simultaneously. For example, the spreadsheet presentation allows for sorting by any arbitrary set of columns. The report viewer may also be launched from the inbox when a report is selected.

A common database may be maintained to hold the common configuration data which may be used by the GUI applications and by the mid-range servers. Such common data includes but are not limited to: customer security profiles, billing hierarchies for each customer, general reference data (states, NPA's, Country codes), and customer specific pick lists: e.g., ANI's, calling cards, etc.. An MCI Internet StarOE server manages the data base for the common configuration of data.

Report management related data is also generated which includes 1) report profiles defining the types of reports that are available, fields for the reports, default sort options and customizations allowed; and 2) report requests defining customer specific report requests including report type, report name, scheduling criteria, and subtotal fields. This type of data is typically resident in a Report Manager server database and managed by the Report Manager.

The Infrastructure component of the nMCI Reporting system includes mechanisms for providing secure communications regardless of the data content

SUBSTITUTE SHEET (RULE 26)

The COApplet class, on the other hand, extends the Applet class and is intended to be launched

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-3010 ·

When a customer wants to logoff, a logoff

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

<td> t .</td><td> request transaction may be sent to the Web server 1344. The Web server 1344 then connects to the cookie jar 13 52 and requests logoff for the session as shown at 1450. The cookiejar 1352 identifies the cookie for the</td>

<td> 5</td><td> session and deletes the cookie. After deleting the cookie, the cookiejar 1352 sends a logoff status to the Web server 1344, which returns the status to the client platform. Other transaction requests are also sent via</td>

<td> 10</td><td> the Web server 1344 and the cookiejar 1352 as shown in Figure 9. Figure 9 is a data flow diagram for various transactions communicated in the system of the present invention. Typically, when a customer enters a mouse click on an application link as shown at 1460, an</td>

<td> 15 '</td><td> appropriate transaction request stream is sent to the Web server as shown at 1462. The Web server 1344 typically decrypts the transaction stream and connects to the cookiejar 1352 to check if a given session is still valid as shown at 1464. The cookiejar 1352</td>

<td> 20</td><td> identifies the cookie for the session and sends it back to the Web server 1344 as shown at 1464. The Web server 1344 on receipt of valid session connects to the dispatcher 1346 and sends the transaction request as shown at 1466. When the dispatcher 1346 obtains the</td>

<td> 25</td><td> request, it may also connect to the cookiejar 1352 to validate the session as shown at 1468. The cookiejar 1352 identifies the cookie for the session and sends it back to the dispatcher 1346 as shown at 1468. The</td>

<td> 30</td><td> dispatcher 1346, upon receiving the valid session connects to a targeted application server or proxy 354, which may include StarOE, and sends the request</td>

<td> ΐ</td><td> transaction to the target as shown at 1470. The server</td>

The present invention includes a user unit for representing a user of a current session. The user unit is generally implemented as a COUser class extending java. lang.Object. The COUser class object typically holds information including a user profile, applications and their entitlements. In order to

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-45minimize network, traffic, the amount of data carried by the COUser is minimal initially, and get populated as requests are processed. The requests are generally processed by retrieving information from the Order Entry service. The profile information is then stored and populated in the COUser object should such information be requested again.

A COUser object is created when the user logs in, and holds the username and password of the user as an object in the COClientSession object. The session object is contained within the backplane, which manages the session throughout its lifetime. The code below illustrates how this occurs:

// Within the backplane COClientSession session = new COClientSession() ; try {

Session. logon (username, password ) ; } catch (COClientLogonException e) {...}; // Should the User object be required COUser user = session.getUser(); '

The logon method of the COClientSession object communicates with the Order Entry server, a back-end authentication mechanism, for authenticating the user.

The COUser that may be obtained from the COClientSession immediately after the login process is very sparse. It includes a limited set of information such as username, a list of applications that user is entitled to, for example. The details of each entitlement information are retrieved at the time of actual processing with those information.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-46Communications

The present invention includes a client communications unit for providing a single interface frqm which the backplane and the applications may send messages and requests to back-end services. The client communications unit includes a client session unit and a transactions unit. The client session unit and the transactions unit comprise classes used by client applications to create objects that handle communications to the various application proxies and or servers. Generally, the entire communications processes start with the creation of a client session after a login process. This is started through the login process. The user logs into user's Web page with a username and password. During a login process, a client session object of class COClientSession is created, and the COClientSession object passes the username and password information pair obtained from the login process to a remote system administrative service which validates the pair. The following code instructions are implemented, for example, to start up a session using the COClientSession class. COClientSession ss = new COClientSession();

try { ss.setURL(urlString);

ss. logon (j smith, myPassword);

PCT/US98/20095

-49enableHeartbeat), where enableHeartbeat is a flag to . enable or disable heartbeat for a session. The heartbeat messages are typically transmitted periodically by first invoking the COClientSession object's method public synchronized void setHeartbeatlnterval (long millsecslnterval) , where the heartbeat interval is set in milliseconds, and by the COClientSession object's method protected int startHeartbeat(), where the heartbeat process starts as soon as the heartbeat interval is reached. Failure to heartbeat for consecutive predefined period, e.g., one hour, would result in the expiration of the session key.

. As described previously, a typical communication with remote services are initiated by instantiating a COClientSession object. A COClientSession instance may then be used to connect to a given URL by invoking its methods setURLO and logon () . There are no limitations on how many

20· simultaneous connections are allowed. During the logon process, the given URL would point to the home page containing the backplane applet.

A second component of the communications unit provided and used in the present invention is a transactions class. The main purpose of a transaction is to send a message to a back-end service and return the corresponding response from that service. This response may also be in a form of a message. Any message may be sent with any transaction. Transactions need not be aware of any service content type information. Instead, this information is encapsulated . in the messages sent to and from the back-end service.

SUBSTITUTE SHEET (RULE 26)

Instances of COBulkTransaction are capable of executing bulk transactions. Like the asynchronous transaction class (COAsynchTransaction) ,

COBulkTransaction blocking mode is invoked with the sendMessage () java message and its non-blocking mode is invoked with the sendRequest () Java message in the CONonblockingTransaction class. In addition to sending a callback Java message to a registered object when the transaction is finished, COBulkTransaction instances send another callback message when each data block arrives. This second callback is sent in both blocking and non-blocking modes and is used to send large data

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-53sets synchronously. COBulkTransaction instances are capable of transferring only a portion of data from a back-end service. This portion can also start at any offset within the complete data set. This functionality will mainly be used by messages which understand how to transfer data to files.

Input/Output Services

In order to centralize and unify all input/output transactions performed by the backplane and the client applications, the present invention includes a set of common input/output services objects for use by the backplane and the applications. These include a framework for printing, data export and import, logging, configuration file management and statistics.

The common input/output services objects provide simplified and standardized export/import interface. Containers, which need to be exported, implement the Exportable interface. Here, containers is used in the broadest possible sense, spanning everything from a complete application to the smallest data container, e.g., trees, queues. This architecture defines exactly how a container will be converted from an object in active memory, to a data array in static memory. The Exportable interface suggests three possibly exportable data formats: a string, byte arrays, and character arrays.

The class Export contains a number' of convenience methods for writing strings, byte arrays, or character arrays to a specified file. In the code example, the container tree implements the

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-54. Exportable interface.

// First, get a reference to a file to export to

- File file = new File ( /MyDirect.ory/treeExport ) ;

// Then use the Export class to export...

Try {

Export.exportData ( file, . tree.getExportableByteArray() );

} catch (lOException ioe) {...}

Containers, which need to import data, implement the Importable interface. An application's import and export mechanisms need not be symmetrical. The interface mechanism defines exactly how import will occur, that is, how a given body of static data will be integrated into the running application. The interface expects to import data in one of three forms: strings, byte arrays, or character arrays.

The class Import provides convenience methods for reading strings, byte arrays, or character arrays from a specified file. The following code fragment represents use of data import. Here, tree is a data container, which implements the Importable interface.

// First, get a reference to a file from which to // import...

File file = new File (/MyDirectory/treelmport);

// Then use the Import class to import... byte[] data = Import. importByteData (file) ; tree.importByteArray(data); '

The input/output services objects also include a centralized logging utility. The purpose of

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-55logging is twofold: it allows developers to get a good handle on what functions customers are using, helping marketing, while also giving a way to checkpoint the series of actions, which led to a failure of the application.

The global logfile has global parameters, and also serves as a container for each of the application logfile objects. Each active application has a reference back to the application logfile in the global object. The following represents a code example of logfile use. In the following code, myself is the COUser object. ' // In the application object....

COAppLog appLog = COAppLog.getAppLog(this); applog.addEntry(COAppLog. INFO, Key Event, User pushed OK);

The input/output services objects also include configuration file object. A configuration file represents either a user's choice of desirable application characteristics or a set of default characteristics. The preferred structure for the configuration file is a hierarchy, which places the application at the highest level, then the version, followed by the section and then by a parameter namevalue pair: application.version.section.name.

The general architecture of the configuration file object is just like that of the logfile object. The following represents an example of the code that would be generated by use of application configuration file object.

// In the application object....

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-56COAppConfiguration appConf =

COAppConfiguration.getAppConfiguration(this) ; String CDRomDriver = appConf.getEntry(Drivers, CDROM);

The input/output services objects also include statistics objects for holding a number of counters and other numerical data, which allow the backplane and the applications to keep a numerical log.

The type of object that a statistic object might hold are the number of times that a user exported data, or the number of times that an application communicated back to a specific back-end server. The architecture is identical to that of logging and configuration

15. files. The following represents code example for use of statistics.

// In the application object....

COAppStat appStat = COAppStat.getAppStat(this) ; appStat. incrementvalue (Communications2Server) ;

Security

The present invention allows the backplane and the client applications to utilize browser built-in security functions without having to be tied to a specific code. The present invention provides an additional module which wraps the security . functionality of specific browsers available off-theshelf .

Figure 12 is a diagram which illustrates a security module design having clean separation from the browser specific implementations. The security module comprises the main COSecurity class 402, and the

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-57interface COBrowserSecuritylnterface 404. The COSecurity object checks browser type upon instantiation. It does so by requesting the java.vendor system property. If the browser is Netscape, for example, the class then instantiates by name the concrete implementation of the Netscape security interface, nmco. security. securityimpls .CONetscape4_OSecurityImpl 406. Otherwise, it instantiates nmco. security.securityimpls.CODefaultSecuritylmpl 408 . COSecurity 402 includes a number of methods for accessing local resources, e.g., printing, importing and exporting data, and getting/setting local system properties .

The COBrowserSecuritylnterface 404 mirrors the methods provided by COSecurity 402. Concrete implementations such as CONetscape4_0SecurityImpl 4 06 for Netscape Communicator and CODefaultSecuritylmpl 408 as a default are also provided. Adding a new implementation 410 is as easy as implementing the COBrowserSecuritylnterface, and adding in a new hook in COSecurity.

After using java.vendor to discover what browser is being used, COSecurity 402 instantiates by name the appropriate concrete implementation. This is done by class loading first, then using Class.newlnstance() to create a new instance. The newlnstance() method returns a generic object; in order to use it, it must be cast to the appropriate’class. COSecurity 402 casts the instantiated object to COBrowserSecruitylnterface 404, rather than to the concrete implementation. COSecurity 402 then makes

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-58calls to the COBrowserSecuritylnterface object, which is actually a concrete implementation in disguise. -This is an example of the use of object oriented polymorphism. This design cleanly separates the specific implementations which are browser-specific from the browser-independent COSecurity object.

Each COApp object may either create their own COSecurity object using the public constructors, or retrieve the COSecurity object used by the backplane via COBackPlane.getSecurity(). In general, the developer of the applications to be run will use the COSecurity object whenever the COApp needs privileged access to any local resource, i.e., access to the local disk, printing, local system properties, and starting external processes. The following represents an example of the code generated when using the security obj ect.

// Instantiating COSecurity objectCOSecurity security = new COSecurity();

// Now access a privileged resource try {

String s = securi ty.getSys temProperty ( user.home ) ; System.out.printin(s);

} catch(COSecurityException cose) { // take care in case of security exception

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-59Help

In order for the backplane and the client application to integrate help functionality of a underlying browser, the present invention provides a help framework. There are two semi - independent parts to providing help. The first part is the help itself ' which is handled through the COHelp object. The second part is the help infrastructure which is provided by the COHelpListener interface. They are semi10 independent because one may be safely used without the other although they are meant to complement each other.

The COHelp object provides a calling interface with which the underlying browser can bring up the help information. To bring up help using this 15 object, all that is necessary is to pass a URL pointing to the relevant help page and a reference to the COApp. For example:

if (action == HELP) { ' try { // creating the help URL

URL helpURL = new URL ( index.html); // calling help

COHelp.showHelp( thisCOApp, helpURL );

} catch (MalformedURLException e) 25 ’ { /* do something */ } }

The COHelpListener interface provides a set of convenient functions for implementing help -in

COApps. This interface provides functions to define a default help URL:

void setHelpURL(URL help);

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-6010 .

URL getHelpURL();

. The COHelpListener interface also provides the initial foundation for handling Fl help calls. It extends the KeyListener interface which is needed to detect Fl keystrokes.

PCT/US98/20095

-64public static final int WINDOWS_TILED_HORIZONTALLY public static final int WINDOWS-CASCADED

- protected static COBackPlane theBackPlane

- this is used to allow a static method to locate the backplane, e.g. by COApplets protected Vector availableApps

Vector of available apps (by name, vector of strings) protected COStat globStats

Global statistics object protected COAppEntitlement globEnts

Global entitlements object protected COLog globLog

Global log object protected COConfiguration globConfig

Global configuration object public COBackPlane()

Default constructor public static COBackPlane getBackPlane() this method is used by COApps which are not launched by the backplane (e.g. applets launched from an HTML page to find the backplane.

Returns:

the COBackPlane public void init()

Initializes the backplane, by initializing

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-65container objects, establishing a session, getting user context object, as well as starting the ToolBar and Inbox applications.

Overrides:

init in class Applet.

public void start ()

Starts the backplane--probably background threads for backend communications.

Overrides:

start in class Applet.

public void stop()

Stops the backplane and kills any background threads used by the Backplane.

Overrides :

. stop in class Applet.

public void destroy()

Destroys the backplane and kills all running applications, and any threads that COBackPlane may have called into existence. It will try to wait for all running COApps to be closed.

Overrides :

destroy in class Applet public void run () Run method for the backplane main thread.

SUBSTITUTE SHEET (RULE 26)

COException '

Launches the specified native application Parameters :

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-69command - String denoting the command used to launch a native application

Throws : COException . if the native application cannot be launched public synchronized void addAvailableApp(String appName) throws COException

Adds the specified COApp to the Backplane by name; updates AppBar

Parameters :

app - the name of the COApp to be added to the Backplane

Throws: COException if COApp cannot be added public synchronized void removeAvailableApp(String appName) throws COException

Removes the specified COApp from the Backplane by name, closing it, if necessary, and updates AppBar

Parameters:

app - the name of the COApp to be removed from the Backplane

Throws: COException if COApp cannot be removed public synchronized void closeApp(COApp app) -throws COException

Closes the specified, locally running COApp;

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-70deletes app from runningApps

Parameters :

- app - a reference to the COApp to be closed

Throws : COException if the COApp cannot be closed public void closeAHApps () throws COException

Closes all locally running COApps; clears runningApps

Throws: COException if all COApps cannot be closed public void setWindowState(COApp app, int state) Sets the window state for the specified COApp Parameters:

app - a reference to the COApp whose window state is to be set state - the integer value representing the window state constant, e.g., WINDOW_MINIMIZED, WINDOW_MAXIMIZED, WINDOW_TILED_VERTICALLY.

public void setAHWindowStates (int state)

Sets the window state for all COApps

Parameters:

state - the integer value representing the window state constant

Throws: COException · if all the window states cannot be set

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-71protected COApp findApp(String appName) finds the requested app by name in runningApps • Returns:

- a reference to the COApp if it is running, or null if it is not protected COApp launchApp(String appName)

Launches the specified COApp, if not already running; adds app to runningApps

Parameters :

app - a reference to the COApp to be launched Throws: COException if the COApp cannot be launched public boolean registerApp(COApp theApp) allows COApps which are not launched by the backplane (e.g., applets launched from an HTML page) to register with the backplane.

Returns:

true if the app was successfully registered protected synchronized void killApp(COApp app) protected synchronized void addRunningApp(COApp a) add a COApp to runningApps protected synchronized void removeRunningApp(COApp a) remove a COApp from runningApps

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-72public COStat getGlobalStats() . The method checks for the existence of a global statistics object. If it does not exist, then it constructs one.

Returns:

the global statistics object for this backplane.

public COAppEntitlement getGlobalEntitlements ()

The method checks for the existence of a global entitlements object. If it does not exist, then it constructs one.

Returns :

the global entitlements object for this backplane public COLog getGlobalLog()

The method checks for the existence of a global log. If it does not exist, then it constructs one using the COLog constructor.

Returns :

the global log object for this backplane public COConfiguration getGlobalConfiguration()

The method checks for the existence of a global configuration object. If it does not exist, then it constructs one.

Returns :

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-73the global configuration object for this backplane.

- The COApp class is intended to mimic an Applet-like interface but be managed by the Backplane. A COApp may use the standard COAppFrame as a container for COView(s), which are notified of updates to the business objects (COModels) instantiated by this COApp (e.g., appHyperScope). The COModels within a COApp implement undo/redo of COCommands (refer to the Controller portion of MVC). It also has a list of COParm objects, which contain the message headers from asynchronous transactions (other than those forwarded to the COApp by the Inbox, for which a separate list object has been provided). Synchronous responses from backend services are processed as they are received.

Example code for use of COApp will be illustrated. When an application icon on the AppBar is clicked, a specific COApp will be launched by the Backplane. The BackPlane will then call the COApp's applet-like startup routines, appHyperScope.initO ; and appHyperScope. start ();

One COApp may communicate with another (including the Inbox) via the BackPlane by instantiating a message object of the COParm class, '

COParm message = new COParm(...); and invoking the processMessage method,

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-74appHyperScope.processMessage(message) ;

A COApp can execute both synchronous and asynchronous -transactions. Synchronous transactions involve direct service requests. New Threads may be spawned in which to execute the transactions in parallel. Such threaded transactions are synchronized if multiple threads modify common business objects:

COSynchTransaction st = new

COSynchTransaction(clientsession);

st. execute (specificService, byteArrayOfData);

Asynchronous transactions involve requests for services which will require extended processing, such as report requests from the Inbox:

COAsynchTransaction ast = new

COAsynchTransaction(clientsession) ;

ast. execute(specificService, byteArrayOfData);

Each application must define the methods, minimizeApp(), maximizeApp(), tileAppO, placeAppO, appRequestFocus () , appToFront() , appToBack() in order ' for BackPlane-induced windowing requests to work properly. Window count must also be set for each application accurately using setWindowCount(), as the BackPlane depends upon an accurate window count using getWindowCount().

The following lists the COApp class properties and methods.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-75public interface COApp

-public abstract String getAppNameO

- Returns the name of the COApp instance

Returns:

the name of the COApp instance, null if not set.

public abstract COAppDescription getAppDescription()

Returns the application description object. The information in the application description is used by the standard app frame.

public abstract COBackPlane getBackPlane()

Returns the COBackPlane pertaining to the COApp ' instance

Returns :

the COBackPlane pertaining to the COApp instance, null if not set.

public abstract COUser getUserO

Returns the user and is identical to the Backplane's COUser instance

Returns:

the user context object, null if not set.

public abstract void minimizeApp()

Minimizes the frames associated with this

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-76application. An application should override this method, dealing with (possibly) multiple frames and open dialogs .

public abstract void maximizeApp()

Maximize the frame (s) associated with this application. An application should override this method, dealing with possibly multiple frames and open dialogs .

public abstract boolean tileApp(Rectangle ,r[]) Backplane feeds the application rectangles, indicating the location and size that the application may take up of screen real estate for tiling purposes. The individual application must override for the case that there are multiple application frames, dialogs, and for the further case that an application is not to be tiled, e.g., COToolBar. This method always returns false.

Parameters :

r - a rectangle indicating the amount of screen real estate the backplane is assigning to this application

Returns :

true if successful, false otherwise. Also, an application like COToolBar which is a pseudoapp, for which tiling will not occur should override this method to return simple false.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-77public abstract void placeApp(Point positions!])

The BackPlane feeds the application positions. The application must then move each of its application windows to one of the given positions.

PCT/US98/20095 •80Enable or disable the application and associated child windows.

public abstract void initO

This method is a part of the Applet-like interface and if called by the COBackPlane to inform this applet that it has been loaded into the system. It is always called before the first time that the start method is called. A subclass of COApp overrides this method if it has initialization to perform. The implementation of this method provided by the COApp class does nothing.

public abstract void start ()

This method is a part of the Applet-like interface and is called by the COBackPlane to inform this COApp that it should start its execution. It is called after the initO method. A subclass of COApp overrides this method if it has any operation that it wants to perform at the start of execution. This method is typically less important for COApps than for Applets, since COApps typically run continuously. The implementation of this method provided by the COApp class does nothing.

public abstract void stopO

This method is a part of the Applet-like interface and is called by the COBackPlane inform this COApp that it should stop its execution. It is called, for example, just before the applet is to be destroyed.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT7US98/20095

-81Like the start () method, this method is typically less important for COApps than for Applets, since COApps typically run continuously. The implementation of this method provided by the COApp class does nothing.

public abstract void destroy() part of the Applet-like interface Called by the COBackPlane to inform this applet that it is being reclaimed and that it should destroy any resources that it has allocated. The stop method will always be called before destroy. A subclass of COApp overrides this method if it has any operation that it wants to perform before it is destroyed. For example, a COApp with threads would use the init() method to create the threads and the destroy method to kill them. The implementation of this method provided by the COApp class does nothing.

The COAppImpl class is intended to implement the COApp interface in a non-.applet class, but with an applet-like interface. The COAppImpl class has all the functionality of an applet, except that it does not derive from Panel and thus does not have its own browser-based display space. A COAppImpl may use the standard COAppFrame or COStandardAppFrame as a container for display components, e.g. COView(s).

The COAppImpl class provides intelligent default implementations for all the COApp interface functions,

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-82as well as the applet - like interface functions such as getlmageO and getAppIetContext().

- The following lists the COAppImpl class properties and methods .

public class COAppImpl extends Object implements COApp, WindowListener protected COBackPlane backplane

This is the COBackPlane which created the COApp. It is provided by the COApp using the setBackPlane() method.

protected String sAppName

Name of COApp.

protected COAppEntitlement appEnts

Application entitlement object for COApp.

protected COAppDescription appDescription

Application description object for COApp which holds meta data such as default help URL.

protected COAppStat appStats Statistics object for COApp.

protected COAppConfiguration appConf Configuration object for COApp.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-83protected COAppLog appLog

Log object for COApp.

protected COUser user

User context object, to be set by the Backplane.

protected int windowcount

Integer type holding the number of main windows currently open for the application, excluding dialogs.

protected Vector children .

Vector holding all the child windows.

public COAppImpK) single constructor, like Applet class.

public String getAppNameO

Returns the name of the COApp instance

Returns: the name of the COApp instance, null if not set.

public COBackPlane getBackPlane()

Returns the COBackPlane pertaining to the COApp instance.

Returns :

the COBackPlane pertaining to the COApp instance, null if not set.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-84public COUser getUserO

Returns the user and is identical to the Backplane's COUser instance.

- Returns:

the user context object, null if not set.

public COAppDescription getAppDescription()

Returns the application description object containing meta-data about this application.

Returns : the application description object, null if not set.

public Vector getlnboxItemVector()

Returns the vector of inbox item headers.

PCT/US98/20095

-87public void setAppName(String name)

Sets the name of the COApp instance.

-92provided by the COApp class does nothing except that it will call disposeAllChildren to get rid of all registered windows.

public void exit() throws COException

This method is used to exit the application, called e.g. from the close box in the main frame, if any.

Throws : COExc ep t i on if an Application can not be closed.

public void addChild(Window wnd)

Adds a child window to this hierarchy.

public void removechild(Window wnd)

Removes a child window to this hierarchy.

public Vector getChildren()

Retrieves all the child windows associated with this COAppImp.

public void setEnabled(boolean state)

Enable or disable the application and associated child windows.

public void disposeAllChildren () ’

Iterate through all the children registered with this coapp and call their dispose method.

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

<td> •</td><td> public void windowActivated (WindowEvent e) Empty public void windowOpened (WindowEvent e)</td>

<td> 5 '</td><td> Empty public void windowclosing (WindowEvent e) Called when window is closing</td>

<td> 10</td><td> public void windowClosed(WindowEvent e) Empty public void windowDeactivated(WindowEvent e) Empty</td>

<td> 15</td><td> public void windowlconified(WindowEvent e) Empty. pub! -i r. void windowDeiconif ied (WindowEvent e)</td>

<td> 20</td><td> Empty public boolean isActiveO This method is a part of the Applet-like interface. This implementation always returns true.</td>

<td> 25</td><td> Subclasses of COApp overrides this method.</td>

<td> • *</td><td> public URL getCodeBase() part of the Applet-like interface.</td>

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-94public URL getDocumentBase() part of the Applet-like interface.

public String getParameter(String name)

This method is a part of the Applet-like interface.

public Appletcontext getAppletContext ()

This method is a part of the Applet-like interface.

public Image get!mage(URL url) This method is a part of the Applet-like interface.

public Image getImage(URL url, String name) This method is a part of the Applet-like interface.

public AudioClip getAudioClip(URL url) . This method is a part of the Applet-like interface.

public AudioClip getAudioClip(URL url, String name)

This method is a part of the Applet-like interface. ' · public Locale getLocaleO

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-95Retrieves locale from the BackPlane.

Returns :

null, if not set.

public void play(URL url) • This method is a part of the Applet-like interface.

public void play(URL url, String name) part of the Applet-like interface.

COApplet class extends java.applet.Applet,, and implements the COApp interface by forwarding the various calls to a contained COAppImpl object.

public class COApplet extends Applet implements COApp protected COAppImpl coAppImpl

This is the COAppImpl object to which the COApp 20 interface will be forwarded.

public COApplet() ’ single constructor, like Applet class.

public String getAppName()

This method is a part of the COApp interface and is forwarded to contained object. Returns : the name of the COApp instance, null if not

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-96set.

public COAppDescription getAppDescription()

This method is a part of the COApp interface and is forwarded to contained object.

Returns :

the application description object, null if not set.

public COBackPlane getBackPlane()

This method is a part of the COApp interface and is forwarded to contained object.

Returns :

PCT/US98/20095

<td> J</td><td> is forwarded to contained object. public void removechild(Window wnd) - This method is a part of the COApp interface and</td>

<td> 5</td><td> is forwarded to contained object. public Vector getChildren() This method is a part of the COApp interface and is forwarded to contained object.</td>

<td> 10</td><td> public void setEnabled(boolean b) This method is a part of the COApp interface and is forwarded to contained object. Overrides :</td>

<td> 15</td><td> setEnabled in class Component. public void initO This method is a part of the COApp interface and is forwarded to contained object.</td>

<td> 20</td><td> Overrides : init in class Applet. public void start () This method is a part of the COApp interface and</td>

<td> 25</td><td> is forwarded to contained object. Overrides: .</td>

<td></td><td> start in class Applet. ·</td>

<td></td><td> public void stopO</td>

SUBSTITUTE SHEET (RULE 26)

Adds a menu to a menu.

Parameters : addto - the menu to which another menu is to be added, menu - the menu to be added.

public void addHelpMenu (Menu help) Adds a help menu to the menubar.

public void setToolbarVisible(boolean visible)

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-104Set a toolbar to be visible or invisible.

-public void setToolbarBackground(Color color)

Set the toolbar background color. 5 public void addTools(Component tools[])

Adds a collection of tools to the toolbar in the order tools [0] to tools[n-l] for an array of n image buttons .

Parameters:

tools - an array of ImageButtons.

public void addTool(Component tool) Add a tool to the toolbar.

Parameters:

tool - an ImageButton.

public Panel getViewArea()

Returns the main viewing area, on which the 20 · developers should add whatever views they wish.

public void attachToViewArea(Component theComponent) makes the provided component take up the entire viewArea.

protected void setupPanels() sets up layout of standard frame. protected COApp getCOApp()

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095 , . -105ί’ ' Returns the COApp which owns this AppFrame.

·>

-public void windowActivated(WindowEvent e) • - Overrides:

windowActivated in class COFrame.

public void windowOpened (WindowEvent e)

Overrides: windowOpened in class COFrame.

public void windowclosing(WindowEvent e) Called when window is closing. Overrides:

Parameters :

username - the user name password - the password enterpriselD - the enterpriselD public COUser(String username,

String password,

String enterpriselD,

String timeZone)

Creates a COUser with the given username and password

Parameters :

username - the user name password - the password enterpriselD - the enterpriselD ' timeZone - the timeZone

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-112public COUser(int uid,

String username,

String password)

Creates a COUser with the.given username and password

Parameters :

uid - the numeric user id username - the user name password - the password public int getUIDO

Returns the user ID number.

Returns :

the user ID number public String getUserName()

Returns the user name

Returns:

the user name

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-113public String getPassword()

Returns the user password.

. Returns:

the user password public String getEnterpriselD()

Returns the enterpriselD.

Returns :

the enterpriselD public String getTimeZone()

Returns the timeZone.

Returns :

the timeZone . public Vector getEntitlements()

Returns the application entitlements

Returns:

a collection of application entitlements ·

public Vector getUserProfile()

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-114Returns the·user profile.

Returns :

. the user profile public void setPassword(String password)

Sets the user password

Parameters:

password - the user password public void setEnterpriselD(String enterpriselD)

Sets the enterpriselD

Parameters:

enterpriselD - the enterpriselD public void setTimeZone(String timeZone)

Sets the timeZone

Parameters :

timeZone - the timeZone public void setEntitlements(Vector entitlements)

Sets the entitlements for this user Parameters:

SUBSTITUTE SHEET (RULE 26)

WO 99/15984

PCT/US98/20095

-115entitlements - the entitlements public void setUserProfile(Vector userProfile) . Sets the user profile

Parameters :

userProfile - the user profile

SUBSTITUTE SHEET (RULE 26)

Contents324

Citations
Document	Relation	Office	Cited during
US5671354A	Cites	United States of America	Search report

120 members in 7 offices

This recordMember, by publication datePriority claim

Priority claims2

Priority claims
Document	Office	Kind	Date
6065597	United States of America	P	1997-09-26
9820095	United States of America	W	1998-09-25

Members120

Family members, oldest first
Document	Office	Kind
US5610915A	United States of America	A	1997-03-11
WO9800784A1	World Intellectual Property Organization (WIPO)	A1	1998-01-08
AU3792997A	Australia	A	1998-01-21
US5825769A	United States of America	A	1998-10-20
CA2304554A1	Canada	A1	1999-04-01
CA2304619A1	Canada	A1	1999-04-01
WO9915950A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915960A2	World Intellectual Property Organization (WIPO)	A2	1999-04-01
WO9915974A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915975A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915977A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915978A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915979A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915984A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915988A2	World Intellectual Property Organization (WIPO)	A2	1999-04-01
WO9915989A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9915996A2	World Intellectual Property Organization (WIPO)	A2	1999-04-01
WO9916002A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9916099A2	World Intellectual Property Organization (WIPO)	A2	1999-04-01
WO9916198A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9916202A2	World Intellectual Property Organization (WIPO)	A2	1999-04-01
WO9916203A2	World Intellectual Property Organization (WIPO)	A2	1999-04-01
WO9916206A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9916207A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9916218A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
WO9916230A1	World Intellectual Property Organization (WIPO)	A1	1999-04-01
AU1062499A	Australia	A	1999-04-12
AU9582798A	Australia	A	1999-04-12
AU9582998A	Australia	A	1999-04-12
AU9583198A	Australia	A	1999-04-12
AU9583298A	Australia	A	1999-04-12
AU9583398A	Australia	A	1999-04-12
AU9583598A	Australia	A	1999-04-12
AU9583698A	Australia	A	1999-04-12
AU9584098A	Australia	A	1999-04-12
AU9666398A	Australia	A	1999-04-12
AU9667198A	Australia	A	1999-04-12
AU9667298A	Australia	A	1999-04-12
AU9667598A	Australia	A	1999-04-12
AU9667698A	Australia	A	1999-04-12
AU9667898A	Australia	A	1999-04-12
AU9667998A	Australia	A	1999-04-12
AU9668098A	Australia	A	1999-04-12
AU9777098A	Australia	A	1999-04-12
AU9777298A	Australia	A	1999-04-12
AU9777398A	Australia	A	1999-04-12
CA2304543A1	Canada	A1	1999-04-22
WO9919803A1	World Intellectual Property Organization (WIPO)	A1	1999-04-22
AU9668298A	Australia	A	1999-05-03
WO9915960A3	World Intellectual Property Organization (WIPO)	A3	1999-05-20
WO9915996A3	World Intellectual Property Organization (WIPO)	A3	1999-05-20
WO9916099A3	World Intellectual Property Organization (WIPO)	A3	1999-05-20
WO9915989A9	World Intellectual Property Organization (WIPO)	A9	1999-08-26
WO9916203A3	World Intellectual Property Organization (WIPO)	A3	1999-10-07
WO9915979A9	World Intellectual Property Organization (WIPO)	A9	1999-10-14
WO9915988A3	World Intellectual Property Organization (WIPO)	A3	1999-10-28
US6032184A	United States of America	A	2000-02-29
EP1015970A2	European Patent Office (EPO)	A2	2000-07-05
EP1015986A1	European Patent Office (EPO)	A1	2000-07-05
EP1015995A1	European Patent Office (EPO)	A1	2000-07-05
US6115040A	United States of America	A	2000-09-05
US6141777A	United States of America	A	2000-10-31
BR9814050A	Brazil	A	2001-11-13
BR9814049A	Brazil	A	2001-11-20
US2001052013A1	United States of America	A1	2001-12-13
BR9814046A	Brazil	A	2002-01-02
US6377993B1	United States of America	B1	2002-04-23
US6381644B2	United States of America	B2	2002-04-30
US6385644B1	United States of America	B1	2002-05-07
US2002054587A1	United States of America	A1	2002-05-09
US2002087383A1	United States of America	A1	2002-07-04
AU752622B2This record	Australia	B2	2002-09-26
AU753269B2	Australia	B2	2002-10-10
US6470386B1	United States of America	B1	2002-10-22
US6473407B1	United States of America	B1	2002-10-29
US6490620B1	United States of America	B1	2002-12-03
AU755614B2	Australia	B2	2002-12-19
US6515968B1	United States of America	B1	2003-02-04
US2003041263A1	United States of America	A1	2003-02-27
US6574661B1	United States of America	B1	2003-06-03
US6587836B1	United States of America	B1	2003-07-01
JP2003522342A	Japan	A	2003-07-22
US6598167B2	United States of America	B2	2003-07-22
EP1015986A4	European Patent Office (EPO)	A4	2003-07-23
EP1015970A4	European Patent Office (EPO)	A4	2003-07-30
EP1015995A4	European Patent Office (EPO)	A4	2003-07-30
US6606708B1	United States of America	B1	2003-08-12
JP2003525475A	Japan	A	2003-08-26
US6611498B1	United States of America	B1	2003-08-26
JP2003526126A	Japan	A	2003-09-02
US6615258B1	United States of America	B1	2003-09-02
US6631402B1	United States of America	B1	2003-10-07
US2003191970A1	United States of America	A1	2003-10-09
US2004019808A1	United States of America	A1	2004-01-29
US6714979B1	United States of America	B1	2004-03-30
US6745229B1	United States of America	B1	2004-06-01
US6763376B1	United States of America	B1	2004-07-13
US2004193512A1	United States of America	A1	2004-09-30
US6859783B2	United States of America	B2	2005-02-22
US2005114712A1	United States of America	A1	2005-05-26

Showing 100 of 120