0
`United States Patent
`
`[19]
`
`I|||||||||||l||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`USU(l(){l92l 14A
`
`[11] Patent Number:
`
`6,092,114
`
`Shaffer et al.
`
`[45] Date of Patent:
`
`Jul. 18, 2000
`
`[S4] METHOI) AND SYSTEM FOR
`])[.;'r[.;RM[N|N(; ']‘H[1:]'().CA'[‘]()NIa‘()R
`PERFORMING F1LE.1r0RMAT
`
`CONVERSIONS OF ELICCTRONICS
`MESSAGE ATTACHMENTS
`
`[75]
`
`Invenlors: Shmuel Shafier, Palo Alla; Wlllialn
`Joseph Haydn, Cupenino; pm”
`Bunumu‘ San Jose’ all of (_-am:
`
`[733 Aggigncc; Siemens I|1fnr|'“a[i;}|1 and
`Con'[n'[unicfltign N;-gwm-ks, Inc" Bgca
`Rakjn’ [~']a_
`
`[21] Appl_ No_: 09m625294
`
`Apr. 17., 1998
`
`[22
`-
`
`[56]
`
`Filed:
`.
`.
`_
`,
`. 7
`"""""""""""""""“ G06] 15_‘”6’ E06?‘ 1739
`Int: L!’
`.............................. 709E232,
`'r'(l9;‘_46,77(l7f];
`[5._| U.!s. Ll.
`.
`07"!“
`[58]
`Fleld of Search ..................................... 7U9_f§3'%;l241f:3
`-
`.
`References cued
`U_S_ PATENT DOCUMENTS
`
`5,326,'[||52
`5.845.282
`$303,723
`
`lUx'l0¢)8 Fake cl al.
`l2Il998 Alleyetal.
`$1999 Beck cl al.
`
`............................ ..
`‘H19,-"2l.|(fi
`
`.. TOTHU
`............................ .. TIFJIZOD
`
`. L-
`‘
`,
`v
`.1.-.
`P -
`r:rna:'_} -Jlmmmr—Kr1sna
`1m
`[57]
`ABSTRACT
`1
`_
`A melhod and syslem for exchan-glng-eleclronic messages,
`such as email messages. mclllde 1solal|ngpcrsonalcompul-
`ers and other client devices lrom the process. of converling
`
`a message alrachmcnl from one file formal to a second file
`tormal. File-Iormal CCIHVCISIGHS are out-tasked lo enhance
`lllc accessibilily, free computer resources, and conserve a
`user’s time. The access requiremenls of each attach rnenl to
`elcclronic messages are compared [0 [he capabililies of a
`larget clienl device. If il
`is delermined that a file-fornmt
`conversion is required, the conversion operalion is assigned
`to a server that supports Ihe process of reformatting lhc
`allachmenbs. In an email environmenl, lhe server is substan-
`“any cquivalcm 10 the Conventional email Sew“, but
`iIl(.'l1l(lU$ enhanced conversion capabililies.
`In one
`umbodimcmg lhc dulcrminmion of whclhcr an auachmcm is
`accessible wilhoul conversion occurs al the server level. In
`anolher embotlimenl, the Llelerminalion is irnplernenled at
`lhe client device level. Preferably, ll" 21 local email sewer is
`incapable of relormalting lhe allachmenl, a requesl is [rans-
`mlllcd lo :1
`remote server lo perform the Conversion.
`Typically, lhc remote server is lhc email server Ihal supports
`,
`.
`,.
`.
`-
`-
`.
`. _
`mcieage LXCl1<'.lI1gL!9 for the person who onglnated the mess
`”“’="'
`
`20 Claims, 3 Drawing Slleets
`
`'sl'-
`
`---------------------
`
`JR 0|
`fflggg
`on awa
`_,.'
`_mw238
`jug‘)? Tang el al_
`rowzrn
`sues-7 Olorii
`TFDQ,-"2[.l(:
`ll},»’l9‘1".-' RE:-I10, Il
`651 993 Kuzma .................................. .. 7013232
`
`
`
`3,) _,
`5h3m,bn
`5.032.013
`5,675,507
`5,7?1.355
`
`/10
`
`32
`
`
`
`FORMAT
`CONVERTER
`
`APPLICATION
`REGISTER
`
`
`FORMAT
`
`CONVERTER
`
`12
`
`LOCAL
`ROUTEWSERVER
`
`
`
`
`REMOTE
`ROUTERISERVER
`
`Apple/Twitter
`Apple/Twitter
`Ex. 1011
`Ex. 1011
`IPR2 of U.S. Pat. No. 8,612,515
`IPR2 of U.S. Pat. No. 8,612,515
`
`

`
`U.S. Patent
`
`Jul. 18, 2000
`
`Sheet 1 of 3
`
`6,092,114
`
`8SK.
`
`Eosmm
`
`E>E£$:5m
`
`#53
`
`E>$@$5om
`
`mm
`
`Ezmom
`
`EEm>_,_8
`
`
`
`_,_o:S:&<E_>_mE
`
`$5.8mE:m>zoo
`
`
`
`

`
`U.S. Patent
`
`Jul. 18,2000
`
`Sheet 2 MB
`
`6,092,114
`
`ATTACH A FILE TO A MESSAGE
`
`TRANSMIT MESSAGE
`
`FROM REMOTE DEVICE
`
`RECEIVE MESSAGE AT THE
`
`LOCAL SERVER
`
`CHECK FILE FORMAT
`
`OF THE ATTACHMENT
`
`CHECK ACCESS CAPABILITIES
`OF TARGET CLIENT
`
`-< rn CD .r=-0':
`
`COMPATIBLE?
`
`CO C‘)
`
`C0 00
`
`J3- |\3
`
`-914:--I=-(:3
`
`NO
`
`U‘! (D
`
`52
`
`LOCALLY
`CONVERTIBLE?
`
`-< IT: (/3
`
`CONVERT FILE
`FORMAT
`
`NO
`
`TRANSMIT REQUEST
`TO REMOTE SERVER
`
`RECEIVE MESSAGE WITH
`
`CONVERTED ATTACHMENT
`
`54
`
`U"! U?
`
`TRANSMIT MESSAGE TO CLIENT
`
`FIG. 2
`
`

`
`U.S. Patent
`
`Jul. 13, 2000
`
`Sheet 3 MB
`
`6,092,114
`
`ATTACH A FILE TO A MESSAGE
`
`36
`
`TRANSMIT MESSAGE FROM
`
`REMOTE DEVICE
`
`RECEIVE MESSAGE AT THE
`LOCAL SERVER
`
`TRANSMIT MESSAGE TO CLIENT
`
`CHECK FILE FORMAT AT THE CLIENT
`
`38
`
`40
`
`58
`
`50
`
`YES
`
`62
`
`DIRECTLY
`
`ACCESSIBLE?
`
`NO
`
`66
`
`TRANSMIT REQUEST TO
`
`THE LOCAL SERVER
`
`68
`
`70
`
`LOCALLY
`
`YES
`
`CONVERT FILE
`
`FORMAT
`
`
`
`54
`
`CONVERTIBLE?
`
`TRANSMIT REQUEST TO
`
`REMOTE SERVER
`
`RECEIVE MESSAGE WITH
`
`CONVERTED ATTACHMENT
`
`TRANSMIT MESSAGE TO CLIENT
`
`ACCESS ATTACHMENT AT CLIENT
`
`
`
`FIG. 3
`
`

`
`6,092,114
`
`1
`METHOI) AND SYSTEM FOR
`DETERMINING THE LOCATION FOR
`Pl£RI*‘ORMIN(} FII.E-F()RMAT
`CONVERSIONS OF ELECTRONICS
`MESSAGE ATTACHMENTS
`
`BACKGROUND OF THE INVl:‘N'l'l0N
`
`The invention relates generally to message delivery sys-
`tems and more particularly to methods and systems for
`providing compatibility between file attachments of the
`messages and resource capabilities of devices to which the
`messages are directed.
`DESCRIPTION OF THE RELATED ART
`
`the exchange of text messages
`Systems that support
`among users often allow files to be attached to messages. As
`one example, electronic mail
`(i.e., email) may have an
`attachment that is a word processing document, or an audio,
`video or graphics file. As another example, a download of a
`message from a web site on the World Wide Web may
`include an attached text file in Hypertext Markup Language
`(1-ITML) or an attached audio, video or graphics file.
`Messages may be transmitted from a sending client device
`(such as a computer} or from a remote server (such as a web
`server} to a message transport server that supports a corn-
`ptlter or other client device at which the receiving party
`attempts to access the message. In an email environment, a
`sending party may generate an email message at a lirst
`computer that transmits the message to a first email server.
`If the first email server does not support message access for
`the party to whom the message is directed, the first email
`server forwards the message to a second email server that
`supports access by the receiving party. The message is stored
`at the second server for download by the receiving party.
`Such message exchange systems operate seamlessly for
`messages that do not
`include file attachments, since the
`systems are designed for sending embedded text. Email is
`basically an ASCII text system. Difliculties arise when a
`message includes an attached lile. Seamless access to the
`attached file may be inhibited by decoding-specific require-
`ments or application-specific requirements upon the receiv-
`ing client device. Regarding the decoding—specific
`requirements, attached files are typically encoded to accom-
`modate transmission within a network, such as the Internet.
`There are different available protocols for accomplishing the
`encoding. One such protocol is Multimedia Internet Mail
`Extensions (MIME), which converts the attached files to text
`and sends the convened text within the message. The
`converted text is then reconverted to its original form at the
`receiving client device. Other well known standards include
`UUencode and BinHex. At the receiving client device, the
`same encoding standard must be used to decode the attached
`file, if the file is to be accessed.
`the
`Even if the attached tile is properly decoded at
`receiving client device, the file will not be accessible unless
`the client device has the required application program for
`opening the attached file. Typically, an attachment has a file
`format that is specific to an application. For example, an
`email attachment of a word processing text
`file may be
`specific to a particular word processing program. Access to
`the text
`is possible only if the receiving client device
`includes the program or has the capability of converting the
`decoded lile to another file format that is accessible. Video,
`audio and graphics files typically have more exacting
`demands. For example, an AVI video formatted file is not
`converted to a MPEG video formatted file without signifi-
`
`ll!
`
`15
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`cantly more complexity than the process ol’ converting from
`one application-specific word processing lile format
`to a
`second application-specific word processing file format.
`Many client devices have the capability of converting
`attachments from a
`limited number of inaccessible file
`formats to an acceptable me format. if the attachment is a
`relatively short word processing document, this capability is
`all that is required for eflicient display of the document at the
`receiving client device. Ilowever, if the attached file is large,
`such as an intra-corporation multimedia presentation of a
`new product release, the required time to convert the attach-
`ment between iile formats may lead to a significant inelli-
`cient use of the time of corporate personnel. Particularly in
`the conversion of multimedia file attachments, a complex
`algorithm must be utilized.
`is received that requires an
`Thus, if a file attachment
`application that
`is “l'oreign” to the receiving computing
`device, the lirst issue is whether the computing device is
`capable of converting the attachment to an accessible tile
`format. Asecond issue relates to the time requirements ol’ the
`conversion process,
`if a conversion is executable. A third
`issue relates to the reliability of the conversion operation.
`Often, the conversion causes data loss.
`What is needed is a messaging method and system that
`provide an efficient and reliable exchange of attached liles in
`a multi-application environment.
`SUMMARY OF THE INVENTION
`
`A method and system for exchanging electronic
`messages, such as email messages, include out-tasking con-
`versions of file formats when it is determined that a client
`device does not include the resources to directly access an
`attachment without conversion. The access requirements of
`each attachment to electronic messages are compared to the
`capabilities of the client device to which the attachment is to
`be transferred. If it is detennined that a file-format conver-
`sion is required, the conversion operation is assigned to a
`server that supports the process of reformatting the attach-
`ment. In an email environment, the server may be substan-
`tially equivalent
`to the conventional email server, but
`includes enhanced conversion capabilities.
`In one embodiment,
`the determination of whether an
`attachment
`is accessible without conversion by a target
`client device occurs at the server. One means of enabling the
`server to execute the determination is to maintain a universal
`register of applications at the server. The universal register
`may be a lookup table that
`identities each application
`program stored at each client device supported by the server.
`The lookup table may also include data that matches each
`user (i.e., potential recipient} with a client device at which
`the user typically accesses messages (eg,
`a
`target
`computer). When a message is received at the server, the file
`format of any attachment is identified. In its simplest form,
`this is accomplished by looking at the file extension (e.g.,
`.BMt’ identities a bitmap graphics format and .Ml’E(J indi-
`cates a specific video format). Alternatively,
`the format
`indicator may be embedded by the sending party within the
`message that includes the attachment. As a third possibility,
`the server may access each attachment in order to identify its
`file format. If a
`file-format conversion is necessary,
`the
`conversion can be implemented at the server, thereby freeing
`resources and processing time at the target client device. In
`this embodiment, the conversion may be transparent to the
`receiving party.
`In another embodiment, the determination of whether an
`attachment
`is accessible without conversion occurs at the
`
`

`
`6,092,114
`
`3
`target client device. Conventionally, computers include a
`register of applications that are stored in memory. Such an
`application register may be used to automatically check
`attachment accessibility. If the client device is unable to
`access the attachment without conversion, a request may be
`transmitted to the server to perform the conversion. Many
`server protocols allow messages to be left on the server for
`a period of time after a download to a target client device
`(e.g., Post Olfice Protocol-l’()I’3). Thus, it is not necessary
`to upload the attachment in order to allow the conversion at
`the server. Following the conversion to a directly accessible
`File format, the attachment is again downloaded to the target
`client device.
`
`III
`
`15
`
`The out-tasking of the conversion operation to the local
`server may be utilized even if the target client device is
`capable of the llle-format conversion. By executing the
`conversion at the server, the process is completed ofl‘-line
`with respect to the user and the user’s client device. This
`frees the resources of the client device to perform other tasks
`and often saves time for the user.
`However. if neither the client device nor the local server
`is capable of performing the necessary conversion to allow
`file access by the target client device, the invention prefer-
`ably includes a step of transmitting a request to a remote
`server to perform the conversion. Typically,
`the remote *
`server is the message server that supports the exchange of
`messages for the person who originated the message having
`the attachment
`that
`requires conversion.
`In another
`embodiment, the server is maintained by an independent
`entity. For occasions in which the remote server is capable
`of converting the attachment, the format-converted file is
`returned to the local server for access by the recipient user.
`On the other hand, if the remote server cannot perform the
`conversion, the conversion request may he passed to the
`sending client device, attempting to trigger an automatic
`conversion andfor notifying the sender that this attachment
`was not accessed by the intended receiver.
`
`30
`
`35
`
`BRIE!’ DlESCRIP'I'I(JN OI? TIIIE DRAWINGS
`
`is a schematic view of one embodiment of a
`1
`FIG.
`message exchange system that provides file-format conver-
`sion in accordance with the invention.
`
`FIG. 2 is a process flow of one embodiment for carrying
`out the conversion process in the system of FIG. 1.
`FIG. 3 is a second embodiment ofa conversion process in
`accordance with the invention.
`
`DETAILED DESCRIPTION
`
`With reference to FIG. 1, a messaging system 10 is shown
`as including :1 local routerfscrver 12 for supporting access to
`stored messages by a number ofclient devices 14, 16 and 18.
`The routing operations of the routerlserver 12 are not the
`primary focus of the messaging system and method.
`Therefore, the routerfserver will be identified primarily as
`the local server. The structure of the server is not critical to
`the invention. Conventional message servers are used to
`store received messages and to provide access to the stored
`messages upon verification of a user identity. Such identi-
`fication generally requires input of a password that
`is
`specific to the user.
`The messaging system 10 may be used to exchange
`messages of any one of a variety of message types. For
`example, the messages may be downloads from a web site
`ofthe World Wide Wet), so that a link 20 to a network 22 is
`a connection to the global communications network referred
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`to as the Internet. However. the system and method will be
`described primarily with respect to the preferred embodi-
`ment ofexchanging email messages having file attachments.
`As is well known in the art, a person at a remote client
`device 24 may transmit an email message to a person who
`accesses email via the local server 12. The email message
`may be routed from the routerfserver 26 of the remote client
`device to the local server 12 via two communication links 20
`and 28 to the network 22. The email message may be
`accessed by the target user using any of the supported client
`devices 14, 16 and 18.
`In an Internet application of the system and method of
`exchanging email, the local and remote routerflscrvers l2 and
`26 are Internet Service Providers (ISPS). It is not critical that
`the sending and receiving client devices subscribe to ditfer-
`ent [SI’s. That is, the method to be described below may be
`utilized to provide lile-format conversion of an attachment
`to a message sent from one of the local client devices [4, 16
`and 18 to another one of the local client devices.
`
`The invention may also be used in a local area network or
`wide area network environment. For example, the network
`22 may be a corporate network of a single company having
`one or more sites.
`
`One concern in the exchange of electronic messages, such
`as email. is that attachments may have access requirements
`that are not within the immediate capabilities of a receiving
`client device 14, I6 and 18. For example, access to a video
`file that
`is attached to an email message may have a tile
`format
`that requires a receiving client device to have a
`specific application program, such as an MPEG player. If the
`receiving device does not include the necessary program,
`direct access is typically not possible. Thus,
`there is a
`possibility that the target user will not be able to display the
`attachment. Many client devices have programs with the
`capability of converting attachments from a limited number
`of inaccessible file formats to an acceptable tile format. A
`word processing document may be elliciently converted.
`However,
`if the attached file is large, such as an intra-
`corporation multimedia presentation of a new product
`release, the conversion process is likely to be time consum-
`ing. The process may dominate the resources of the client
`device, preventing a user from efficiently utilizing his or her
`time.
`
`The messaging system 10 of FIG. I provides an improve-
`ment ovcr the conventional system by providing a format
`converter 30 at
`the server level. Consequently,
`if it
`is
`determined that a file attachment to an electronic message
`includes an attachment
`that cannot be accessed without
`
`file-format conversion by the target client device 14, 16 and
`18, the conversion process may be out-tasked to the format
`converter 30. If the determination of the capabilities of the
`target client device occurs at the server level. the resources
`of the target device remain free during the entire process.
`That
`is, by providing a liormat check and a capability
`comparison at the local server 12, the process occurs while
`the target client device is off-line and the process is executed
`in a manner that is transparent to the target device. In this
`server-level embodiment, an application register 34 is uti-
`lized by the local server to monitor the access capabilities of
`each client device, as will be explained more fully below.
`The client devices may be individually polled to determine
`which file formats are accessible without conversion.
`Alternatively,
`the client devices may be programmed to
`provide updates regarding their capabilities.
`In another embodiment, the format check and the capa-
`bility comparison occurs at the target client device 14. 16
`
`

`
`6,092,114
`
`5
`and 18 at which the receiving party accesses the electronic
`message stored at the local server 12. If it is determined that
`the message attachment is inaccessible without conversion,
`a request is transmitted to the local server 12 to file—format
`convert the attachment at the converter 30. For example, a
`special protocol element
`1’ may be sent
`to request
`the
`conversion. Often, downloading an electronic message to a
`client device does not delete the storage of the message from
`the local server. For example, email servers based on the
`standard POP3 (Post Ollice Protocol) maintain a copy after
`download to a target client device. Thus. it is not necessary
`to upload the message to the local server 12 for conversion
`by the format converter 30.
`If the format converter 30 of the local server 12 is unable
`to convert the attached file, the message can he sent to the
`remote routerfs-erver 26 from which the message was origi-
`nally received. This may be necessary when the file format
`is unrecognized at the local server 12 and format converter
`30. As another possibility, the format converter may not have
`the programming algorithm for convening an attachment
`having a particular file fomtat.
`In the embodiment in which the compatibility comparison
`occurs at the client device level (rather than the server level),
`the special protocol element P that was originally generated
`at the target client device 14, 16 and 18 may be forwarded *
`from the local server L2 to the sending remote routerfserver
`26 to request the necessary manipulation of the attachment
`that is not locally convertible. The remote routerfserver 26 is
`connected to a second format converter 32. If the second
`format converter is capable of placing the attachment in a
`file format that is accessible by the target client device, the
`file format can be changed and the message can be retrans-
`mitted to the local server 12 for subsequent access by the
`target client device.
`(Jn the other hand,
`if the remote
`conversion is not successful, the routertserver 26 can return
`the message to the original client device 24.
`In some
`applications, the original client device may be automatically
`triggered to attempt
`to locally convert
`the attachment.
`llowever, in typical applications, the message to the origi-
`nating client device 24 is an infomtational message that the
`target client device was unable to read the attachment, so
`that the attachment should be resent in an accessible format.
`
`ll!
`
`15
`
`30
`
`35
`
`40
`
`The protocol elements and messages described above can
`be designed and implemented in a manner in which they are
`buried in text fonnat within the electronic message. Thus,
`any intermediary servers are unlikely to recognize the con-
`version requests. If the protocol message is human readable.
`it can arrive at
`the sender's message box of the remote
`routerfserver 26 for subsequent viewing by the sender.
`In the embodiment of FIG. 1, the client devices 14,16. 18
`and 24 are shown as being computers. However, this is not
`critical. In the email application, the client devices may be
`any device that is used to access email, either by means of
`wired transmission or wireless transmission.
`
`The attachments to the messages may be simple word
`processing documents. However,
`the invention is more
`benelicial if the conversion complexity and time consump-
`tion are greater than the complexity and time consumption
`typically associated with converting a word processing
`document. For example,
`the attachment may he audio
`embedded into an email message, with the audio file requir-
`ing a specific player. In other examples, the attachments may
`be video files or graphic files or a multimedia presentation.
`The application in which the format check of an attach-
`ment and the access-capability assessment occur at
`the
`server level will be described with reference to FIGS. 1 and
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`2. In a lirst step 36, a lile is attached to an electronic
`message. In the preferred embodiment, the message is an
`email message having a file attachment. With reference to
`FIG. 1, step 36 may he executed at the remote client device
`24.
`
`In step 38, the electronic message is transmitted from the
`remote client device 24 to the local server 12.. At step 40, the
`local server receives the message and preferably stores the
`message in memory, using techniques well known in the art.
`For example, each subscriber of an ISP is assigned an email
`mailbox into which messages directed to the subscribe!’ are
`stored. The mailbox system is carried out in software. A
`similar system is implemented within a corporate environ-
`ment
`in which email and other electronic messages are
`exchanged within a corporate firewall. Thus, the message
`and attachment may be generated at one of the local client
`devices 14, 16 and 18 for access at another local client
`device.
`
`In step 42, the lite format of the attachment is identified
`at the server level. In its simplest form, this may merely be
`a check of the file extension of the attachment. For example,
`.BMP identifies a bitmap graphics format and .Ml-"l:lG iden-
`tifics a specific video format. As another format indicator,
`there may be an identifier that is intentionally embedded by
`the sending party within the message to indicate the tile
`format of the attachment. As a third alternative, the server
`may attempt to access the attachment in order to identify its
`file format. Other approaches to checking the tile format
`may also be implemented.
`At step 44,
`the access capabilities of the target client
`device 14, 16 and 18 are determined. Referring to FIG. 1, an
`application register 34 may be maintained at the server level.
`As is well known in the art, computers typically maintain an
`application register of programs stored at the computer. 'I'l'tc
`application register 34 of FIG. 2 may be considered to be a
`universal application register that identifies all of the access
`capabilities of various client devices that are used to access
`email stored at the local server 12. In one embodiment, the
`application register is maintained as a lookup table. When a
`client device is lirst used to access email stored at the local
`
`the client device is polled to identify its access
`server.
`capabilities. The polling process may also be used to peri-
`odically update a lookup table that
`is compiled within
`memory of the server or within memory of an adjunct
`device. While the format converter 30 and the application
`register 34 are shown as being connected to the local server
`12,
`the operations of the converter and register may be
`integrated into known servers. As an alternative to the
`polling approach, the client devices 14, 16 and 18 may be
`programmed to identify their individual access capabilities
`each time that a program is upgraded or added to the client
`device.
`
`is determined whether the attachment is
`it
`At step -1-6,
`accessible at the target client device without conversion. If
`the attachment is accessible without conversion, the mes-
`sage is transmitted to the target client at step 48. This
`transmission is a conventional download step and its execu-
`tion is not critical
`to the invention. Optionally,
`if it
`is
`determined that
`the attachment
`is inaccessible without
`conversion, the message may nevertheless be transmitted to
`the client, if there is a determination that the conversion is
`neither complex nor time consuming. For example, a short
`word processing document may be forwarded to the target
`client device despite a conversion requirement.
`ll‘ at step 46 it is determined that there is an incompat-
`ibility between the access requirements of the attachment
`
`

`
`6,092,114
`
`ill
`
`15
`
`7
`and the direct access capabilities of the target client device,
`the process proceeds to step 50 for a determination of
`whether the attachment is locally convertible. If the attach-
`ment is locally convertible, the file—format change is imple-
`mented at step 52 and the message is made accessible to the
`target client device at step 48. Preferably, the checking steps
`42 and 44,
`the determining steps 46 and 50, and the
`conversion step 52 are implemented without intervention by
`the target client device. Thus, the process occurs “off-line"
`with respect to the target client device. This frees the client
`device to operate in other capacities.
`The file format conversion at step 52 is executed using
`known techniques. Conventionally, computer software is
`utilized to change an attachment from one file format
`to
`another. However, if the format converter 30 of FIG. I is
`incapable of providing the conversion, because the file
`format is unrecognizable or because the format converter is
`not programmed to provide a particular conversion,
`the
`conclusion at step 52 is that the attachment is not locally
`convertible. In this situation, a request
`is generated and
`transmitted from the local server 12 to the sending remote
`routeriserver 26. The request includes instructions to convert
`the attachment to an accessible file format. For example, at
`step 54, a special protocol element 1’ may be generated and
`transmitted to the remote server to determine whether the
`remote format converter 32 has capabilities beyond that of “
`the local system.
`Ideally, at step 56.
`the attachment
`is
`reformatted remotely and the local server 12 receives the
`message with a converted attachment, which is made avail-
`able to the target client device at step 48. However, if neither
`the local system nor the remote system is capable of pro-
`viding an accessible attachment, the protocol message may
`be forwarded to the originating client device 24. As previ-
`ously noted, the forwarded protocol message may be used
`merely to inform the sending party that the attachment was
`not received and displayed at a client device. Alternatively,
`the protocol message may be formatted to trigger an auto-
`matic conversion and retransmission ofthe attachment in an
`alternative file format.
`
`30
`
`35
`
`Reference will be made to FIGS. 1 and 3 in describing the
`embodiment in which the format check and the access-
`capability determination occur at the target client device 14,
`16 and 18. Steps 36, 38 and 40 are identical to the process
`described with reference to FIG. 2. Thus. a file is attached to
`a message at a sending client device 24 and the message is
`received at the local server 12. The message is stored for
`access by the user at one of the local client devices 14, 16
`and 18. When access is requested, the message is transmitted
`to the client device at step 58.
`A file fonnat check occurs at the target client device in
`step 60. Some of the possible approaches to performing the
`check were described with reference to step 42 in FIG. 2. For
`example, the format check may merely be an identification
`of the tile extension.
`
`After the file format has been identified, in step 62 it is
`determined whether the attachment
`is directly accessible,
`i.e., whether the attachment is accessible without conver-
`sion. If the attachment
`is directly accessible,
`the file is
`displayed at step 64. On the other hand, a determination that
`the attachment is inaccessible without conversion triggers a
`transmission of a request to the local server l2 at step 66.
`The request may be the above-identified protocol element F.
`The request includes instructions to convert the attachment
`to a particular accessible file format.
`In the determination step 68, the ability of performing the
`requested manipulation at the format converter 30 is ascer-
`tained. If the ability exists, the process is implemented at
`step 70. Preferably,
`the message and attachment remain
`stored at the local server. so that the conversion can take
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`place without an upload of the message from the target client
`device to the local server. Following the lile-format change
`at step 70,
`the message is again accessible to the client
`device at step 72, but with the attachment in a directly
`accessible file format.
`
`a negative
`Returning to the determination step 68,
`response to the capability of executing a local conversion
`will
`trigger a
`transmission of a request
`to the remote
`routerlserver 26 from which the message was received. This
`is shown at step 74. if the remote format converter 32 is
`capable of performing the requested reformatting operation,
`the reformatted attachment is transmitted to the local server
`12 at step 76. The reformatted attachment may then be
`transmitted to the target client device at step 72 for display
`at step 64. On the other hand, if the reformatting operation
`cannot be executed, the request is forwarded to the origi-
`nating client device 24. As previously noted, this request
`may merely be informational or may be used to automati-
`cally trigger a desired operation at the remote client device,
`such as a reformatting operation. The protocol message can
`be designed in a way that the protocol element P is buried
`in text format in an email message that is human readable,
`so that intermediary servers do not recognize the conversion
`request as the request is forwarded to the sender’s server.
`While the invention has been described primarily with
`respect
`to email
`transmissions,
`this is not critical. The
`system and method may be used in other applications.
`Moreover, it is anticipated that servers will be dedicated to
`the attachment conversion. Web sites may also performs
`these functions, so that unresolved requests for conversion
`may be sent to a conversion service that is outside of the
`sender-t0—receiver transmission path. That
`is,
`the format
`converter 30 may be maintained by a private company that
`provides service to subscribing companies or individuals.
`What is claimed is:
`
`1. A method of providing message exchange capability for
`a plurality of users comprising steps of:
`receiving electronic messages at a server that supports
`message access by said users, including receiving first
`electronic messages having attachments in file formats
`that are each specific to one of a plurality of applica-
`tions;
`identifying capabilities. of client devices with respect to
`accessing said attachments without conversion from an
`original file format to a second file for