EMC 1019
`EMC Corp. v. Clouding Corp.
`IPR2014-01217
`
`

`
`Patent
`
`W
`
`US 7,254,621 B2
`
`
`
`
`.m...,__mEo:m>_mw:o:m_:u_cm_>_2m.Q__mE.mmmucmm=0m<wexmEmamw:o_§:a_:m2m.moE29022x5._s_x
`
`tm>cootm>._owco:m_3a_cm_>_mfin.=2Xm>>9tm>coo.._S_X
`
`
`
`NewENEN3.05
`
`E_._&.o>._omco_«m_:a_cm_>_EmoEamVMNnunNunRNcmw
`
`EE:m>.wmco_.m_:a_cms_m.moEE0Eoommoceofoo
`
`madam
`
`

`
`U.S. Patent
`
`Aug. 7, 2007
`
`Sheet 4 of 9
`
`US 7,254,621 B2
`
`
`
`Ema2.338.Emzcou
`
`QWV5330Ema
`
`
`
`93.Eotmmcoawm.mzooom
`
`Eom<53:0«.8
`
`
`
`Em?.350
`
`
`
`%m.._3cmmEma<
`
`
`
`932mmcoawo.oozuoi
`
`o_>>mczmmaum.
`
`
`
`§hVBuw>_mo9fimzcmm
`
`
`
`co:a__.a_cm_2Sun
`
`Eaww
`
`
`
`§N§.003.0%mc__.Em.mo
`
`
`
`ucmumfimzcm.m:_mn
`
`
`
`mafiacozmcces
`
`um.w_:Q_:mE
`
`
`
`cozmoo>:_mo_>_owm_>
`
`mmmfiv<
`
`
`
`
`
`3.6.bammuoocccotmm
`
`Emucom:_mm8o.a
`
`
`
` 3».mgzomBmozummn=>>¢.05
`
`
`
`
`
`
`
`
`
`
`
`

`
`U.S. Patent
`
`Aug. 7, 2007
`
`Sheet 6 or 9
`
`US 7,254,621 B2
`
`mm.03
`
`con.toam_tm>._mmm_Sim.EL::&._m2mmco_«m_:a_:m_2m.mo=d:c
`
`mmAVE
`
`
`
`uoufioamto_>>>m_ommmmou<mm_E.m>..mm>>m:§n~mmv.woou.toam.EmEmwmE=umEwe.E52mwco=m__d_cm_2m.mo\>azn
`
`mm.UE
`
`mmvmmE2...8mum2oo2..
`
`
`

`
`U.S. Patent
`
`Aug. 7. 2007
`
`Sheet 8 of 9
`
`US 7,254,621 B2
`
`FIG. 6A
`
`602
`
`603
`
`Internet Explorer
`f192«1‘='*9~
`
`3:29p
`
`9
`
`The ReefEdge Solution
`Eafirv.-are fiar Iuletw-:1rl>;‘3:1nrne-:ti'.'it',' and Enterpri-
`
`
`
`610
`
`9
`
`

