WO2002017068A2

WO2002017068A2 - Method and apparatus for remote execution of an application with local display and control

Info

Publication number: WO2002017068A2
Application number: PCT/US2001/026121
Authority: WO
Inventors: Joe Wallace Duran; Ann Marie Laubach; Lawrence Seligman
Original assignee: Motorola, Inc.
Priority date: 2000-08-23
Filing date: 2001-08-21
Publication date: 2002-02-28
Also published as: EP1360581A2; AU2001285158A1; WO2002017068A3

Abstract

The present invention allows users to keep local copies of files received, such as email messages, and to invoke remote server-resident application software as necessary in order to open and read various files sent as attachments to email messages.

Description

METHOD AND APPARATUS FOR REMOTE EXECUTION OF AN APPLICATION WITH LOCAL DISPLAY AND CONTROL

Field of the Invention

The present invention is related in general to communication systems, and more particularly to an improved method and system for remote execution of an application with local display and control.

Background of the Invention

Many new computing devices and personal digital assistants (PDAs), such as those using the Windows CE operating system, are capable of receiving all of a user' s normal email, but are not capable of the computing necessary to open and manipulate all of the attachments that are frequently included with an email message. For instance, a user of even recent versions of Windows CE "sub-notebooks" can not open, view, or edit a Microsoft PowerPoint file attached to an email message.

Further, Windows CE and Palm Pilot devices owe much of their value to their portability, which is greatly enhanced by wireless internet connections. These connections are inherently slower than most wireline connections, so downloading an email attachment, such as a typical PowerPoint file of 500 KB or greater, can be quite time consuming, especially when the connection is through a lower bandwidth wireless WAN service such as Cellular Digital Packet Data (CDPD). Any technique that can allow users to view, edit, and otherwise manipulate such attachments without actually downloading the attachment may be of great benefit.

"Thin client" techniques for remote execution of computer programs while the results are viewed locally are in common use. Products such as PC anywhere from Symantec Corporation, Unix X-Windows, and Citrix MetaFrame provide the capability of using one computer as the screen and keyboard for another, remotely located computer. These products are often called "thin client" because the client computer contains a relatively small amount of software, typically just enough to act as a remote keyboard, mouse, and display. The application software runs on a remote computer, usually a server, or the user's desktop computer. Thin client technology and wireless connectivity are useful for mobile computing because they allow a user to carry lightweight devices with long battery life, for example, hand held PCs, yet still have the ability to run virtually any application. However, since there are occasions when connections are not available, for example on airplanes, it is also desirable to have some local computing capability.

Lightweight devices incorporating operating systems such as

Windows CE or the Palm Operating System (Palm OS) are capable of running thin client software and controlling the execution of programs on a remote server. This solves the problem of downloading large files, and of being unable to view and manipulate certain hie types locally. A remote server can provide all of a user' s computing needs, including email. The user can operate the lightweight terminal device as a remote screen and keyboard to control the email software and any application programs necessary for viewing, editing, or manipulating email attachments. The drawback of operating exclusively in a thin client mode is the user has no locally stored information. When a communications link is not available, such as when on an airplane, the user does not have access to any of the data. In particular, the user cannot read, answer, or compose email while disconnected.

In addition, the prior art requires that, if a user reads his email locally and notices that it has an attachment that he wants to read, he must then open a session on a thin client server. The thin client server must contain both the necessary application software and an email client. The email client, running on the thin client server, must be configured for that user to fetch the same email message, with the attachment, from the user's mail server. He must then read the email message again, and select the attachment to open it.

It is beneficial for a user to be able to work in two modes: remotely

(via thin client) and locally. This enables him to work on large files without downloading them and to have functionality when network connections are unavailable. To make switching between the two modes simpler and faster for the user, what is needed is an improved method and apparatus for remote invocation of applications with local display and control.

Brief Description of the Drawings

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects, and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 illustrates a block diagram depicting an exemplary network layout in accordance with the method and system of the present invention;

FIG. 2 illustrates a functional flow diagram depicting the mail access server /mail copy process in accordance with the method and system of the present invention;

