Motorola Mobility, Inc. v. Apple, Inc.

Filing 94

NOTICE by Motorola Mobility, Inc. of Filing Brief on Claim Construction (Attachments: # 1 Exhibit, # 2 Exhibit, # 3 Exhibit, # 4 Exhibit, # 5 Exhibit, # 6 Exhibit, # 7 Exhibit, # 8 Exhibit, # 9 Exhibit, # 10 Exhibit, # 11 Exhibit, # 12 Exhibit, # 13 Exhibit, # 14 Exhibit, # 15 Exhibit, # 16 Exhibit, # 17 Exhibit, # 18 Exhibit, # 19 Exhibit, # 20 Exhibit, # 21 Exhibit, # 22 Exhibit, # 23 Exhibit, # 24 Exhibit, # 25 Exhibit, # 26 Exhibit, # 27 Exhibit, # 28 Exhibit, # 29 Exhibit, # 30 Exhibit, # 31 Affidavit)(Giuliano, Douglas)

Download PDF
Exhibit 14 to Motorola’s Opening Claim Construction Brief July 28, 2011 11111111111111111111111011111411111 1111111111111 0110111111111111 3 United States Patent [11] Patent Number: [45] Date of Patent: [19] Eggleston et al. [54] SYSTEM FOR COMMUNICATING USER-SELECTED CRITERIA FILTER PREPARED AT WIRELESS CLIENT TO COMMUNICATION SERVER FOR FILTERING DATA TRANSFERRED FROM HOST TO SAID WIRELESS CLIENT 6,101,531 Aug. 8, 2000 5,377,354 12/1994 Scannel et al. 5,406,557 4/1995 Baudoin . 5,491,820 2/1996 Belove et al. 5,506,887 4/1996 Emery et al. . 5,513,126 4/1996 Harkins et al. . 5,568,540 10/1996 Greco et al. . 5,621,727 4/1997 Vaudreuil . 5,764,899 6/1998 Eggleston et al. [75] Inventors: Gene Eggleston, Cary; Mitch Hansen, Fox River Grove, both of Ill. 709/103 707/3 709/203 Primary Examiner—Le Hien Luu Attorney, Agent, or Firm—Romi N. Bose; Terri S. Hughes [73] Assignee: Motorola, Inc., Schaumburg, Ill. [57] [21] Appl. No.: 09/060,686 In a main embodiment, prestage filtering is applied via user-definable filter parameters (e.g., reject, pass, or granularity filters) on data being transferred between a communication unit (201) and communication server (220). For downloading, e.g., email from a host post office (240), a communication server controller (229) preferably either forwards the filter parameters in a query object or message to the post office to apply and return qualified mail (406-414), or the communication server receives all unprocessed mail and applies the filters locally (418-420), only acknowledging as processed that mail which passes the filters. For uploading, e.g., email from a client, a client controller applies an upload prestage filter (432) so as to retain all filter-rejected email, while transmitting email passing the filters (434). Thus, only desired data transfers (i.e., those meeting user defined filters) are communicated over the expense-bearing networks between the remote unit and communication server. [22] Filed: Apr. 15, 1998 Related U.S. Application Data [63] Continuation of application No. 08/574,537, Dec. 19, 1995, abandoned. [51] [52] Int. C1. 7 U.S. Cl. GO6F 15/16; G06F 15/177 709/206; 709/207; 709/220; 709/232 [58] Field of Search 709/206, 207, 709/220, 232, 103, 203; 706/47; 707/3 [56] References Cited U.S. PATENT DOCUMENTS 5,276,680 1/1994 Messenger . 5,283,856 2/1994 Gross et al. 5,287,456 2/1994 Rhodes et al. ABSTRACT 706/47 MS/CLIENT 11 Claims, 8 Drawing Sheets COMM SERVER HOST/SERVER QUERRY OBJECT 14 RECEIVE QUERRY FOR MAIL 408 -" 406 -' 414 416 RECEIVE MAIL; ACKNOWLEDGE 412 APPLY FILTERS; SEND QUALIFYING MAIL RECEIVE QULIFYING MAIL;FORWARD • • RECEIVE MAIL APPLY FILTERS FOWARD MAIL 420 418 FORWARD QUALIFYING MAIL RECEIVE MAIL; ACKNOWLEDGE 422 ACKNOWLEGE (LIST QUALIFYING, UNQUALIFIED MAIL) • 426 430 GENERATE MAIL 428 MARK INDEX 432 APPLY FILTERS 434 FORWARD QUALIFYING MAIL ATTACHMENTS; RETAIN; ALL UNQUALIFIED MAIL 436 • • • FOWARD MAIL 438 440 USER OVERRIDE, SEND UNQUALIFIED MAIL FOWARD MAIL • •• 444 442 RECEIVE; ADJUST CLIENT PROFILE/OBJECT CHANGE FILTER SETTINGS ACK EXHIBIT 14 PAGE 1 100 130 115 ___/ HOST/ SERVER COMM / SERVER 110 111 FIG.1 EXHIBIT 14 PAGE 2 216 218 201 219 240 242 r 1 t_ SESSION MANAGER 217 1 230 r POST OFFICE HOST SERVER MAILBOXES 222 r CD CSO MANAGER 244 — 246 I l VIRTUAL SESSION MANAGER 06 O 275 I rMEMOR1/ I 212 PITOUE3SOlqi 231 1224 232 ti HOST B I 234 X260 I CONTROLLER 226L - 214 FIG.2 J ACTIVE CLIENT PROFILE DB MEMORY INACTIVE CLIENT PROFILE DB CLIENT MAIU S&S INDEX DB 227 COMMUNICATION SERVER EXHIBIT 14 PAGE 3 22 8 I ^ 225 I El I ADMIN HOST(A) I BILLING 1 MANAGER 1 1 r _1_ 250 220 262 I CLIENT /GROUP PROFILE DB 11I■• = ......, I 266 I I 264 U.S. Patent Aug. 8, 2000 6,101,531 Sheet 3 of 8 MS/CLIENT VSM HOST/SERVER(E.G., POST OFFICE) AUTHENTIFICATION; SEND REGISTRATION/ LOGON TO HOST RECEIVE REGISTRATION' AUTHENTICATE 301 INSTANTIATION 305 INSTANTIATION 308 306 SEND REGISTRATION 307 w RECEIVE REG.;FULLY IACK FULLY QUALIFIED;START QUALIFIED,START TIMER IP. TIMER 309 • 321 -6— VIRTUAL SESSION ESTABL SHED .-4—SESSION ESTABLISHED-1'v 1• JERRY•FOR MAIL H RECEIVE NEW MAIL • FOR MS 320 24 • RECEIVE MAIL, RECEIVE MAIL FORWARD MAIL TO VSM FORWARD TO CLIENT ACKNOWLEDGE 322 UPDATE TIMER UPDATE POST OFFICE BOX(E,G., MARK READ) 1 327-J • • 326 UPDATE TIMER 328 331 • • • 332 7-- 330 OTHER DATA EXCHANGE --0 ' OTHER DATA EXCHANGE' OTHER DATA EXCHANGE UPDATE TIMER I FIG.3 7 341 REMOVE QUALIFICATION,' LOGOFF EXHIBIT 14 PAGE 4 )1 LOGOFF CLIENT U.S. Patent MS/CLIENT 6,101,531 Sheet 4 of 8 Aug. 8, 2000 HOST/SERVER COMM SERVER QUERRY OBJECT H FOR MAIL RECEIVE QUERRY 1 408---J 406 ----- FILTE AT HOST? 410 414 416 / RECEIVE MAIL; I. ACKNOWLEDGE • • • 412 APPLY FILTERS; SEND QUALIFYING MAIL RECEIVE QULIFYING MAIL; FORWARD 1 RECEIVE MAIL APPLY FILTERS 420 ------ FOWARD MAIL 4'--- 4113- FORWARD QUALIFYING MAIL z---424 RECEIVE MAIL; ACKNOWLEDGE 422 ACKNOWLEGE (LIST QUALIFYING, UNQUALIFIED MAIL) • , 430 - X426 • • GENERATE MAIL 1 432 APPLY FILTERS I i NO ,,,.--- 434 FORWARD QUALIFYING MAIL ATTACHMENTS; RETAIN; ALL UNQUALIFIED MAIL / 436 FOWARD MAIL 438 1 ••• 440 USER OVERRIDE, SEND H UNQUALIFIED MAIL -.--- 442 FOWARD MAill • • • RECEIVE; ADJUST CLIENT PROFILE/OBJECT CHANGE FILTER SETTINGS ACK FIG.4 EXHIBIT 14 PAGE 5 ,---- 444 ,..--- 428 MARK INDEX II U.S. Patent Aug. 8, 2000 6,101,531 Sheet 5 of 8 602 APPLY FILTERS TO MAIL MSG SIZE> FILTER SIZE? 604 YES 606 TRUNCATE MESSAGES NO 518 TEXT ATTACH -MENTS>PERMITTED NO OR SIZE? 608 YES 610 [ FORWARD QUALIFYING MESSAGES II NO F1G.5 TRUNCATE/OMIT I MESSAGES FILE ATTACHMENTS PERMITTED? 616 yEs 612 NO OMIT FILE/FLAG J [ SEND MESSAGES F1G.6 EXHIBIT 14 PAGE 6 614 U.S. Patent Aug. 8, 2000 MS/CLIENT 6,101,531 Sheet 6 of 8 HOST/SERVER COMM SERVER RECEIVE QUERRY I APPLY FILTERS SEND QUERRY 704 702 ) 706 YES • • • 411 SEND QUALIFYING MAIL 710 G> I URE IDEN 1 IFYING --- INFORMATION FOR EACH NON-QUALIFYING MAIL, SEND RECEIVE ID INFO, SAV IN SUMMARY INDEX WAIT PREDETERMINED PERIOD? 7--720 RECEIVE; UPDATE CLIENT SUMMARY INDEX, PROMPT USER 722 USER REQUESTS SPECIFIED MAIL;SEND REQUEST(E.G., SERIAL NO.) 730 RECEIVE MAIL; ACKNOWLEDGE, UPDATE INDEX 716 F4 DETERMINE CLIENT SUMMARY INDEX CONTENT SEND SUMMARY INDEX DELTA 724 ..,\ RECEIVE REQUEST, i FORWARD OW; TO POST OFFICE 712 r MARK QUALIFYING AN NON-QUALIFYING MAIL 718 m... (726 RETRIEVE SPECIFIED I MAIL, FORWARD RECEIVE FORWARD TO CLIENT ■„... 728 732 UPDATE INDEX, SEND 1 ACKNOWLEDGEMENT 734 MARK MAIL AS READ FIG. 7 802 801 CLIENT 1 SUMMARY SERIAL NO.1 HEADER INFO.1(E.G.,AUTHOR:SUBJECT,DATE/TIME IN; INDEX SIZE:ACKNOWLEDGEMENT/S1ZE:PRIORITY) SERIAL NO.2 HEADER INFO 2 FIG. 8 EXHIBIT 14 PAGE 7 U.S. Patent Aug. 8, 2000 MS/CLIENT ,— 902 FORM REPLY (NEW CONTENT) COMM SERVER GENERATE OPTIMIZED REPLY="DELTA" BETWEEN REPLY AND A PREEDING MESSAGE, AND PRECEEDING MESSAGE IDENTIFIER 1, /--- 906 COMPARE OPTIMIZED REPLY AND STANDARD REPLY,SEND SHORT -FST HOST/SERVER RECEIVE OPTMIZED REPLY 908-i REQUEST PRECEEDING MESSAGE CORRESPONDING TO PRECEEDING MSS.ID /912 910 "' RECONSTRUCT REPLY USING DELTA AND PRE CEEDING MESSAGE - i SEND REPLY TO ADDRESSEE --Po RETRIEVE PRECEEDIN MESSAGES;SEND TO COMM SERVER -914 916 ,---918 RECEIVE REPLY FOR CLIENT 14 920N * COMPARE REPLY TO PROCEEDING MESSAGE TO SOURCE/ADDRESSOF FROM CLIENT(IN INDEX) FOR CONTENT MATCH GENERATE OPTIMIZED REPLY=DELTA PLUS PRECEEDING MESSAGE IDENTIFIER 928 EXHIBIT 14 PAGE 8 ••• • •• 922 4 924 —926 SEND OPTIMIZED REPLY( RECONSTRUCT REPLY , 930 UPDATE INDEX; limi UPDATE INDEX, ETC. ACKNOWLEDGE, - 6,101,531 Sheet 7 of 8 FIG. 9 U.S. Patent Aug. 8, 2000 MS/CLIENT 952 ADMIN/SERVER COMM SERVER SEND MESSAGE 6,101,531 Sheet 8 of 8 MESSAGE PARAMETER(E.G. SIZ , ES CLASS) <USE LIMIT(FROM 956 CLIENT OBJECT RD • • • FORWARD MESSAGE 958 NO 964 USER UPDATE CLIENT OBJECT/ YES PRIVILEDGE QUAL1F DATA BASE REFLECTING OR OVERRID NEW TRANSACTION TOTAL 9 (ESTIMATED), DETERMINE NO 966 ---- NEW USE LIMIT FORWARD NOTIFIER T CLIENT, (OPTIONALLY) ADMINISTRATOR FORWARD NOTIFIER T ADMINISTRATOR OF 1)FORWARD REQUEST ANY OVERRIDE; ALERT TO ADMINISTRATOR TO CLIENT OR ,-962 2)PROCESS CHARGE/ DEBIT AMOUNT,ADJUST VERIFY PRIVILEGE; RI LIMIT IF APPROVED ALERT ADMINISTRATO 972 "-974 UPDATE USE LIMIT,NCi, PROCESS REQUEST FOR -TIFY CLIENT PRG, ETC. APPROVAL OF NEW LIMI T, ' 976 — NOTIFY COMM. SERVER 980 NEW USE LIMIT END < ALERT THERESHOLD? / 968 ALERT CLIENT USE LIMIT REACHED ,-970 OPTIONALLY(IF CAPABLE) 1)SEND REQUEST TO ADMINISTRATOR FOR ADDITIONAL ALLOCATION 2)AUTHORIZE COMM. SERVER PROVIDER FOR ADDITONAL CHARGE /DEBIT lUPDATE PRG USE LIMIT 978 956 ALERT CLIENT Iv 4 141 YES w 982 FORWARD NOTIFIER T CLIENT, (OPTIONALLLY) ADMINISTRATOR 986 it RECEIVE BILLING INFOR -MATION FROM PROVIDER, 988 REPLACE ESTIMATED USE UPDATE PRG USE LIMIT, 11 ._ CHARGES IN BILLING INDEX, UPDATE DIRECT ALERT CLIENT OBJECT REFLECTING NEW TRANSACTION TOTAL, UPDATE USE LIMIT, NOTIFY w CLIENT, ADMIN. CLIENT REQUEST • • • DOWNLOAD OF CURRENT BILLING INDEX UPDATE EVENT OCCURS (E.G., START NEW • • • AI-BILLING CYCLE); ADJUST LOSE LIMITNTIFY CLIENT EXHIBIT 14 PAGE 9 • •• 92 F1G.10 6,101,531 1 2 SYSTEM FOR COMMUNICATING USER-SELECTED CRITERIA FILTER PREPARED AT WIRELESS CLIENT TO COMMUNICATION SERVER FOR FILTERING DATA TRANSFERRED FROM HOST TO SAID WIRELESS CLIENT The present application is a continuation of U.S. application Ser. No. 08/574,537, filed Dec. 19, 1995 now abandoned, entitled "Method and Apparatus for Virtual Session Communications" by Gene Eggleston and Mitch Hansen, commonly owned together with this application by Motorola, Inc. FIELD OF THE INVENTION The present invention relates to communications and more particularly an improved method and apparatus for transferring data in a communications system. BACKGROUND Further, many processes, like that of a typical email reply, are wasteful of bandwidth by resending all earlier messages each time a new reply is generated, even though the earlier messages may still be stored at both ends of the wireless 5 network. In addition to the above concerns over how to optimize the types and amount of data being transferred, there is additionally a problem in a lack of effective techniques for monitoring and even controlling an aggregate use of tariffed 10 networks. While the network service providers have means for tracking use by an individual unit basis, which is totaled in periodic billing statements, this information is typically unavailable to users or their managers/application administrators. Thus, users and managers are typically left without 15 any effective means for controlling the level of messaging during a billing cycle, and can only monitor or react to usage following the service providers periodic statements. There remains therefore a need for an improved means for data communications that solves these and related problems. 20 The last 10 years have seen a tremendous increase in the demand for communications services, including both wired and wireless networks capable of handling data communications. Unlike real-time voice services, such as standard telephony or cellular wireless services, in which circuitswitched communications are used because of the sensitivity of users to the timing of oral dialogue/voice data, greater efficiencies can often be achieved in non-voice data communications through the use of packet-switched or hybrid communications systems. This is particularly the case with communications to remote users (e.g., persons sending messages via one of the well-known available wireless networks like GSM (Global System for Mobiles) or AMPS (Advanced Mobile Phone System) cellular), where protracted circuit-switched sessions into a mail server or LAN (local area network) could be prohibitively expensive due to the high per-minute session charges by the wireless service provider. One solution to this problem has been for users to limit, as much as feasible, their communications to sessionless communications. This can be done, e.g., by subscribing to additional email services that can receive LAN/WAN (wide area network) email and send out broadcast pages and transmissions to registered users, in lieu of requiring a user to maintain a session with a mail server. However, this disadvantageously requires subscription to an additional service, and is typically limited in the types of applications supported. With the rapid growth in emerging sessionoriented applications—like the popular client server application of Lotus Notes®—the need is growing for more cost effective solutions to providing connectivity of such sessionoriented applications and users remotely located from their host servers. Regardless of whether a session-oriented or session-less communication service is used, it is also desirable to limit the amount of information communicated between a remote user and host, both to save off-site user's time and to limit the costs arising from the more expensive rates for remote communications. Unfortunately, typical applications like email do not provide for user-selected methods for choosing and limiting the volume of down-loaded communications, or for filtering uploaded communications. Thus, a user who wants to receive remote messaging is left with an option of receiving all his messages, even the ones he or she might otherwise be willing to leave unread until a later time when no longer using expensive remote communications services. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of a communications system according to a first embodiment of the invention; 25 FIG. 2 is a block diagram of a communications system according to a further embodiment of the invention; FIG. 3 is a flow chart illustrating virtual session data transfer between the different functional entities of the wireless communications system of FIG. 2; 3 0 FIG. 4 is a flow chart illustrating a pre-stage filtering embodiment for data transfer between the different functional entities of the wireless communications system of FIG. 2; FIG. 5 is a flow chart illustrating one embodiment of 35 pre-stage filtering for data transfers; FIG. 6 is a flow chart illustrating another embodiment of pre-stage filtering for data transfers; FIG. 7 is a flow chart illustrating a message summariza40 tion and selection embodiment for data transfer between the different functional entities of the wireless communications system of FIG. 2; FIG. 8 is a diagram illustrating an embodiment of a summary index for use in the process of FIG. 7; 45 FIG. 9 is a flow chart illustrating an optimized reply embodiment for data transfer between the different functional entities of the wireless communications system of FIG. 2; and FIG. 10 is a flow chart illustrating a rate governor 50 embodiment for data transfer between the different functional entities of the wireless communications system of FIG. 2. 55 DETAILED DESCRIPTION These problems and others are solved by the improved method and apparatus according to the invention. A presently preferred first main embodiment of the invention is a system including a virtual session manager (VSM) for 60 establishing and maintaining a sessionless communication path with a first data processing device (e.g., a mobile client) on the one hand and a session-oriented communication path with a second data processing device (e.g., a host system). The session-oriented communication protocol with the host 65 system permits remote access to, e.g., LAN-based applications, while the virtual session, via a sessionlessoriented communication protocol, between the VSM and EXHIBIT 14 PAGE 10 3 6,101,531 4 remote (i.e., coupled via a tariffed network or connection) main rate governor is maintained at the communication client permits this access to be carried out without the server, allowing access, control and the like by system expense of a dedicated/circuit switched connection. administrators and the like. A further rate governor, respon sive to the main rate governor, may also be used at the In a second main embodiment, a prestage filter stage is provided for applying user-definable filter parameters (e.g., 5 remote unit. By means of this rate governor a mechanism is provided for both limiting user or group data transfer beyond reject, pass, or granularity filters) on data being transferred a set amount, as well as providing alerts to users as the limit between the remote communication unit and communication is approached. server. For downloading, e.g., email from a host post office, a communication server controller preferably either for- Turning now to FIG. 1, there is generally depicted a wards the filter parameters in a query object or message to 10 communication system 100 in accordance with a first the post office to apply and return qualified mail, or the embodiment of the invention. This system is configured to communication server receives all unprocessed mail and support one or more user devices such as wireless subscriber applies the filters locally, only acknowledging as processed units (i.e., mobile station (MS) 105) communicating with that mail which is qualified. For uploading, e.g., email from host processor 115 via an infrastructure including base a client, a client controller applies an upload prestage filter is station 120 and intermediate system 125 coupled to a data so as to retain all filter rejected mail, while transmitting mail network 130. In the illustrated case mobile station 105 is a passing the filters. Thus, only desired data transfers (i.e., portable computer having an rf (radio frequency) modem those meeting user defined filters) are communicated over 106. A communications server 110, including a virtual the expense-bearing networks between the remote unit and session manager (VSM) and query manager (QM), is communication server. 20 coupled between the public data network 130 and the host In yet another main embodiment, a select and summary server 115. The virtual session manager and query manager (S&S) listing or index is used to provide user flexibility in are, preferably, an appropriately configured data processing reviewing and requesting otherwise filtered data. Both the device, the VSM and QM program being shipped for loading user's remote communication unit and communication on the server 110 via any convenient means such as a server maintain a S&S index containing identifying 25 machine-readable CD-ROM 111 (compact disc-read only (summary) information about data which has not been fully memory) or the like. Counterpart client-communications transferred between the communication unit and communi- software, e.g., a prestage filter and rate governor, can be cation server. As new data is reviewed and filtered for shipped via a similar convenient form like CD-ROM 107, transfer, identifying/summary information is captured for downloaded directly from server 110 to subscriber 105 (also any non-qualifying data by either a host unit or the com- 30 being, e.g., a data processing device, by which is meant munication server. This information is stored in the com- virtually any processor (but not a human) capable of promunication server's S&S index, and at least periodically cessing data for a programmed result, whether a general transferred via update messaging to the remote communi- purpose computer or more specialized electronic processor), cation unit. Upon reviewing its updates or its S&S index, the or the like. user may send a request for such of the data that it desires 35 In this embodiment the mobile user 105 communicates partial or full transfers for further review. Thus, a cost with the server/VSM 110 using any appropriate data protoefficient review mechanism is provided to users for deter- col being used by the data network 130, as necessarily mining whether to transfer data that otherwise fails selected modified for transport over the wireless infrastructure; the filter parameters. wireless infrastructure could be, e.g., any private system like In a fourth main embodiment, a method and apparatus for 40 ARDIS® or DataTAC®, CDPD (cellular digital packet optimized reply to messaging is provided. When sending a data), GPRS (GSM Packet Radio Service), and the like. reply, the remote communication unit's controller generates Thus, a sessionless data flow between the mobile user 105 a delta (e.g., data representing the content difference and server/VSM 110 occurs on an event driven basis, and no between two messages) between a preceding message and costly connection is maintained when there is nothing being the reply message, and forms an optimized reply using the 45 communicated. In order to keep connectivity costs to a delta and an identifier of the preceding message. On receiv- minimum, the server 110 is preferably connected to the ing the optimized reply, the communication server uses the LAN/WAN on which the host 115 is also connected, via any data unit identifier to retrieve the preceding message from a standard LAN/WAN communication channel (e.g., a bus or further host (e.g., the post office mailbox of the user asso- backbone). This allows the communications server 110 to ciated with the remote unit), reconstructs the full reply from so advantageously maintain the same session with the host 115 the retrieved message and the delta, and forwards the full that the client 105 typically enjoys when connected to the LAN/WAN. Thus, by use of the server 110 the client 105 can reply to the addressee. When receiving a reply for the remote unit, an index is preferably maintained at both the remote achieve a virtual session with the host 115 with almost the unit and communication server of mail stored at the remote same access as if directly connected to the host's 115 LAN, unit. Resort is made to this index to determine a preceding 55 but at a substantial reduction in the cost of communicating message forming part of the reply. An optimized reply is via the wireless network and PDN 130. similarly formed from a delta and identifying information of FIG. 2 illustrates an alternative communication system the preceding message, and sent to the remote unit. In this 200 embodiment of the present invention. A first client, a manner, the volume and expense incurred in reply messag- mobile end system (M-ES) computer including a user device ing is greatly reduced, by only sending a delta and small 60 201, is in communication with a base station (BS1) 218 of header (i.e., the identifying information). a wireless communication system. This base station 218 is Finally, in a fifth embodiment, a rate governor is provided coupled, e.g., on a same bus or via bridges/routers, to a for monitoring and controlling the amount of communica- communication server 220 which includes VSM 230. An tions between the remote unit and communication server. electronic mail (email) post office is coupled locally to VSM Preferably, as threshold(s) are passed a user is alerted to 65 230, either as another program running on the same comamounts (time and/or charges) spent or remaining, and once munications server 220 or located on another server 240 of a use limit is reached further communication is restricted. A the communications server's 220 LAN/WAN. It is not EXHIBIT 14 PAGE 11 6,101,531 5 6 important, however, where the post office is located for purposes of operation of the VSM 230, as is illustrated by other application hosts B and C 255,260 being in communication via other networks such as a public data network or public switched telephone network 250. In fact, the same user 201 could be concurrently coupled via the VSM 230 to, for example, a local email post office 240, a remote clientserver host 255, a further database host server (not shown), an administrator host server 260, a multimedia host, a voice processor, etc. It should be understood that for purposes of this application, a first device or component is responsive to or in communication with a second unit or component regardless of whether the first and second units are directly coupled or indirectly coupled, such as via intermediate units, including switches that operatively couple the units for only a segment of time, as long as a signal path can be found that directly or indirectly establishes a relationship between the first and second units. For example, the client computer 105 is in communication with the VSM server 110 even though intermediate system (e.g., a router or switch) 125 and a packet network 130 having multiple switches etc. are disposed between the user device 105 and VSM server 110. In the illustrated case client 201 includes a data transfer manager or exchange unit 206, which in simple form could be an appropriately programmed electronic processor 207 (e.g., a general purpose CPU (central processing unit) and memory or data store 211. A timer 205 is also preferably employed in the data exchange control process, as will be explained further in connection with the flow chart of FIG. 3 below. A typical client 201 would also include some form(s) of user interface such as display 204, a data encoder/ decoder 203 to accommodate the system communications protocol(s), and a transceiver (if using rf or infrared communications) and a modulator-demodulator (or modem) 202 to connect to a wireless or wireline communications network. Transceiver/modem 202 in this case would either include a built-in or attached user module for wireless LAN communications; the specific type will vary depending on the system, e.g., including PCMCIA (personal computer memory card interface association) wireless modems, and attached or built-in PSTN (public switched telephone network) modem, etc. Specific features of data exchange unit 206 preferably includes (as more fully described below) a prestage filter (PSF) manager 208, rate governor (RG) 209, user profile store 212, select and summary index store 213, and mail store 214 (a store being any available device (e.g., ROM (read-only memory), disks) or program (e.g., a database) for storage of the specified information). The communication server 220 preferably includes a data transfer manager or controller 229 having a VSM 230, memory stores for storing active client profile (user parameters) and inactive client profile information 226 and 227, a timer 224, and optionally some form of protocol translators or formatters 222. The VSM 230 serves to manage the virtual session with the client 201 and session with host systems 240,255 and/or 260 based on the parameters loaded into the active user parameter store/profile memory 226 or object. Controller 229 preferably also includes a query manager (QM) 231 for controlling specific processes (e.g., sending messages to a post office to query for unprocessed messages and forwarding received messages etc.), and a prestage filter 232 and rate governor 234. Memory 225 also preferably includes a client select and summary index database or store 228, which will also be described more fully below in connection with FIGS. 7 and 8. The protocol translators 222 serve to format or code the messages as appropriate for transport between the VSM 230 and client 201; these include, e.g., appropriate protocol software that can be located at the communications server, or any other convenient processor per design of the given communication system. By messages is meant any appro5 priate data unit (whether a frame, datastream, packet, or other format), including objects, datagrams, etc., for containing information being communicated. Communications server 220 is also illustrated as supporting additional users, e.g. user module 216, communicating 10 via different access points, e.g., control module (CM) 217 of a wireless LAN and base station 219, all access points 217-219 being coupled via a common bus, backbone, etc. These base stations can be part of the same communication system, similar systems owned by different service is providers, or even different systems, all of which may be different from the communications server service provider. Thus, for example, a single communications server can support at one local region 215 an ARDIS® node, a RAM® node, a wireless LAN controller module, a CDPD node, an 20 in-building cordless telephone node, etc., allowing users from a variety of systems to access the same communications server and post office. Users not registered could access through the appropriate one of these nodes along the model of FIG. 1, i.e., via PDN 250 to a remote communi25 cations server having their VSM/QM. Thus, any number of system configurations is possible, limited only by the network services provided and the user's preference. A process by which a VSM manages communications between client and host is illustrated in the flow chart 30 embodiment of FIG. 3. This process typically begins with a user event, such as instantiation (forming) of a communications object at the client and sending a registration message (steps 301-302). Alternatively, the infrastructure could initiate the communications by sending a page or the like 35 requesting the client to register (for example, when the client has registered with the wireless system but not yet requested registration with the communications server). In any event, once a registration message is received by the communications server, it preferably authenticates and otherwise quail40 fies the client, including sending a logon/registration message to the host for its authentication of the client (steps 303-305). Upon successful authentication, the communications server instantiates a client object (CO) for the communications session including client parameters retrieved 45 from an inactive client parameter store, as modified by the user in his registration or subsequent messages (step 306). These parameters include at a minimum client and host identifiers, but may also include additional preferences based on the type of communications involved. Also, the so registration and authentication process can be handled by the VSM, or alternatively by another appropriately programmed entity of the communications server. Following instantiation at the server, a response message, e.g., a further registration message, is sent to the client, and an acknowledgment 55 (ACK) returned to the server; both client and server then retain the instantiated objects as fully qualified, and start session timers (steps 307-309). At this point a virtual session has been established between the client and the VSM, and a regular session established between the VSM and host 60 computer. If the registration is not successful, then any instantiated object is deleted, with the client returned to an inactive status. Upon establishing the virtual session, a query is preferably generated by query manager requesting unprocessed 65 data for the user, and the VSM forwards the query to the host (step 320). In the case of email, e.g., this might include generating a request message for all unread mail in the users EXHIBIT 14 PAGE 12 6,101,531 7 8 post office box. The post office then checks for new mail received, and forwards all such mail to the VSM (steps 321-322). Because the VSM has established a LAN session with the post office, these communications are performed relatively quickly, e.g., in accordance with the LAN's and host's typical processing for their current loading level. The VSM in turn forwards the data (i.e., mail) received via the virtual session transport (step 323). For example, in the case of FIG. 1 where PDN 130 is an ISDN (integrated services digital network) network connected to a CDPD wireless network, the mail would be appropriately packetized by the communications server and delivered via the serving BS 120 according to ISDN/CDPD system protocols. This can take up to several minutes or more for a moderately sized mail package. However, since the data is being delivered in a sessionless mode, the amount of time the communication channel (including the more expensive wireless communication channel portion, as well as the portion via PDN 130) is tied up is kept to a minimum. This also translates into a significant cost savings for the user, since the user is only charged on a per packet basis for mail when it is actually transported, and doesn't have to pay for a prolonged session to keep connected to the post office in order to receive new mail. Finally, upon receipt by the client, appropriate acknowledgments are sent and the post office box updated, e.g., by marking the mail as read or processed (steps 324-326) While in some systems it may be advantageous to store some of the data at the communications server, in the case of email and the like it is presently envisioned that the communication server is preferably used in maintaining the sessions between client and host, and not as a remote server for the host. Thus, rather than have all new data from the host pushed down to the communications server, most data exchanges are preferably initiated, at some predetermined interval or intervals, by the communications server (e.g., by the query manager). Further, it is an inefficient use of resources to continue querying a host or attempting to deliver data when the client is no longer receiving at its remote location (occurring, e.g., when the client leaves a coverage area, or the user turns off its modem or processor). Thus, a process for either maintaining the client in an active status, or removing the client from active status in response to an event, is also preferably included in the VSM. One such process is to utilize timers at both client and VSM to determine when a virtual session is no longer active. The timers are first set upon registration, and are subsequently reset after each data exchange (steps 327-336). If no data exchange occurs within a predetermined period of time, say 20 minutes, both client and VSM would remove the client qualification (i.e., destroy the client object for the communication session) and, if desired, mark the client as being in an inactive status (steps 337-340). The VSM would also forward a logoff message to the host (step 341). In order to avoid an undesired time out, the client is preferably configured to send a short message after a predetermined period since the last data exchange, sufficiently prior to the time at which the timers elapse so that the VSM can receive it. Otherwise, if there are only intermittent data exchanges, the client may be required to frequently re-register; this in turn means the client will not be notified of outbound data until the client re-registers and is again coupled via the virtual session manager. Turning now to FIGS. 4 through 6, a presently preferred embodiment is shown for prestage filtering data for transfer between the different functional entities of the wireless communications system of FIG. 2. This typically begins with the generation of a query object or message at the communications server (step 406). This object/message may be created in response to a preceding client generated message (e.g., a request generated when clicking on an 5 application button requesting updates, executing the mail application, etc.), or in response to settings in the client profile. However, after updating the active client profile/ object for an active client application, the query manager is preferably programmed to send query objects at predeter10 mined intervals for each application being run by each active client, the intervals varying depending on the application type (e.g., longer for mail (about every 5?*** seconds) than for interactive applications like Lotus Notes (about every 1?*** second). Alternatively, the intervals could be user is specified via the client profile, for example to shorten the query intervals for time critical applications (e.g., for emergency services or "real time" applications), or lengthen the intervals when less frequent updates are desired (e.g., to conserve on traffic expenses for updates to a rapidly 20 changing, but non-time critical, group-ware file or document). The content of the query objects will vary depending both upon the application and client filter settings. One approach for mail applications is to have a predetermined number of 25 user-definable filter attributes stored in the client profile databases (e.g., stores 212 and 226-227 of FIG. 2). These attributes can include, by way of example, the priority of a message (e.g., urgent, normal, or low); the date on which the message is sent or posted; the size of the message (typically 30 uncompressed, i.e., the normal stored size; although transmission size or cost could also be used); the author of the message; and the subject of the message (e.g., key words in a subject line or in the text). These attributes can simply be used as reject criteria (e.g., reject all messages having "low" 35 priority, date before "12/15/95", size more than "2" kbytes (kilobytes), or subject not containing "project x"), pass criteria (all messages from "Boss") or a combination of both, the variety and complexity being a matter of design choice. These attributes also preferably include certain "granularity" 40 filters, i.e., filters additionally limiting the size of a message passing all or most of the other filters. Three possible examples of granularity filters are a truncation size filter (e.g., truncate the message after the first "100" bytes), and text or file attachment filters (e.g., indicating whether or not 45 to strip attachments). Thus, messages passing all criteria but message size could still be received in a truncated size meeting the message size criterion. Alternatively, messages failing the author or subject filters could still be passed with header information, by setting all rejected messages to be so passed with a text truncation size of "0" bytes. One skilled in the art will appreciate that a variety of other reject/pass filter criteria may be used, and the specific ones and combinations of user-definable (or even administrator-definable) features will be largely a matter of design choice depending 55 on factors such as the desired functionality, complexity, and application(s) (including filterable features). It is significant, however, that clients are now provided by the present invention with a means for effecting prestage filtering of their communications by virtue of the communications 60 server and definable filter settings, rather than having to choose between receiving no messages or receive all messages, including less important or expensive and timeconsuming transmissions. The prestage filtering is preferably performed at the host 65 server. This may be accomplished, for example, by passing the filter attributes in an appropriately formatted query object or message for use by the host application. In the EXHIBIT 14 PAGE 13 6,101,531 9 10 illustrated case a query object with the client filter settings is forwarded to the post office, and applied by a communications server object or CSO (instantiated at the post office when the virtual session is established). The post office/CSO reads/queries the query object for the filter attributes, and applies these criteria in the selection and formatting of unprocessed messages (steps 408-412). The filtered messages are then encapsulated and forwarded to the QM, which similarly forwards the filtered messages (with appropriate protocol translation) to the client (steps 414-416). Alternatively, where the host application is not designed to permit prestage filtering, all unprocessed messages can be forwarded to the communications server, where the filters are applied via a prestage filter (PSF) object or routine (e.g., PSF 232 of FIG. 2), with only qualifying/filtered messages being forwarded to the client (steps 410, 418-424). Through acknowledgments the post office is notified how to mark the mail index in both cases. For example, when prestage filtering at the post office, all forwarded mail would be marked as processed/read and all filtered mail as unprocessed (truncated messages being marked as either depending on design conventions, or if available marked as filtered or partially processed). If prestage filtering is done at the communications server only those messages forwarded to the client would be acknowledged and marked as processed (step 428). In addition to download/downlink filtering, prestage filtering is also advantageously used in upload/uplink transmissions. This can take the form of granularity filtering, or automatically retaining the whole data unit or message based upon filterable attributes for later transmission when on a lower cost network. In this case, each client would have a prestage filter (PSF) unit such as that of PSF 208 of FIG. 2 (e.g., a PSF object or routine drawing on selected attributes in the profile store 212). Each data unit generated is filtered using the user-selected criteria, with qualifying data being forwarded via the communication server (steps 430-436). If a data unit is not sent, it is retained locally for transmission later, e.g., when connected via a lower cost network to the post office. As an enhancement, the user could additionally be provided with a selection of types of send buttons (i.e., filtered send or unfiltered send), or be prompted with an alert dialogue or similar message when a message is filtered to decide whether to forward the data unfiltered (steps 438-440). Similarly, the user can be provided with several groups of filter settings that could be manually or automatically activated, so as to enable the client to adjust plural filter settings with a minimum effort, for example by switching to a more restrictive profile when entering important meetings (which profile could be automatically activated via an appropriately configured and coupled calendar program, etc.). While only the client need retain the upload filter attributes in its profile store, preferably both the communication server and client store copies of the download filter settings in their profile memories. This conveniently permits a client to review all settings whenever desired, and to change the settings locally. When the download settings are changed at the client, the changes are communicated to the communication server preferably as soon as the change is made, or as soon as a virtual session is established if the changes are made while offline from the communication server (steps 442-444). Further, where a summary index of filtered messages is maintained (as is described in connection with FIGS. 7 and 8 below), upon a change in filter settings the communication server may be automatically set to forward all messages previously rejected but now passing the new filter settings. FIGS. 5 and 6 illustrate two approaches to prestage filtering particularly useful for email filtering. In FIG. 5, a series of five reject filters are applied to each message. If a mail message does not meet any of the criteria (priority, date, 5 size, author, or subject/key word) then it is left unprocessed (steps 502-516). Once all unreviewed messages (i.e., all unprocessed messages, or if expanded marking is available all unprocessed messages not previously filtered) have been filtered, those not rejected are forwarded (step 518). FIG. 6 1 0 illustrates the application of granularity filters. If a message exceeds the filter size, it is appropriately truncated (including insertion of a note indicating truncation) (steps 602-606). Similarly, if there are text or file attachments, and these are marked to be filtered, they are stripped with, optionally, a note being inserted alerting the addressee that 15 the attachment was stripped (steps 608-614). Once filtered, the message is sent (step 616). FIGS. 7 and 8 illustrate a further enhancement, permitting the user to more conveniently review selected information 20 even for filtered/rejected data. In the preferred embodiment a query object or message is similarly generated by the communication server as described above. However, in addition to the profile information, the query object in this case includes a request for summary information about each 25 partially and fully rejected message (step 702). When the host (i.e., a post office server in the illustrated case) receives the query it applies the appropriate filters; if only qualifying mail is present, this is forwarded to the client as described above (steps 704-708). Where there is partially (e.g., 30 truncated) or fully rejected data, identifying summary information is captured for all rejected data (step 710). For mail this identifying summary information would include the message serial number, along with certain header information (801 and 802 of FIG. 8). This header information may 35 include any filterable attribute (e.g., date, author, subject, size, priority, attachment indicator) and is preferably client definable, so the client can decide how much header information it needs and how much to omit. All qualifying and non-qualifying (i.e., filter-rejected) mail is marked similarly 40 as described above (step 712). When the response object or message is received by the QM of the communication server, the encapsulated identifying summary information is saved to a select and summary (S&S) index, such as that illustrated by client S&S index 45 database 228 of FIG. 2 and the index structure of FIG. 8. This index is preferably created in response to the first query following full qualification, although one could retain a stored index when the client is inactive as long as the index is fully updated upon re-registration/qualification. In order so to minimize transmissions between the communication server and the client, only changes to the S&S index are forwarded, as summary delta data (i.e., a delta of the revised index to the immediately preceding index, the preceding index being an acknowledged version same as that stored in 55 the S&S index (e.g., S&S index database 213 of FIG. 2) of the client). Where only identifying summary information is received in response to the query object, one may additionally delay forwarding the delta information to the client for a predetermined period of time or until the next message 60 passing the prestage filters is forwarded, whichever comes first (i.e., the filter-rejected information more likely being less important, some users may prefer to receive S&S index updates less frequently in order to further reduce costs or interruptions) (steps 714-718). 65 Upon receiving the delta of the identifying summary information, the client updates its S&S index and, when appropriate, prompts the user (again, the prompt criteria EXHIBIT 14 PAGE 14 6,101,531 11 12 could be set for all messages, or some sub-set based on any filterable attribute, etc.). The user is thus able to review the summary information and make a determination on whether or not to override the filter rejection. For mail the user wants to read, the user indicates the decision by any appropriate means (clicking on the message, voice command, etc.) and an appropriate request generated (e.g., for all selected mail, for only a partially filtered version (e.g., truncated), etc.) (steps 720-722). The request is appropriately translated, as needed, and sent as a query object or message to the post office. Upon retrieval, the requested data is forwarded to the client via the QM. Upon receipt at the client, a read acknowledgment is generated and sent to the communication server. Preferably when the read acknowledgment is received at the communication server a further ACK (acknowledgment signal) is sent to the client, at which time both client and communication server update their respective S&S indices to remove the entry for read mail from the S&S index, and note any partially read mail. Upon acknowledgment, the post office further marks any read mail as processed (steps 724-734). As with prestage filtering, one skilled in the art will appreciate that many more filterable attributes and summary inputs are possible than those described, and which ones are available will depend on such factors as the desired functionality, complexity, and application(s) (including filterable features) for which the select and summary index is being used. The index structure may thus similarly vary significantly, as will the means for achieving similar indices for both the client and communication server; in other words, while one could simply periodically forward the whole index, where practical any one of a number of known delta (e.g., data representing the content difference between two files) or other update approaches for communicating less than the whole index are likely more preferable. What is significant, no matter the particular design approach selected, is that a summary index, showing unprocessed or partially processed data (e.g., that filtered), is available to a client for determination on whether to process the data further, with a substantially identical index being retained at the communication server in order to further reduce transmission requirements. FIG. 9 illustrates a yet further improvement, this embodiment permitting a user to minimize the data transmitted for responses to earlier data transmissions. This is particularly advantageous in the case of email, where it is common to append all prior messages in an email conversation to a reply, making for lengthy reply messages that contain substantial portions that are identical to mail already saved at the client or target unit. While this has come to be expected in email replies, it is also quite costly in time and tariff charges in bandwidth limited systems like most wireless communication systems. Starting from a client perspective, the process of FIG. 9 commences with a client formulating a reply to a received mail message, much as he or she would for any typical email application (step 902). However, when the user executes the reply, e.g., by clicking on a send button, the client controller (201 of FIG. 2) optimizes the reply message by calculating a delta or difference, using any appropriate delta routine, between the reply message and the preceding message. This delta is then formed into an optimized reply along with a message/data unit identifier for the preceding message/data unit (preferably the mail serial number, although any retrievable identifier of the preceding message may be used, such as header information, or even a CRC (cyclic redundancy check) value) (step 904). To ensure that only the shortest message is being sent, the controller additionally compares the reply message with the optimized reply to determine which is optimum for transmission (step 906). This determination may be made based on a comparison of the 5 message sizes, compressed and formatted message sizes, or any other convenient means for estimating which version of the reply will require the least bandwidth or transport cost. Thus, for example, a normal reply message to a very short message may be selected for transmission where the over10 head of the delta and message identifier make the optimized reply bigger than the normal reply message would be. However, in most instances it is anticipated that the optimized reply will be smaller than a normal reply message, providing significant savings to the client in time and costs. 15 When the optimized reply is received at the QM of the communication server, a determination is made on whether to reconstruct the normal reply message (i.e., form a replica reply) or to forward the optimized reply, based on known parameters (if any) of the target communication unit/client. 20 Thus, for example, where both the originating and target clients are active and served by the same communication server and thus are known to have optimized reply capabilities, and the target client was an addressee or originator of the preceding message identified by the message 25 identifier of the optimized reply, a reconstructed reply is not required. Rather, since the preceding message is either in the inbox or outbox of the target unit, the target unit can reconstruct the reply message from the identified mail in its mailbox and the delta. This advantageously allows band30 width to be minimized for both the sending and target clients. Further, if perchance the target unit has already deleted the identified preceding message, the controller of the target unit could, rather than acknowledge receipt, send a request for the normal reply message, which the commu35 nication server would reconstruct as described next. In cases where the target unit is not an active client with the communication server, the QM (or other appropriate entity of the controller) functions to reconstruct the reply message from the optimized reply. Because the communi40 cation server preferably does not retain a copy of client mail or data located on other hosts (such remote stores typically adding complexity and cost, while being unnecessary in view of the virtual session established via the communication server), it would use the identifier to retrieve the 45 preceding message from the host (e.g., send a query object or message to the appropriate post office) (steps 908-912). This can be implemented by requesting the preceding message from the client inbox, or from the originating unit's outbox (or even the target unit's inbox, if it is a cc: on the 50 preceding message). Because the serial number is a unique number widely used in email applications, this is the preferable message identifier for email systems. However, where this unique number is unavailable other identifiers may be used, including author, date and/or subject matches. Further, 55 for some messages it may even be advantageous to use other relatively unique values, such as CRC or other values, by themselves or together with other identifiers. It is relatively unimportant for purposes of the invention what the identifier is, as long as it is useful within the accuracy demanded by 60 the system design for retrieving the correct preceding message. Once the preceding message has been received by the communication server, it uses a counterpart delta routine to that of the client to reconstruct a replica of the reply message 65 from the delta of the optimized reply and the retrieved copy of the preceding message. Once reconstructed, the reply message is forwarded to the target unit(s), as well as to the EXHIBIT 14 PAGE 15 6,101,531 14 13 outbox or sent mail folder of the client's post office box within desired limits. Turning to FIG. 10, with reference also (steps 914-916). While some additional processing and to FIG. 2, one embodiment of such a rate governor is network traffic is required between the communication illustrated. This rate governor operates to track the approxiserver and host, this is relatively inexpensive compared to mate time and/or expense for client use, which can be as the savings achieved by using an optimized reply over the 5 simple as timing a circuit-switched connection, or where tariffed network between the communication server and packet data is being sent, timing (or estimating based on client. size) the time and/or cost of transmitting the packet over the tariffed network(s). In estimating the transmission value While the preceding approach can be implemented with(e.g., cost), a rate governor could better estimate actual costs out resort to a message index, it can be further optimized by use of indices at the communication server and client. In this 1 by taking into account known pricing factors established by each network service provider (e.g., rates by time of day, by case, a full index of each active client's mailbox (or other grade/quality of service (QoS) for packets, by size or bandapplication file(s)) is maintained at both the client and the width desired, etc.). These values would be maintained for communication server. This index could advantageously be application by the rate governor (234 of FIG. 2) as each data one of the S&S indices 213 and 228 of FIG. 2 designed to unit is received to determine an estimated transmission include all mail (although perhaps with less identifying information for received mail than for filter-restricted mail, is value. depending on factors such as the memory available and the In the illustrated case of an email application, upon amount of identifying information desirable). When an receiving a client-generated message the QM (or other optimized reply is received at the communication server, a appropriate controller entity of the communication server) search of the appropriate client index (e.g., first the target passes the pertinent packet information or message paramunit, if also an active client, otherwise the client's or 20 eter (e.g., the packet size from the header) to the rate originating unit's indices) for the message identifier of the governor, which in this case operates as a packet rate preceding message, indicating whether or not the preceding governor (or PRG). The PRG determines from the client message has been deleted. When the preceding message's object (or profile store) the amount of use time and/or charge identifier is present, the process continues as noted above, in still available (or alternatively, the amount already used, and other words by sending the optimized reply to the target unit, 25 limits allowed), and compares the use time remaining (e.g., or reconstructing the reply message and forwarding it to the a previously authorized or allocated transmission value) target unit. against the value for the message parameter (step 954). Replies being sent to the client can similarly use an Preferably several limits are established, including one or optimized reply to minimize messaging sizes. Thus, for more alert thresholds. These alert thresholds would serve to example, where a reply is received by the communication 30 warn the client each time a certain threshold is passed in server which has the client as an addressee, the communiamounts of time/charge used or remaining, permitting the cation server is capable of generating a delta between the client to limit use as needed to stay within budget, or to seek reply message and a preceding message known to be stored a higher limit in advance of the point at which the use limit in a mail database (e.g., memory 214 of FIG. 2) of the client. is reached. This use or transmission limit serves as the The preceding message is most easily identified if an addi- 35 budgeted limit for data transfers. Unless a user is privileged, tional identifier is included with the reply for ease of once the use limit is reached further communications/data searching in the client's index. However, where such is not transfers are restricted. In the simplest form, such transfers included, identifier's can be extracted from the text (e.g., are restricted by alerting the client that the use limit has been author, date, recipient, subject) for comparison matching. reached, terminating the current session and preventing Alternatively, a comparison of the text of the reply message 40 further sessions until additional use limit time/charge is can be used in determining the preceding message. For authorized. Alternatively, certain messaging could still be example, a series of preceding messages could be retrieved permitted (based, e.g., on any filterable criteria—e.g., perfor textual comparison; or alternatively an identifying value mitting messages to the administrator but not a further for all or selected (e.g., sent) mail can be maintained (e.g., communication unit), but with reminders that routine mesby calculating the text CRC value and storing it in the 45 sages will not be forwarded. This would advantageously index), and a check of selected portions (e.g., all portions allow critical messages, messages to an administrator (e.g., below insertions identifying preceding messages in the text) requesting additional authorization), etc., to still be of the reply message text can then be performed. The latest transferred, although it does not prevent a user from running or largest matching preceding message is the selected up excess charges for messaging to the communication (which could be either a message sent to, or sent from, the so server. A PRG may thus also be advantageously used in the client), so as to minimize the delta, and the delta calculated client (e.g., PRG 209 of FIG. 2), signaled by the PRG of the between the preceding message and the reply message. An communication server to automatically set certain prestage optimized reply is then formed including the delta and filters to restrict all but certain message transfers until a new preceding message identifier recognizable by the client. This use limit is provided. If a user were to bypass this client PRG optimized reply is then forwarded, and reconstructed at the 55 and continue improper messaging, all further sessions could client into the reply message. In other words, the client be terminated by the communication server with notification retrieves from memory the message corresponding to the to the administrator and client. message identifier, and forms a replica of the reply message If the user is privileged, data transfers would still continue from the delta and message. Once acknowledged, both client despite the user limit having been exceeded. However, an and communication server indices are appropriately updated 60 alert would still preferably be sent to both the client and to reflect the mail transfer (steps 918-930). administrator, allowing the administrator to verify the priviThis embodiment thus provides an efficient process for lege and reset the use limit if desirable, and the client to still sending reply data between a client and the communication be aware it has passed a targeted use amount (steps 956-968 server, without requiring the costly transfer of earlier transand 980-984). In any event, after each data transfer the mitted portions of the reply data. 65 client object or store is updated to reflect the new estimated In a final embodiment, a rate governor is provided so as transaction total (e.g., time remaining, total expense, etc.) to assist clients in maintaining their messaging and expenses (step 958). EXHIBIT 14 PAGE 16 6,101,531 15 16 As mentioned above, if a user is not privileged it is preferable to allow the client an additional data transfer to an administrator requesting additional allocation of time/ charges. This request would be forwarded by the communication server to the administrator host, where it would be processed for approval. If approved, the administrator would notify the communication server to adjust the use limit by a specified amount. Alternatively, if there is no system administrator, but charges or debits are handled through a communication server service provider, the client may send any appropriate authorization for additional charge/debit to the communication server (e.g., by sending an encrypted account number and identifying information like a PIN (personal identification number). Once the charge or debit is processed and approved to the service provider's satisfaction, the amount of charge or debit would be used to adjust the use limit. A notification would also be forwarded to the client of the new use limit, with the client PRG being updated accordingly (steps 970-978). In addition to updating the use limit in response to a user or administrator request, the rate governor can also be advantageously set to automatically update the use limits upon the occurrence of a predetermined update event. Thus, for example, where billing and budgeting is done on a monthly cycle, and the administrator has set rate governor preferences so as to automatically reset the use limit on the first day of the next billing cycle, the communication server will automatically reset the client use limit at the specified time and in the specified amount (step 992). Moreover, in order to achieve an even more accurate billing control, the communication server could be coupled with the tariffed network service provider(s) so as to receive periodic charge statements for client data traffic, as well as updates for tariff rates, etc. In order to take advantage of these statements, a billing index would be maintained for each client estimating use and charges for each data transfer. Upon receiving the periodic charge statement (e.g., forwarded once a day during an administrative window) the estimated use entries are replaced by the actual use and charges from the statement, and the client profile (and object, if active) is updated to reflect a corrected use limit, etc. The administrator is notified, and the client is notified upon the next transaction, of the updated amount. If desired, the client or administrator can request a download of the current billing index showing the most recent estimated and actual charges (steps 986-990). Finally, one should appreciate that the above process is equally applicable to groups as well as to individual clients. Thus, the PRG can advantageously be used to set use limits for groups and supergroups of users, as well as for individual clients as described above. Thus, where one of the applications being used is groupware, as opposed to the email example described above, different groups can be assigned group use limits for groupware data transfers (while retaining individual use limits for separate email or data transfers, etc.). To avoid one or two users exhausting the group's authorized limit, individual use limits can still be set for each client, although with more flexibility, e.g., to draw on unused group time before requiring additional allocation from an administrator, to permit another user of the group to yield a portion of its individual use limit, etc. As should be apparent, many variations exist on how the rate governor is structured, depending on the applications being used, clients and groups operating, the interactivity with service providers, complexity or simplicity desired, and many other related and unrelated factors. One skilled in the art will appreciate that there are many variations that are possible for the present invention, only a limited number of which have been described in detail above. Thus, for example, while the embodiments above describe application to clients communicating in certain systems, one should appreciate that it has application to any 5 communication system, wired or wireless, client-server, distributed or other networks, etc., in which the user is remote from a host. It can also be used with almost any application program or groups of programs (e.g., transferring database, wordprocessing, graphics, voice etc. files, executing programs and control messages, etc.), not just 10 email or groupware. Moreover, while processor 206, controller 229, timers 205 and 224, data stores 211 and 225, and other circuits, are described in terms of specific logical/ functional/circuitry relationships, one skilled in the art will appreciate that such may be implemented in a variety of 15 ways, preferably by appropriately configured and programmed processors, ASICs (application specific integrated circuits), and DSPs (digital signal processors), but also by hardware components, some combination thereof, or even a distributed architecture with individual elements physically 20 separated but cooperating to achieve the same functionality. Thus, it should be understood that the invention is not limited by the foregoing description of preferred embodiments, but embraces all such alterations, modifications, and variations in accordance with the spirit 25 and scope of the appended claims. We claim: 1. A method of communicating data units over a wireless network between a client communication unit and a host device via a communication server, the method comprising, 30 at the communication server: filtering data units based on a first set of user-selected criteria to produce filtered data units; communicating the filtered data units to the client communication unit; 35 receiving a second set of a plurality of user-selected criteria, wherein the second set of the plurality of user-selected criteria has been previously prepared at the client communication unit and, when completed, has been sent to the communication server in a virtual 40 session; filtering subsequent data units based on the second set of the plurality of user-selected criteria to create subsequent filtered data units; and communicating the subsequent filtered data units to the 45 client communication unit. 2. The method according to claim 1 further comprising truncating a filtered data unit if the filtered data unit exceeds a first filter size. 3. The method according to claim 1 further comprising 50 truncating a subsequent filtered data unit if the subsequent filtered data unit exceeds a second filter size. 4. The method according to claim 1 further comprising: maintaining a summary index of data units that did not pass the first set of user-selected criteria to produce 55 unfiltered data units; and automatically forwarding the unfiltered data units to the client communication unit that pass the second set of the plurality of user-selected criteria. 60 5. A method of communicating data units over a wireless network between a client communication unit and a host device via a communication server, the method comprising, at the client communication unit: communicating a set of a plurality of user-selected criteria 65 to the communication server; storing the set of the plurality of user-selected criteria locally in a memory; EXHIBIT 14 PAGE 17 6,101,531 17 18 receiving filtered data units from the communication server based on the set of the plurality of user-selected criteria; reviewing the set of the plurality of user-selected criteria 5 locally; modifying the set of the plurality of user-selected criteria locally to produce a modified set of a plurality userselected criteria; storing the modified set of the plurality of user-selected 10 criteria locally in the memory; communicating the modified set of the plurality of userselected criteria to the communication server; and receiving filtered data units from the communication server based on the modified set of the plurality of 15 user-selected criteria. 6. The method according to claim 5 wherein the steps of communicating occurs when a virtual session is established between the client communication unit and the communi2 cation server. 7. The method according to claim 5 wherein the step of modifying comprises modifying the set of user-selected criteria at the client communication unit while on-line with the communication server. 8. The method according to claim 5 wherein the step of 25 modifying comprises modifying the set of the plurality of user-selected criteria at the client communication unit while off-line from the communication server. 9. The method according to claim 5 further comprising providing the client communication unit with several pre- defined groups of filter settings that are selectively communicable to the communication server. 10. The method according to claim 5 further comprising providing the client communication unit with several groups of filter settings that are manually activated. 11. A method of communicating data units over a wireless network between a client communication unit and a host device via a communication server, the method comprising: filtering data units, at the communication server, based on a first set of a plurality of user-selected criteria to produce filtered data units; communicating, at the communication server, the filtered data units to the client communication unit; preparing, at the client communication unit, a second set of a plurality of user-selected criteria and, when completed, communicating the second set of the plurality of user-selected criteria to the communication server in a virtual session; filtering subsequent data units, at the communication server, based on the second set of the plurality of user-selected criteria to create subsequent filtered data units; and communicating, at the communication server, the subsequent filtered data units to the client communication unit. EXHIBIT 14 PAGE 18

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.

Why Is My Information Online?