`
`US 7,254,621 B2
`
`1
`'l'ECl'.lNlQUE FOR ENABLING REMOTE
`DATA ACCESS AND MAs\’IPULA'I‘ION FROM
`A PERVASIVE DEVICE
`
`CROSS-REFERENCE TO RELATED
`Al’P.ZlCATION
`
`This application is a continuation of prior application Ser.
`No. 09/848,394, filed May 3, 200], which is hereby incor-
`porated herein by reference, now US. Pat. No. 6,925,481.
`
`FIELD OF THE lN"\"El.NTlON
`
`The present invention relates to pervasive computing, and
`more partimlarly to methods, systems, and computer pro-
`g_mm instructions for enabling users of pervasive devices
`t‘ such as limited-fiinction mobile devices, smart appliances,
`etc.) to remotely access and manipulate ini'or.mation in ways
`that might otherwise be impossible or impractical because of
`inherent limitations of the device.
`
`BACKGROUND OF THE ll\’VlEN'l’lON
`
`it‘;
`
`15
`
`20
`
`30
`
`2
`all of the inlbrniat.ion that the user requires. indeed. most of
`a user’s tiles or data are normally stored on a desktop
`personal computer
`(“l’C"),
`laptop. or corporate server.
`Moreover, the dcvice’s memory liinitations ot"ten prevent the
`user from manipulating large files, such as g.rapl1ics-inten-
`sive presentations (where it might be desirable, for example,
`to rc-order the slides within a presentation). Second. the
`device typically does not have the software required to
`access all of the data that the user might wish to use. For
`example, most pervasive devices are unable to mo conimon
`software
`applications
`such as Microsoft® Word or
`Microsolt® Powerpoint. (“Microsoft" is a registered trade-
`mark of Microsoft Corporation.) Some pervasive devices,
`such as two-way pagers from Research in Motion (“RIM”),
`do not usually have a Web browser installed, and therefore
`the user cannot render data formatted as Web documeitts.
`Third, the device often does not have the necessary drivers
`installed with which to support all the data manipulation
`operations the user might wish to perform. For example,
`pervasive devices typically do not have drivers to support
`operations such as printing and Faxing. Similarly, pervasive
`devices typically do not have drivers for video graphics
`may (“V(lA") adapters that would enable the device to
`display content
`to at projector (such as a liquid crystal
`display, or “LCD,” projector).
`Some pervasive devices would not be considered as
`limited in function, although they may suffer from some of
`the drawlnaclts of limited-function devices such as poor
`ease-of-use =,’having_. for example. a small screen size).
`Exainplcs include the Compaq iPAQ l-Ionic Internet Appli-
`ance lA-1 and the Audrey“ home appliance from 3Com
`Corporation. (“Audrey” is 3 trademark’ of 3Com Corpora-
`tion} The term “Wireless lxiforiitatioii Device", or “WID”,
`will be used hereinafter to refer to this type of pervasive
`. device as well as limited—l'unction pervasive devices. ('l‘ltis
`tenn l'B{X)glllZBS the tact that both the limited-function and
`full-function pervasive computing devices typically com-
`municate using wireless communication techniques and
`protocols, such as 802.ll, l3lnetoot’l1, and so forth.)
`Various attempts have been made to address the limita-
`tions of W'll)s; however, existing approaches fail to provide
`a satisfactory SC‘.l‘tlll(Jn.
`One existing approach to addressing the limitations of
`Wll.)s involves the teclmique of “transcodiug” content into
`a form that is better suited for the WID. Products such as the
`WebSpherc® Transcoding Publisher
`from liztternational
`Business Macliines (“lBM") Corporation and Spyglass
`Prism from Open TV, lnc. represent examples of this class
`of solution. (“WebSphere” is a registered trademark of
`IBM .) Tlirouglt transcotling. the content is programniaticaliy
`
`in-rt
`tpulated for a target device. For example. the transcod—
`ing process may enable the content to be rendered effectively
`on it small-screen device (perhaps by altering 'l'ont size,
`removing image files, and so forth). Typically, a "transeod-
`ing engine" located on a server or network device receives
`the content
`in its original fonn, performs It conversion
`process, and delivers the renderable lormat
`to the client
`device. However, these rranscoding solutions only address
`the need to view content: they do not provide a capability to
`manipulate the content from the WID. For example, the
`transcoding, process does not enable the WTD to e-mail, fax,
`print, or project the content.
`Another approach to addressing the limitations of WlDs
`involves supplementing the capabilities of the W ID tltrough
`the deployment of hardware adapters or software. For
`cxanlple, a special-purpose attachment (known as a "Spring-
`I 1board"M"' module) may be plugged into a Handspring Visor
`
`Pervasive devices (also referred to as “pervasive comput-
`ing devices") have become popular in recent years as people »,
`increasingly seek “anywltere, anytime" access to services
`such as voice and data communications. Matty pervasive
`devices are designed to be mobile, and may equivalently be
`referred to as “mo’nile devices” or “mobile computing
`devices". Examples of mobile pervasive devices range from
`two—way pagers to personal digital assistants, or “l-’DAs"
`(such as the Palm Pilot‘, Handspring Visor“. or Compaq
`il’.-KQ)
`to cellular phones (such as the Nokia 6110) to
`multi-function devices (such as the Nokia 9110 or Qual-
`comrn “pdQ'”“" sniartplicne). (“Visor" is a trademark of
`It-landspring, and “pdQ” is a trademark of QUALCIOMM
`‘tncorpora1cd._) All pervasive devices are not necessarily
`mobile. however. lixamples of this latter category include
`smart appliances for the home or business setting, devices
`which are permanently mounted in :tutomobi.les, and so
`it-rtli.
`Pervasive devices typically share several common char-
`acteristies:
`limited processor speed;
`2) limited memory capacity;
`3} small size, which limits the richness of the data input
`and output
`interfaces (for example, small screen.
`limited
`keypad, and so forth);
`4) a limited amount of software pre-installed on the
`device; and
`5) access to limited-bandwidth networks.
`The inherent drawbacks of these characteristics are fur-
`ther exacerbated by:
`l) the need to mttxintize the device’s relatively short
`battery llle—~—Wl1:lClt in turn prevents additional processor
`power or memory capacity from being added to the device;
`and
`
`45
`
`50
`
`35
`
`2) the need to simplify use of the device————wl1ich in turn
`reduces the desirability oi’ supporting, an “open” software
`installation platform in which arbitrary software packages
`might be added.
`As people rely on pervasive devices tor day-to-day infor-
`mation access tasks, they find that the experience can be
`extremely limiting. While pervasive devices vary widely in
`functionality and in their capabilities, some general obser-
`vations for an average pervasive device can be made. First,
`the device typically does not have suflicient memory to store
`
`6!)
`
`65
`
`