FIG. 3 illustrates a functional flow diagram depicting the mail access server/attachment process in accordance with the method and system of the present invention; and

FIG. 4 illustrates a functional flow diagram depicting the intelligent application manager on the client device invoked when the user selects an email attachment in accordance with the method and system of the present invention.

Detailed Description of the Preferred Embodiment

Referring now to the drawings, and in particular FIG. 1, a block diagram depicting an exemplary network layout in accordance with the method and system of the present invention is shown. In a preferred embodiment, when a user is sent mail with an attached file, the user may be carrying a client device 102, such as a mobile terminal, that does not contain the application software necessary to open the file. Alternatively, the user may not wish to suffer the waiting time, transmission costs, and local storage consumption needed to download the file. The present invention provides the user the opportunity to see the name, type, and size of the attached file in the usual manner, and the opportunity to select it easily for remote execution on a remote server. The user controls the file' s viewing and execution in normal thin-client fashion from the terminal being carried. That is, the user clicks on an icon representing the attached file. Software on the client device 102, in the mail access server 104, and in the application server 106, will cooperate to invoke the appropriate application software and provide to that software a link to the file' s actual storage location.

In a preferred embodiment, the user' s lightweight terminal 102, running Windows CE, contains an IMAP4 compliant email client, which the user always runs as the terminal' s local mail client. As seen in FIG. 1, client device 102, mail access server 104, application server 106, and mail server 108 are coupled to each other, preferably via communications networks such as the internet 110 and wireless WAN 112. It will be appreciated by those skilled in the art that the technique described herein will also be of benefit for users employing low bandwidth wireline connections. The present invention provides an intermediate server, or mail access server 104, preferably set up so that larger attachments are never actually downloaded to the user' s terminal 102. Rather, only their names, types, and links back to their locations on another server, such as the user' s mail server, are passed to the terminal. The user thereafter clicks on the link to read an attachment, which opens remote invocation software. The remote invocation software determines the attachment type and the required application on the application server 106, which in the preferred embodiment is a Citrix MetaFrame server, and opens communication links to the user's mail server and the desired application server .It will appreciated by those skilled in the art that thin client packages other than MetaFrame, such as Microsoft' s Windows Terminal Server, or such as techniques for using web servers to reformat files for web browsers, can also be used without departing from the spirit and scope of the present invention.

A preferred embodiment of the overall operation is as follows.

The user terminal or client 102 has a text file, named remote.ica and following the Citrix convention, contains the following entries:

#A Address=< Application Server IP address>

Domain=<user' s domain name>

Username=<user ID> Password=<encrypted password> #B InitialProgram=<application location> H:\MAILTEMP #C WorkDirectory=<Directory location>

When the client device 102 receives an email sent with an attachment, the attachment is filtered. That is, the attachment is delivered to the client device 102 only if it passes a set of rules (filters), preferably based on size and format. The filters may be predetermined, or may be customizable by the user. For instance, a 3KB Microsoft Word file typically will be delivered to the client device 102, whereas a 200KB PowerPoint file typically will not be delivered. When an attachment is not delivered, a pointer is appended to the end of the associated message. For instance, a typical message delivered to the client device 102 may look like the following:

From: Charlie Smith [mailto:CSmith@Centesxs.com] Sent: Monday, November 08, 1999 10:29 AM To: Horace Jo; Kay Buena Subject: "Set To Fail"

This guy is a regular participant in the "Studio 2000" book publishing list that I subscribe to. His business plan outline is in the attached PowerPoint File.

Regards, Charlie

onderplan.pdf .voc (0KB/2200KB)

The attached file indicator, Wonderplan.pdf .voc in the above example, indicates that an Adobe Portable Document Format (PDF) file was attached to the message, that it is 2.2 Mbytes in size, and that it was not actually delivered to the client device. The " .voc" extension is linked to the intelligent application manager program on the terminal, through the File

Associate command in Windows CE. When the user clicks on the filename, intelligent application manager program is launched on the terminal.

