0
`United States Patent
`
`[19]
`
`I|||||||||||l||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`USUO()O921 14A
`
`[11] Patent Number:
`
`6,092,114
`
`Shaffer et al.
`
`[45] Date of Patent:
`
`Jul. 18, 2000
`
`5,326,'[|(i2
`5.845.282
`$303,723
`
`lU,"l0‘)8 Fake Cl al.
`l2Il998 Alleyetal.
`$1999 Buck cl al.
`
`‘TOG,-"2l.|6
`............................ .,
`
`.. TOTHU
`............................ .. TIFJIZOD
`
`. L-
`‘
`,
`v
`.1.-.
`P -
`r:rna:'_} -Jmrmmr—Kr1sna
`1m
`[SH
`ABSTRACT
`1
`_
`A melhod and syslem for exchan-glng-eleclronlc messages,
`such as email messages. mcllldc isolating personal compul-
`ers and other client devices lrorn the pmcess of convening
`
`a message allachmcnl from _0nc file formal to a second file
`tormal. File-Inrmal CCIHVCISIGHS are out-tasked lo enhance
`lllc acccssibilily, [rec computer resources, and conserve a
`user’s time. The access. requiremenls of each attach menl to
`eicclronic messages are compared In the capabililies of a
`larget clienl device. If il
`is delermined that a file-fornmt
`conversion is required, the conversion uperalion is assigned
`lT.§L§§~f§’§i.-. ‘ll?L§1‘$§'$i‘Zn$';?L.EL32§T5.E§ ».Trf$’§r”l3‘lLlil§$5
`“any cqumlcm 10 ‘ha Conventional email Scmr’ but
`inchuhs enhanced convcrfion capabflifics In one
`umbodimcmg lhc dulcrminmion of whclhcr an auachmcm is
`accessible wilhoul conversion occurs al the server level. In
`anolher embodirncnl, the Llclcrminaliun is implemenled at
`lhe client device level. Preferably, ll" 21 local email server is
`incapable of relorrnalting lhe allachmenl, a requesl is [rans-
`mlllcd 10 :1
`remote server In perform the Conversion.
`Typically, lhc rcmc-la: server is lhc email server Ihal supports
`,
`.
`,.
`.
`-
`-
`.
`. _
`message LXCi1<'.lI1gL33 for the person who originated the mess
`”“’="'
`
`20 Claims, 3 Drawing Slice-ts
`
`32
`
`
`
`FORMAT
`CONVERTER
`
`1O
`
`/
`
`[S4] MITZTHOI) ANI) SYS'['[*}M FOR
`])[.;'r[.;RM[N|N(; ']‘H[1:]'().CA'[‘]()NIa‘()R
`PERFORMING F1LE.1r0RMAT
`
`CONVERSIONS OF ELICCTRONICS
`MESSAGE ATTACHMENTS
`
`[75]
`
`Invenlors: Shmucl Shafier, Palo Alla; Willialn
`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
`Filed:
`[22
`I-"— 0-’ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ G*’6"15f16:G<'6F W3“
`I51!
`[52] us. Cl.
`.............................. 709x232; 7n9r24r;;77(:7n;
`.
`{win
`[58]
`Fleld of Search ..................................... 709E333, 246;
`0 if 1- 10
`.
`References cued
`U_S_ PATENT DOCUMENTS
`
`[56]
`
`3,) _,
`5h3m,bn
`5.032.013
`5,675,517?
`5,7?1.355
`
`'sl'-
`
`---------------------
`
`JR 0|
`fflggg
`on awa
`_,.'
`_mw238
`jug‘)? Tang el al_
`rowzrn
`snag-7 Olorii
`".-‘(T9,-"2l]fi
`ll}_e’l9‘1"." Rol1n,Il
`651 993 Kuzma .................................. .. 7013232
`
`FORMAT
`CONVERTER
`
`
`
`APPLICATION
`REGISTER
`
`
`
`12
`
`LOCAL
`ROUTERJSERVER
`
` REMOTE
`ROUTERISERVER
`
`0001
`
`Apple/Twitter
`Apple/Twitter
`Ex. 1011
`Ex. 1011
`IPR1 of U.S. Pat. No. 7,765,482
`IPR1 of U.S. Pat. No. 7,765,482
`
`0001
`
`