`
`US 7,254,62l B2
`
`5
`MG. 1 illustrates a preferred architecture and components
`of a system in which the present invention operates. The
`system may provide support for multiple WlDs, although
`only one WlD 130 is illustrated in FIG-. 1. The WID, which
`in preferred embodiments is a commercially-available WID
`which may be provided by any one of a number of vendors,
`includes at least one software application with which 21 user
`interacts to access and/or mzuripulatc data.
`in preferred
`embodiments, this user-interaction software application is
`the only software required on the WID to enable use of the
`present invention. This uscr—interaetinn sofiwarc pr'eferably
`comprises a browser
`implementation (such as a Web
`browser); in alternative embodiments, other types of user-
`iutcraction sofiware applications (including, but not lintitccl
`to, e-mail client software) may be used. The riser‘-interaction
`software application may be installed on the Wll) when it is
`marketed, and may be a cornmercially-available so1'"twarc
`irnplementation. When browser software is present, it pref-
`erably supports at least one markup laiigttage. Examples tit’
`markup languages that may be supported include the Hyper-
`text Markup l'..anguag_e (“l'ITMI."): Wireless Markup .lI..an-
`guage (“WM.I.J‘); and Voice Extensible Markup Language
`(“Voicex ML”).
`Note that while preferred ernbodituetrts of the present
`
`invention operate with coninterci
`-available WlDs and
`without requiring lrardware or software rrtodificatirx-trs or
`zidd—ons, in alternative embodiments the WID may be spe-
`cifically adapted for use with the present ll1VcI1ll()ll, without
`deviating, frotn the inventive concepts disclosed herein. Ftjll’
`example, 21 W11) ntight include tnodificatioirs to provide a
`user interface tailored for use with the present invezttion. or
`perhaps code for optimizing data access and/or manipulation
`processing. Moreover", auxiliary software may be provided
`to provide enhanced atrtlietttication, encryption, compres-
`sion, or similar l'unctiot'rs that augntcut the transmission of
`data described hereirr. Furthermore, while the preferred
`crnbodimertt anticipates invocation by user interzrction (and
`user-interaction software), there may be implemezitations in
`which automated or progratnniatic invocation is appropriate.
`in these cases, sottx are which embodies the automated o.r
`prograiniuzttic irtvocatiott may replace the previously-cltr
`scribed user-interaction software as
`the only so llware
`required on the W.lD to enable use of the present invention.
`Or, the two forms of invocation software may co-exist on a
`WID.
`At least one protocol proxy 120 is provided, according to
`the teaclrings of the present invention. A protocol proxy
`provides a bridge between the client (i.e. an applic*;rtion
`executing on Will) .130) and the itiforiuatiori that it seeks to
`access and manipulate. A protocol proxy is responsible for
`accessing inlTormation on behalf of the client and (in pre-
`ferred ernbodiments) annotating this accessed inforrnation
`with information about the rnanipttlatiori services available
`for that accessed information. (The annotation process is
`rlescribed in more detail below, with reference to Block 350
`of N6. 3.) The itrfonnatiori may be accessed, for example,
`
`from its location on one or more Web content servers ..
`the
`World Wide Web (liereinullcr. “Web”) 110, in a distributed
`file system 150 of the prior art, or from an application of the
`prior art. This content server may deliver content
`that
`includes services which have been “pre-added" to the con-
`tent {e.g. by querying the DMS directly), so that the protocol
`proxy is not required to provide additional annotations. 'll1is
`latter situation may be particularly bcnelicial, for example,
`if the content server happens to be co-located with the DMS.
`Preferred embodiments of the present invention include at
`least one of the following types of protocol proxy: (1) a
`
`5
`
`15
`
`2t)
`
`25
`
`30
`
`.35
`
`40
`
`45
`
`Sf‘:
`
`6
`Hypertext Transfer Protocol (“ll’l'TP“) proxy, (2) a Wireless
`Session Protocol (“WSP") proxy, and (3) a Simple Mail
`Trattsfer Protocol (“SMTP”), l’ost Ofice Protocol (“l’()P" or
`“l‘~OP3”), or Internal Message Access i’rotc-col (“IM;-KP”)
`proxy. Au HTTP proxy handles requests for and reception of
`inllinnatiorr using H"l"l‘P request and response messages. A
`WSP proxy liandles requests for and l‘CC8pl.iO=.'l of inil'orma-
`tion using WSP request and response messages. SMTP, P09,
`and lMAl’ proxies handle requests for and reception of
`electronic mail respectively using SMTP, POP, and IMAP
`request and response rriessrrges.
`Alternative ernhodiments may include diil'cr'ent and/or
`additional protocol proxy types. For example, it synchroni-
`zation protocol proxy may be included, which may be used
`to sytichr1')rii2e data stored locally on a user’s WID with data
`stored elsewhere (such as on the user’s desktop
`An
`example synchronization protocol
`is “SyncMl.." which is
`being developed by The SyncMl’,. Initiative to seamlessly
`synchronize wireless and wireline data and devices. (See
`httpzi/www.syncml.0rg for more information on Syricl\'ll}.)
`'llie protocol proxies in a particular implementation of the
`present invention may each run on dillcrent hosts if desired,
`and individual protocol proxies may be co~located with
`other components of the system. The protocol proxy func-
`tion described herein may be replicated, if desired (for
`example,
`to administratively separate diilereitl
`types of
`proxy lirtictiori, for purposes of fault
`tolerance or fault
`isolation, for scalability and load balancing, etc.) Moreover,
`a single proxy may itself be diVidL\’i into separate compo-
`nents. For example, an HTTP proxy may include a first
`comporient that determines whether the request is for con-
`tent on the Web or perhaps mi 3 file server; a second
`component that handles those requests which are for Web
`content; and it third component that liandles those requests
`whicli are ‘for cotrtcrtt from a file server. The multiple
`criinpoireiits mrty,
`in turn, be distributed across multiple
`m;tcltines_
`In one embodiment, prior art configuration mechanisms
`are used to adapt
`the Wll) for comrniuiicating with a
`protocol proxy. For example, the client Web browser may be
`instmcterl to communicate with an l-ll"l“? proxy, or synchro-
`nization software on the Wll) rnuy be configured to send
`synchrorrizatitrn protocol messages to the synchr'oni2'ation
`protocol proxy. In this etnborlirner=.t_. the protocol proxy then
`intercepts outbound messages from the client on the WH)
`and processes those niessages as disclosed herein. In another
`et‘t‘th0ditrtent_. a WID comnztturicates with a protocol proxy
`through a wireless access point (not shown in FIG. 1), such
`as an 802.1 "l access point or Bluetnoth access point ifthe
`lirnctioning of which is known in the art). In this latter
`embodiment, the access point or an adapter device cornnm-
`nicr.-titig with the access point receives outbound rnessziges
`from the WID and evaluates those messages to determine
`whicli protocol is in use. The access point or adapter device
`then routes the outbound message to the appropriate proto-
`col proxy. (This latter embodiment is preferred in the present
`ir.tventio.n because it avoids the need to configure the WID.)
`Zero or more file access proxies 140 are also provided,
`according to the present invention. File access proxies may
`be located on various file sewers. desktop computers, data-
`base systems, or other storage devices, and provide access to
`data stored in one or more repositories 150 which are located
`on (or otlrerwise accessible to) those machines. A particular
`file access proxy may access data from a local repository,
`within remote data stores (such as iitfontizrtioit
`that
`is
`accessible iron) a remote file server or Web server), infor-
`1»;I.1'.ldll0ll stored within local applications (such as stored
`
`65.1
`
`65
`
`
`
`

`
`US 7,254,62l B2
`
`9
`(“URLs’ ). Preferably, the addresses are specified within the
`entries stored in the DMS‘s table, as shown in the example
`tables of HG. 2A and FlG. 2B. although alternatively the
`addresses may be separately stored (perhaps as a storage
`0pll.§‘{i.l’l£ill0l‘L). As an example of using the latter approach. a
`print service might appear many times in the DMS’ table. To
`climinate redundant storage of this seivice“s URL, the U RL
`mi ght be correlated to the print service but separately stored,
`enabling individual table entries such as 255 and 260 in FIG,
`2B (wltich specify qualifiers on when printing is available)
`to be associated with the proper URL at run-time even
`though column 254 is omitted. Sin1ilarly, separate storage
`may be desirable in cases where the appropriate URL to use
`for creating the available services list is determined dynami-
`cally at run-time.
`Note that while the service invocation addresses used
`herein as examples specily locations on a DMS, this is for
`purposes of illustration and not of limitation. One or more of
`the URLs may alternatively identify services pl'()\—"l(lCf.l at
`locations other than the DMS.
`in alternative embodiments, service invocation address s
`
`may employ adtlrcss lbnnats other than URLs. such
`5
`e-mail addresses, or perhaps a combination of an c-mail
`address and subject
`line,
`to designate a service to be
`invoked.
`
`‘Nhcn requested information is delivered to a client nppli~
`eatioii on the WID, a list ofscrvice invocation addresses for
`the available sen-‘ices is provided along with that informa-
`tion {as will be discussed in more detail with reference to
`Block 350 of FIG. 3). Each service iiivocatimt address is
`"preferably augnieuted with an identity of the information
`that is to be operated upon. in some cases. it may be possible
`to infer the infnrrualion identity from the service invocation
`address. in which case this augmentation is not required. For
`example, a service invocation address might
`identify 21
`Structured Query Language (“SQL”) query whose result is
`implicitly the data being manipulated.
`Returning now to Fifi. 3, one or more data output agents
`170, which implement specific output manipulation opera-
`tions (such as printing, faxing, projecting, or delivering to a
`voice mail system, the details of which do not form part oi‘
`the present invention), are provided. (Note that a data output
`agent, as the term is used herein. refers to a component that
`delivers tile content
`to an output device, whereas a file
`access proxy as defined licrcin retrieves tile content
`in
`read-only mode. In some instances, 5 data output agent and
`a file access proxy maybe co-located, and fuithennore these
`functions may be implemented within a single sofiware
`component.) The DMS passes data to selected ones of these
`agents to perform the manipulation services which are ”
`managed by the DMS. in preferred embodinients of the
`present invention, one or more of the following, data output
`agents are supported:
`a print server agent, which is responsible for scndingjobs
`to one or more printers;
`a projection server agent, which is responsible for driving
`the display of content to an LCD projector, video display, or
`other graphical terminal;
`a file manipulation server agent, which is capable of
`performing file operations such as copying. deleting, and
`renaming files (and which is typically co-located with a tile
`access proxy};
`an e-tnail manipulation server agent, which is capable of
`performing e-mail operations such as sending, receiving,
`and deleting e-mail messages (and which is typically co-
`located with a file access proxy that accesses e-mail tiles);
`
`55
`
`60
`
`(:5
`
`5
`
`in
`
`i5
`
`-'3
`
`30
`
`3'5
`
`45
`
`l 0
`a fax server agent, which is responsible for sending
`information for facsimile transmission; and
`a voice mail server agent, which is responsible for sending
`in.l"ormation for delivery through 8 voice messaging system.
`The agents may send data to queues or other similar
`slrlictures or processors, which may in turn be implemented
`as agents. For example, the output of a print server agent
`may he sent
`to 9 selected print queue for printing {using
`queuing techniques which are well known in the art). An
`agent such as a print server may manage local resources,
`such as a locally-stored print queue for a particular printer,
`or remote resources. such as access to multiple printers (each
`of which typically has its own print queue processing).
`In
`degenerate cases, a print server agent may be manifested
`simply as a print queue. Similarly, other agents such as the
`fax server agent and projection server agent may be mani-
`fested as queues for their respective devices.
`Referring now to Flt}. 3, logic is illustrated that may be
`used to provide data access support for a WID, including
`delivery of a Elsi’ of the manipulation operations that are
`available on that data. At Block 300, the client soilware on
`the W ll") issues a request for information. (This corresponds
`to request message tlmv l in Filti. I. The encircled numbers
`in FIG. I all refer to message flows.) Typically. this request
`is initiated by action of the Wll) user. Block 3.10 indicates
`that a protocol proxy receives this request. As described
`eai'licr, the outbound request either may be received by the
`protocol proxy to which the client software has been con-
`figured to communicate, or may be received by a wireless
`access point or adapter device (which then inspects the
`content to determine which protocol proxy is required, and
`lorwartls the request to that proxy").
`At Block 320, the protocol proxy forwards the request to
`the appropriate iiilorriiatioii source. For example,
`if the
`request is an H'.l"l"l" request For V‘v'ch content issued by a Web
`browser. then an l~l'l"l‘P proxy forwards that I-ITTP request to
`the Wt;-lzi. Or. if the request
`is for file content,
`it will be
`tb.i‘w:u'ded lo a file access proxy.
`(This corresponds to
`niessagc flow 2 or 3 in FIG, 1.) At Block 330, the protocol
`- proxy receives the response fmrn the information source.
`(This corresponds to message llow 4 or 5 in Fl(i. l.)
`The protocol proxy then determines, in Block 340, which
`services are available to the Wll) for manipulating the
`re-iuriictl content. This determination may be made in several
`ways. in a prefenred eniliodinient, the protocol proxy issues
`a query to the DMS For a list of available services. {This
`corresponds to message flow 6 in FIG. 1.) Upon receiving
`the list from the DMS, the protocol proxy may optionally
`cache the list for use with subsequeiit requests (in order to
`avoid the message exchange and processing overhead of
`repeatedly requesting such infonnation from the DMS). in
`an alternative embodiment,
`the protocol proxy may he
`statically pre-configured with a list of available services that
`are appropriate for particular types of content, users, loca-
`tions, or other criteria as described previously with respect
`to FIGS. 2A and 2B; in this case, message flow 6 of FIG. 1
`is not required.
`When queried by the protocol proxy at Block 340, the
`DMS consults its stored table entries (see PlGS. 2A and 28
`for examples), using logic that is adapted to the particular
`storage format in use by that DMS, and dctcnnincs which
`services are available for the data being returned to the WlD.
`As stated earlier, the available services are preferably fil-
`tered according to the type of content being returned, and
`may also (or alternatively) account for one or more other
`factors.
`(_'l'his
`filtering process has been discussed with
`1 Sreferencc to FlGS. 2A and 28. above.)
`
`

`
`US 7,254,621 B2
`
`.13
`
`original request tnesi-sag,e, thereby ensuring that the mar.-iptt-
`lated content corresponds to the content delivered to the
`WID user. FIG. 5l<' provides an example of syntax that may
`he used to annotate a link with it cookie whose name is
`"acct_nbr" and whose value.
`is “l23456”. (Note that
`the
`DMS prepares the user’s bank account
`information for
`priming in response to a data manipulation request indicated
`as message flow 8 in FIG. 1, and invokes the print process
`at a data output agent by issuing message flow 10 in FIG-. 1.
`The processing performed by the DMS may further com-
`prise obtaining bank account information by issuing mes-
`sage llow 9 in FIG. 1.)
`This same approach may be used for fonn parameters that
`are submitted to a Web server (e.g. using an HTTP POST
`inessagc). To encode the form parameter information in the
`URL. a parameter name such as “postParams" may be
`substituted for the “cookie” parameter name shown in MG.
`SF. A parameter iiatneivaltte pair may then be listed, in an
`analogous manner to listing, a cookie naine/value pair.
`A service invocation address may be coupled with any
`combination of cookies, form parameters, or other infonria-
`Zion.
`
`form parameters, and other
`Wlien encoding cookies,
`iiiforirtation in this manner. three issues should be consid-
`ered. First, URL length is currently limited to 255 characters,
`according to the ’rl'l‘TP specificaatioii. Second, it is diflicult to
`encode all character sets in URLs. Third, a DMS may in
`some cases be intplentented within Et Web client which is not
`able to progratttmatically control the sending of request data.
`For example,
`the DMS might use Microsoft
`Internet
`Explorer, which provides no programmatic way to force. a
`cookie to be sent. To address these problems, the cookies,
`fortn parameters, and so forth may be cached by the protocol
`proxy (i.c. when the original content is beitig, processed).
`This cached information may then be used in three ways to
`construct a valid request for use with the present invention.
`In a first approach, in the sewice invocation address URL,
`a parameter can be given by which the cached parameters
`can be obtained by the DMS from the protocol proxy. For
`example,
`“?params=ht'lp2!/protocolproxy/parmns.’
`l39x3e2‘45" gives the DMS a URL from which the cached
`parameters, cookies, etc. can be obtained.
`'lhe value
`“‘i39x3e245" in this example is meant as a temporary code
`which represents the parameters associated with the part ictt—
`lar requwt.
`in a variation of this first approach, the parameter on the
`service invocation address URL may identify how to obtain
`the cached parameters from the cache, rather than from the
`protocol proxy.
`in a second approach, the data URL may actually point to
`the protocol proxy itself. The protocol proxy, upon receiving
`the data request from the DMS, dctennines the real request
`and obtains the requested data on the DMS’ behalf. For
`example, “http2//protocolproxy/reqncsL’139x3e245” n‘-.ig,l‘it
`cause a request (along with the appropriate cookies. form
`parameters, and other information) to be issued from the
`protocol proxy to the true source of the data.
`ln at third approach. the DMS may request the content by
`itself using the protocol proxy, in much the shine way tlt-at
`all requests from the Will were directed through the proto-
`col proxy. However, the protocol proxy may annotate the
`data source with a tag that the protocol proxy can later use
`to reconstruct the original query. For example, the protocol
`proxy might rewrite the content request URL. to be “http:.-"/
`wwwyahoo.oorn./?prot;ocolproxy*l39x3e245",
`so,
`upon
`
`.
`ing the request from the DMS, the protocol proxy may
`
`10
`
`25
`
`30
`
`I4
`look up session l39.x3e245 in its cache, obtain the necessary
`parameters, and forward the properly-formatted request to
`location “www.ytthoo.cotn".
`lt is also possible that the protocol proxy might cache the
`data content (ra‘-ahcr than the parameters). In this case, the
`content location provided by the protocol proxy might then
`point to that cache. There is then no need to provide cookies
`or parameters in the URL, because the DMS can obtain the
`full content from the cache. To achieve maxintal perfor-
`mance and capacity in this situation, the cache is preferably
`capable of storing multiple versions of content associated
`with the same URL, with each version associated with a
`‘ different combination ofcookics, form parameters, and other
`request iitfommtion.
`Optionally, additional formatting information may be
`supplied as parameters on selected wrvice invocation
`addresses during the annotation process of Block 350. These
`additional patnmeters may he provided for implementation-
`specific usage,
`inciuding for customization of the data
`tnattipttlatiott service. One example, described above, is to
`specify a destittation address for a tile that is being stored in
`a repository. As another example, suppose the data manipu-
`lation service is to send an c-maii message to a particular
`recipient’. An example of invoking the “email” service,
`which is managed through the DM S at the location shown in
`FIG. 56, to send a message identified as “msg98765.txt” to
`the recipient “lttcy@:ricardo.cotn” is shown in FIG. 5}-l.
`As yet‘ another example of adding patairtcters to service
`invocation addresses, it may be desirable in a tile conversion
`service to supply parameter values to be used in guiding the
`conversion process. Suppose, for exampic, that the previ-
`ously—discussed “report.doc” Microsoft Word document is
`being converted to HTML, and that the conversion software
`allows seveml diflerent types of tzatisforttiatiotis, based upon
`identification of a particular template. The template may
`specify how to fonnat the title, for example, and how to
`“clu.inlr" the source docunicnt
`into different pieces, how
`links to those pieces ate embedded, and so forth. if the
`template parameter value
`"‘pl2tin", for exarnple, the con-
`version is adapted to returning plain text, whereas if the
`template parameter value is "scgmented”, then the conver-
`sion may generate a “chunl<ed” document where each logi-
`cal input. segment appears on a dillfereitt page, and perhaps
`failing to specify 2:
`template parameter value causes the
`entire document to be generated as a single HTML page. A
`sample service invocation address for viewing the converted
`file in segmented form is shown in l"'lG. S].
`Preferably, the annotation process of Block 350 generates
`separate annotated links for each valid option. such that
`when the user selects one of the links, all the necessary
`infortttatiott
`is present
`for properly invoking the data
`man.‘-pulatioii service. (Note that the DMS prepares this file
`for viewing in response to a data manipulation request
`indicated as message flow 8 in FIG. 1, and returns the result
`for rendering on the WID at message flow 12 in FIG. 1. The
`processing performed by the DMS may further comprise
`obtaining the tile content by issuing message flow 11 in FlG.
`1-)
`The parameter types supplied during the annotation pro-
`cess may be stored in, and obtained front. the DMS table
`along with the applicable service invocation address. Or, the
`protocol proxy may provide service-specific code for deter-
`mining which parameter types are applicable for a particular
`service.
`While the preferred einbodiment has been described in
`terms of embedding the service description directly into the
`lifontent
`(eg.
`as
`links
`in HTML), other alternative
`
`40
`
`St‘)
`
`60
`
`65
`
`

