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)

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