Preferably, the intelligent application manager program checks whether there is a local application program capable of opening the file. If so, the user is asked to select whether to download the file for local execution or to view it by remote invocation and execution. If there is no appropriate local application program, remote invocation begins immediately, in the following manner.

The actual IP address of a Citrix MetaFrame server with Adobe® Acrobat® Reader software installed is inserted as the Application Server IP address in Line #A of remote.ica above. Similarly, the location of AcroRd32.exe (the executable code for the reader) is inserted in Line #B, and the Working Directory location is inserted in Line #C. This information is obtained from the application server table maintained on the mail access server 104 and downloaded periodically to the client device 102. Table 1 below is an example.

The following is an example of an instance of remote.ica resulting from the process described above.

DesiredColor=0x0001

DesiredVRES=

DesiredHRES=

[WFClient] Version=2 ClientSN=

[ApplicationServers] FocusDummy=

[FocusDummy] Address=155.55.55.56 TransportDriver=TCP/IP inStationDriver=ICA 3.0 Domain=domainname Username=aaadams Password=111876543210987654543 InitialProgram=F: \Apps\AcroRd32. exe H: \ AILTEMP\Wonderplan. pdf Wo.rkDirectory=F: \Apps ScreenPercent=100 DesiredColor=l TAPIDevice=Off Compress=On

PersistentCacheEnabled=Off ClientAudio=Off AudioBandwidthLimit=-l

The file to be viewed (the PDF file, in this example) is copied from the mail access server 104, using well known mail protocols such as IMAP4, and placed into the MAILTEMP directory on the MetaFrame or application server 106. The application program, wficaCE.exe is then started on the client device 102 with remote.ica as its argument. This causes the Citrix ICA remote terminal software to begin running on the client, acting as a remote screen and keyboard to control the pdf reader running on the MetaFrame server, opening the file Wonderplan.pdf. The user can read and control Wonderplan.pdf. This has two advantages. First, the user is able to view the attachment without having had to download it to the client device 102, which may result in a considerable reduction in the number of bits sent to the client device 102. It also means that the user can start viewing the attachment much sooner than if he had to wait for a download to complete. Second, it means the user can view attachments for which there is no associated client software. For example, as of this writing, there is no PDF viewer available for Windows CE client devices.

FIG. 2 illustrates a functional flow diagram depicting the mail access server/mail copy process in accordance with the method and system of the present invention. As depicted in FIG. 2, at block 202, the mail server is checked for email. At block 204, a determination is made whether there is new mail. If there is not new mail, then flow proceeds to block 206 where a delay occurs and thereafter, flow reverts back to block 202. If there is new mail, then flow proceeds to block 208, wherein the email is copied. Thereafter at block 210, a determination is made whether there are any attachments. If there are not any attachments, flow proceeds to block 212, wherein the mail is sent to the client device. If there are attachments, flow proceeds to block 214, wherein the message header and text body is set up. At block 216, the attachment size is compared with a predetermined maximum attachment size, which may be user specified. At block 218, a determination is made whether the attachment size has exceeded the predetermined maximum size. If the attachment size has not exceeded the predetermined maximum size, then the file is appended to the message body at block 220. If the attachment size has exceeded the predetermined maximum size, then the pointer is appended to the message body at block 222. Thereafter, at block 224, a determination is made whether any attachments are remaining. If there are attachments remaining, flow reverts back to block 216. If no attachments remain, flow proceeds to block 226, wherein the step of processing the assembled message to make valid Multipurpose Internet Mail Extensions (MIME) is performed. Thereafter, flow proceeds to block 228 and mail is sent to the client, using well known SMTP protocols

FIG. 3 illustrates a functional flow diagram depicting the mail access server /attachment process in accordance with the method and system of the present invention. As depicted in FIG. 3, at block 302, the step of receiving the email UID and attachment name from the intelligent application manager on the client device is performed. Thereafter, at block 304, the attachment is copied from the mail server. At block 306, the file name extension of the attachment is read. Thereafter, at block 308 the extension in the application server table is located. Thereafter at block 310, a determination is made whether the extension is found. If the extension is not found, then at block 312 an error code is sent to the client. If the extension is found, then at block 314 the attachment is moved to a temporary directory on the application server containing the application program associated with the file name extension. Thereafter at block 316, an attachment copy completed indicator is sent to the client.