`
`7,254,62l B2
`
`17
`as has been shown in the examples herein. Alternatively, it
`may happen that
`the DMS needs to evaluate additional
`infomtaticn in order to locate the data. For example, if a file
`name is received that does not specify 22 complete file path
`from a root directory, then the DMS preferably uses imple-
`nierttation-dcpendent techniques for resolving the location
`and directory path irifortnatiort. (Or, an error message may
`be returned in such cases, if desired.)
`At decision Block 440,
`the DMS determines whether
`processing lay it data output agent is required to complete the
`requested service. Each service irnplemented on the DMS is
`adapted to knowing what
`type of ftmhcr processing,
`is
`required and when zigentts) need to be invoked.
`if the answer to the decision block is Yes, then controi
`passes to Béoclc 450 where a request to the appropriate data
`output agent is generated. The data output agent
`that is
`invoked is preferably dcterrnined according to the type of
`service to be performed, and optionally by evaluating other
`factors (such as the user"s identity} the processing load on
`particular printers. current network conditions such as avail-
`able bandwidth mttl,-‘or outages. wlticlt data output agent
`supports the user’s e-mail service or file system, and so
`fortlt). The data output agent performs any necessary opera-
`tions, using processing which is known in the prior art, to
`perform the requested data riitrtripttlzttion. For example, iftlie
`data output agent controls on LCD projector, then the data
`output agent retrieves the information to be projected, ren-
`ders it, and makes the rendered in'l‘orm:':tion available to the
`associated projector (eg. through a VGA output connector).
`Or, if the data output agent hztudles sending of c-mail
`message-s_. then the