`
`U.S. Patent
`
`Jul. 18,2000
`
`Sheet 1 of3
`
`6,092,114
`
`NmV
`
`8%
`mm>mmwEmzbom
`.253
`
`/S
`
`ZEmoL
`
`mmEm>zoo
`
`fem
`
`0002
`
`

`
`U.S. Patent
`
`Jul. 18,2000
`
`Sheet 2 0f 3
`
`6,092,114
`
`ATTACH A FILE TO A MESSAGE
`I
`TRANSMIT MESSAGE
`FROM REMOTE DEVICE
`I
`RECEIVE MESSAGE AT THE
`LOCAL SERVER
`I
`CHECK FILE FORMAT
`OF THE ATTACHMENT
`I
`CHECK ACCESS CAPABILITIES
`OF TARGET CLIENT
`
`“42
`
`~44
`
`COMPATIBLE?
`
`LOCALLY
`CONVERTIBLE?
`
`(52
`CONVERT FILE
`FORMAT
`
`TRANSMIT REQUEST
`TO REMOTE SERVER
`I
`RECEIVE MESSAGE WITH
`CONVERTED ATTACHMENT
`I
`TRANSMIT MESSAGE TO CLIENT
`
`FIG. 2
`
`0003
`
`

`
`U.S. Patent
`
`Jul. 18,2000
`
`Sheet 3 of3
`
`6,092,114
`
`—\ 36
`
`38
`v
`
`ATTACH A FILE TO A MESSAGE
`I
`TRANSMIT MESSAGE FROM
`REMCTE DEVICE
`I
`RECEIVE MESSAGE AT THE A
`LOCAL sERvER
`40
`I
`TRANSMIT MESSAGE T0 CLIENT V 58
`T
`CHECK FILE FORMAT AT THE CLIENT N 60
`
`DIRECTLY
`ACCESSIBLE?
`
`/ 66
`
`TRANSMIT REQUEST TO
`THE LOCAL SERVER
`
`68
`
`LOCALLY
`CONVERTIBLE?
`
`( 70
`CONVERT FILE
`FORMAT
`
`J 74
`
`TRANSMIT REQuEsT T0
`REMOTE SERVER
`I
`RECEIVE MESSAGE WITH
`CONVERTED ATTACHMENT
`f 72
`V
`TRANSMIT MESSAGE TO CLIENT <——
`I
`—> ACCESS ATTACHMENT AT CLIENT q 64
`FIG. 3
`
`,_ 76
`
`0004
`
`

`
`1
`METHOD AND SYSTEM FOR
`DETERMINING THE LOCATION FOR
`PERFORMING FILE-FORMAT
`CONVERSIONS OF ELECTRONICS
`MESSAGE ATTACHMENTS
`
`BACKGROUND OF THE INVENTION
`
`The invention relates generally to message delivery sys
`tems and more particularly to methods and systems for
`providing compatibility betWeen ?le attachments of the
`messages and resource capabilities of devices to Which the
`messages are directed.
`
`DESCRIPTION OF THE RELATED ART
`
`Systems that support the exchange of text messages
`among users often alloW ?les 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 ?le. As another example, a doWnload of a
`message from a Web site on the World Wide Web may
`include an attached text ?le in Hypertext Markup Language
`(HTML) or an attached audio, video or graphics ?le.
`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 com
`puter 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 ?rst
`computer that transmits the message to a ?rst email server.
`If the ?rst email server does not support message access for
`the party to Whom the message is directed, the ?rst 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 ?le attachments, since the
`systems are designed for sending embedded text. Email is
`basically an ASCII text system. Dif?culties arise When a
`message includes an attached ?le. Seamless access to the
`attached ?le may be inhibited by decoding-speci?c require
`ments or application-speci?c requirements upon the receiv
`ing client device. Regarding the decoding-speci?c
`requirements, attached ?les 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 ?les to text
`and sends the converted 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
`?le, if the ?le is to be accessed.
`Even if the attached ?le is properly decoded at the
`receiving client device, the ?le Will not be accessible unless
`the client device has the required application program for
`opening the attached ?le. Typically, an attachment has a ?le
`format that is speci?c to an application. For example, an
`email attachment of a Word processing text ?le may be
`speci?c 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 ?le to another ?le format that is accessible. Video,
`audio and graphics ?les typically have more exacting
`demands. For example, an AVI video formatted ?le is not
`converted to a MPEG video formatted ?le Without signi?
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6,092,114
`
`2
`cantly more complexity than the process of converting from
`one application-speci?c Word processing ?le format to a
`second application-speci?c Word processing ?le format.
`Many client devices have the capability of converting
`attachments from a limited number of inaccessible ?le
`formats to an acceptable me format. If the attachment is a
`relatively short Word processing document, this capability is
`all that is required for ef?cient display of the document at the
`receiving client device. HoWever, if the attached ?le is large,
`such as an intra-corporation multimedia presentation of a
`neW product release, the required time to convert the attach
`ment betWeen ?le formats may lead to a signi?cant inef?
`cient use of the time of corporate personnel. Particularly in
`the conversion of multimedia ?le attachments, a complex
`algorithm must be utiliZed.
`Thus, if a ?le attachment is received that requires an
`application that is “foreign” to the receiving computing
`device, the ?rst issue is Whether the computing device is
`capable of converting the attachment to an accessible ?le
`format. Asecond issue relates to the time requirements of 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 ef?cient and reliable exchange of attached ?les 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 ?le 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 determined that a ?le-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 identi?es 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 (e.g., a target
`computer). When a message is received at the server, the ?le
`format of any attachment is identi?ed. In its simplest form,
`this is accomplished by looking at the ?le extension (e.g.,
`.BMP identi?es a bitmap graphics format and .MPEG indi
`cates a speci?c 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
`?le format. If a ?le-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
`
`0005
`
`

`
`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 Office Protocol-POP3). 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
`?le format, the attachment is again doWnloaded to the target
`client device.
`The out-tasking of the conversion operation to the local
`server may be utiliZed even if the target client device is
`capable of the ?le-format conversion. By executing the
`conversion at the server, the process is completed off-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
`?le 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 ?le 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 be passed to the
`sending client device, attempting to trigger an automatic
`conversion and/or notifying the sender that this attachment
`Was not accessed by the intended receiver.
`
`15
`
`25
`
`35
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a schematic vieW of one embodiment of a
`message exchange system that provides ?le-format conver
`sion in accordance With the invention.
`FIG. 2 is a process How of one embodiment for carrying
`out the conversion process in the system of FIG. 1.
`FIG. 3 is a second embodiment of a conversion process in
`accordance With the invention.
`
`45
`
`DETAILED DESCRIPTION
`
`With reference to FIG. 1, a messaging system 10 is shoWn
`as including a local router/server 12 for supporting access to
`stored messages by a number of client devices 14, 16 and 18.
`The routing operations of the router/server 12 are not the
`primary focus of the messaging system and method.
`Therefore, the router/server Will be identi?ed 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 veri?cation of a user identity. Such identi
`?cation generally requires input of a passWord that is
`speci?c 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
`of the World Wide Web, so that a link 20 to a netWork 22 is
`a connection to the global communications netWork referred
`
`55
`
`65
`
`6,092,114
`
`4
`to as the Internet. HoWever, the system and method Will be
`described primarily With respect to the preferred embodi
`ment of exchanging email messages having ?le 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 router/server 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 router/servers 12 and
`26 are Internet Service Providers (ISPs). It is not critical that
`the sending and receiving client devices subscribe to differ
`ent ISPs. That is, the method to be described beloW may be
`utiliZed to provide ?le-format conversion of an attachment
`to a message sent from one of the local client devices 14, 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, 16 and 18. For example, access to a video
`?le that is attached to an email message may have a ?le
`format that requires a receiving client device to have a
`speci?c 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 ?le formats to an acceptable ?le format. A
`Word processing document may be ef?ciently converted.
`HoWever, if the attached ?le 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. 1 provides an improve
`ment over the conventional system by providing a format
`converter 30 at the server level. Consequently, if it is
`determined that a ?le attachment to an electronic message
`includes an attachment that cannot be accessed Without
`?le-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 format 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 ?le 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
`
`0006
`
`

`
`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 ?le-format
`convert the attachment at the converter 30. For example, a
`special protocol element P 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 Of?ce 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 ?le, the message can be sent to the
`remote router/server 26 from Which the message Was origi
`nally received. This may be necessary When the ?le 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 converting an attachment
`having a particular ?le format.
`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 12 to the sending remote router/server
`26 to request the necessary manipulation of the attachment
`that is not locally convertible. The remote router/server 26 is
`connected to a second format converter 32. If the second
`format converter is capable of placing the attachment in a
`?le format that is accessible by the target client device, the
`?le format can be changed and the message can be retrans
`mitted to the local server 12 for subsequent access by the
`target client device. On the other hand, if the remote
`conversion is not successful, the router/server 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.
`HoWever, in typical applications, the message to the origi
`nating client device 24 is an informational message that the
`target client device Was unable to read the attachment, so
`that the attachment should be resent in an accessible format.
`The protocol elements and messages described above can
`be designed and implemented in a manner in Which they are
`buried in text format 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
`router/server 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
`bene?cial 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 be audio
`embedded into an email message, With the audio ?le requir
`ing a speci?c player. In other examples, the attachments may
`be video ?les or graphic ?les 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
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`2. In a ?rst step 36, a ?le is attached to an electronic
`message. In the preferred embodiment, the message is an
`email message having a ?le attachment. With reference to
`FIG. 1, step 36 may be 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 subscriber 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 ?reWall. 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 ?le format of the attachment is identi?ed
`at the server level. In its simplest form, this may merely be
`a check of the ?le extension of the attachment. For example,
`.BMP identi?es a bitmap graphics format and .MPEG iden
`ti?es a speci?c video format. As another format indicator,
`there may be an identi?er that is intentionally embedded by
`the sending party Within the message to indicate the ?le
`format of the attachment. As a third alternative, the server
`may attempt to access the attachment in order to identify its
`?le format. Other approaches to checking the ?le 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. The
`application register 34 of FIG. 2 may be considered to be a
`universal application register that identi?es 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 ?rst used to access email stored at the local
`server, the client device is polled to identify its access
`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.
`At step 46, it is determined Whether the attachment is
`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.
`If at step 46 it is determined that there is an incompat
`ibility betWeen the access requirements of the attachment
`
`0007
`
`

`
`6,092,114
`
`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 ?le-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 ?le format conversion at step 52 is executed using
`knoWn techniques. Conventionally, computer softWare is
`utiliZed to change an attachment from one ?le format to
`another. HoWever, if the format converter 30 of FIG. 1 is
`incapable of providing the conversion, because the ?le
`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
`router/server 26. The request includes instructions to convert
`the attachment to an accessible ?le format. For example, at
`step 54, a special protocol element P 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 of the attachment in an
`alternative ?le format.
`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 ?le 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 ?le format 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 identi?cation
`of the ?le extension.
`After the ?le format has been identi?ed, 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 ?le 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 12 at step 66.
`The request may be the above-identi?ed protocol element P.
`The request includes instructions to convert the attachment
`to a particular accessible ?le 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
`
`10
`
`15
`
`35
`
`45
`
`65
`
`8
`place Without an upload of the message from the target client
`device to the local server. FolloWing the ?le-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 ?le format.
`Returning to the determination step 68, a negative
`response to the capability of executing a local conversion
`Will trigger a transmission of a request to the remote
`router/server 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-to-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. Amethod 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 ?rst
`electronic messages having attachments in ?le formats
`that are each speci?c to one of a plur