FIG. 4 illustrates a functional flow diagram depicting the intelligent application manager on the client device invoked when the user selects an email attachment in accordance with the method and system of the present invention. As depicted in FIG. 4, at block 402, a determination is made whether there is a local application that can open the attachment. If there is not a local application that can open the attachment, then flow proceeds to block 404 as discussed below. If there is a local application that can open the attachment, flow proceeds to block 406, wherein a determination is made whether the attachment body is stored on the device. If the attachment body is stored on the device, then at block 408 the file is opened with the application. If the attachment body is not stored on the device, then at block 410 the user is asked whether he/she wants to download the attachment. Thereafter, at block 412, the user response is determined. If the user responded yes, then at block 414 the file is download from the mail server, and at block 416, the file is opened with the application. If the user responded no, then at block 418 the mail access server is signaled to copy the attachment from the mail server to the remote application server containing the proper application. Thereafter at block 420, the system waits for a response indicating whether the attachment was copied. At block 422, a determination is made whether the attachment was copied. If the attachment was not copied, then at block 424 flow proceeds to the error handler. If the attachment was copied, then at block 426 the application server IP address and application location is inserted into the thin client configuration file. Thereafter, at block 428, the thin client software is launched.

The present invention allows users to keep local copies of email messages received, and to invoke automatically remote server-resident application software as necessary in order to open and read various files sent as attachments to email messages. That is, while reading email using a mail client resident on a lightweight terminal, the user may click on a pointer to the attached file and cause the appropriate application to be launched on the server. In this case, the pointer appears to the user to be essentially the normal name or icon that a mail system uses to indicate the presence of an attachment. The results are viewed on the terminal using the usual " thin client" methods. If the attached file has been downloaded and the application software is available locally (i.e. in the lightweight terminal), the appropriate application is launched locally. Otherwise, whenever a usable communications link is available, the application is launched on a server.

The foregoing description of a preferred embodiment of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiment was chosen and described to provide the best illustration of the principles of the invention and its practical application, and to enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly, legally, and equitably entitled.

Claims

ClaimsWhat is claimed is:

1. A method for remotely executing an application with local display and control, the method comprising the steps of:

5 receiving a request to open a file;

analyzing the file based on predetermined file characteristics; and

in response to the analysis, automatically launching one of a local application associated with the file and a remote application associated with the file.

2. The method for remotely executing an application according to claim 1, o wherein the step of analyzing includes the step of determining whether local execution of the file is appropriate.

3. The method for remotely executing an application according to claim 2, wherein the step of determining whether local execution of the file is appropriate includes at least one of the steps of:

5 determining whether there is a local application that can open the file;

determining whether the file is stored locally; and

determining whether the size of the file has exceeded a predetermined maximum size.

4. The method for remotely executing an application according to claim 3, including the step of determining whether or not to download the file from a remote server.

5. The method for remotely executing an application according to claim 4, including the step of:

based on the determination whether or not to download the file from a remote server, signaling another server to copy the file from the remote server.

6. The method for remotely executing an application according to claim 2, including the steps of:

determining the location of the application;

determining the location of the file; and

launching the application with the file, while simultaneously launching a control program on a portable device.

7. The method for remotely executing an application according to claim 6, wherein the step of launching includes the step of moving the file from one server to the server containing the application.

8. An apparatus for remotely executing an application with local display and control, the apparatus comprising:

means for receiving a request to open a file;

means for analyzing the file based on predetermined file characteristics; and

in response to the analysis, means for automatically launching one of a local application associated with the file and a remote application associated with the file.

9. The apparatus for remotely executing an application according to claim 8, wherein the means for analyzing includes means for determining whether local execution of the file is appropriate.

10. The apparatus for remotely executing an application according to claim 9, wherein the means for determining whether local execution of the file is appropriate includes at least one of:

means for determining whether there is a local application that can open the file;

means for determining whether the file is stored locally; and

means for determining whether the size of the file has exceeded a predetermined maximum size.