1111111111111111 IIIIII IIIII 11111 1111111111 11111 1111111111 1111111111 11111 1111111111 11111111
`US 20020080928Al
`
`(19) United States
`(12) Patent Application Publication
`Bates et al.
`
`(10) Pub. No.: US 2002/0080928 Al
`Jun. 27, 2002
`(43) Pub. Date:
`
`(54) TELEPHONE MESSAGE SYSTEM WITH
`FLEXIBLE PRESENTATION CAPABILITY
`
`(75)
`
`Inventors: Cary Lee Bates, Rochester, MN (US);
`John Matthew Santosuosso, Rochester,
`MN (US)
`
`Correspondence Address:
`Steven W. Roth
`IBM Corporation, Dept.917
`3605 Highway 52 North
`Rochester, MN 55901-7829 (US)
`
`(73)
`
`Assignee: International Business Machines Cor(cid:173)
`poration, Armonk, NY (US)
`
`(21)
`
`Appl. No.:
`
`09/746,883
`
`(22) Filed:
`
`Dec. 22, 2000
`
`Publication Classification
`
`Int. Cl.7 ...................................................... H04M 1/64
`(51)
`(52) U.S. Cl. ..................................... 379/88.21; 379/88.25
`
`(57)
`
`ABSTRACT
`
`A telephone message system identifies a caller with an
`incoming message, and sorts messages according to caller
`identifying information for presentation to the user. Prefer(cid:173)
`ably, messages are grouped according to the caller's tele(cid:173)
`phone number, but may alternatively be grouped using voice
`recognition technology. When a user plays back a large
`number of messages, all messages from the same number or
`person will be grouped together, making it easier to follow
`a chain of messages. The user may optionally prioritize
`message groups, either explicitly of by letting the system
`assign a priority.
`
`120
`
`121
`
`I
`
`I
`
`I
`
`PHONE
`
`1/F
`
`I
`102
`
`•
`
`:>
`
`• 7
`
`101
`
`PROCESSOR
`
`,,
`"'
`
`A
`
`II' ..
`
`)
`
`..
`
`...
`
`V
`
`100
`
`103
`
`ROM
`110
`CONTROL
`PROGRAM
`
`104
`
`111
`GREETING
`113
`112 PROFILE
`
`MESSAGES
`
`I I/0
`
`lt
`1/F . ;.
`
`• 7
`106
`DISPLAY
`
`lOZ
`BUTTONS,
`ETC.
`
`~
`
`Motorola Solutions, Inc., Ex1020, p. 1
`
`

`

`Patent Application Publication
`
`Jun. 27, 2002 Sheet 1 of 8
`
`US 2002/0080928 Al
`
`100
`
`103
`
`ROM
`110
`CONTROL
`~ PROGRAM
`"
`
`..
`'
`v'
`
`104
`
`111
`GREETING
`113
`_112 PROFILE
`
`MESSAGES
`
`120
`
`I
`
`I
`
`I
`
`PHONE
`
`1/F
`
`) :
`
`I
`102'
`
`101
`
`PROCESSOR
`
`A
`
`/
`
`"
`
`~
`
`,c
`
`I/0
`
`I/F
`
`~
`
`/
`107 lb[]108
`""'
`BUTTONS.
`ETC.
`
`",7
`
`106
`DISPLAY
`
`FIG. I
`
`Motorola Solutions, Inc., Ex1020, p. 2
`
`

`

`Patent Application Publication
`
`Jun. 27, 2002 Sheet 2 of 8
`
`US 2002/0080928 Al
`
`113 t
`
`201
`
`PRIORITY
`
`PRIORITY
`
`PRIORITY
`~
`205
`
`HEADER
`I MODE 203 I
`CALLER ID
`
`CALLER ID
`
`CALLER ID
`~
`204
`
`-.. ~202
`
`FIG. 2
`
`Motorola Solutions, Inc., Ex1020, p. 3
`
`

`

`IDLE
`
`310
`
`Yes
`
`Yes
`
`No
`
`316
`Play
`Greeting
`
`Record
`Message
`
`317
`
`313
`Increment
`11i1 Priority
`
`~---
`
`No
`
`314
`Create + Initialize'--_....., _ _ _ _ __
`New Caller Entry
`
`FIG. 3A-I
`
`""C
`
`I")
`
`I")
`
`~ .... ~ = ....
`~ "Cl -....
`~ ....
`.... 0 =
`~
`O' -....
`~ ....
`.... 0 =
`~ = ?
`
`N
`~-..J
`N
`0
`0
`N
`
`'JJ. =(cid:173)~
`~ ....
`0 ....,
`00
`
`~
`
`d
`'JJ.
`N
`0
`0
`~
`0
`0
`00
`0
`\0
`N
`00
`
`>
`'"""'
`
`Motorola Solutions, Inc., Ex1020, p. 4
`
`

`

`Patent Application Publication
`
`Jun. 27, 2002 Sheet 4 of 8
`
`US 2002/0080928 Al
`
`No
`
`Yes
`
`322
`Increment
`Priority 1--•
`
`Create+ Initialize~-----~
`New Caller Entry
`
`Yes
`
`No
`
`Yes
`
`No
`
`326
`
`Age all
`Priorities
`
`FIG. 3A-2
`
`Motorola Solutions, Inc., Ex1020, p. 5
`
`

`

`Patent Application Publication
`
`Jun. 27, 2002 Sheet 5 of 8
`
`US 2002/0080928 Al
`
`331
`
`PLAY
`<FIGS. 4A+4B)
`
`333
`
`334
`
`Select
`Group
`
`Play all
`1-----messages
`this group
`
`336
`Select
`Mode
`
`337
`Save in
`1 - - - - . i Prof i I e 1 - - -. .
`
`339
`>---Perform Othert--______ _,..
`Function
`
`Yes
`
`340
`341
`342
`Select ___ Select _ _ _ Save
`Caller ID
`Priority
`Values
`
`FIG. 3B
`
`Motorola Solutions, Inc., Ex1020, p. 6
`
`

`

`Patent Application Publication
`
`Jun. 27, 2002 Sheet 6 of 8
`
`US 2002/0080928 Al
`
`PLAY
`
`Mark all
`Messages
`Unplayed
`
`401
`
`Yes
`
`404
`Select next
`Message
`
`405
`
`Play Message
`Mark
`
`No
`
`417
`Select next
`Unplayed
`Message
`
`No
`
`413
`
`414
`
`Yes
`
`412
`
`Select next
`Unplayed
`Message
`
`Crt Grp=
`CalTer ID
`
`Play Message
`Mark
`
`No
`
`416
`
`Reset Skip/
`Delete Grp
`
`Yes
`
`422
`Delete
`Message
`
`Play
`Message
`423
`
`FIG. 4A
`
`- - - - - - - - - - - - - . . . . - . , B
`
`Motorola Solutions, Inc., Ex1020, p. 7
`
`

`

`Patent Application Publication
`
`Jun. 27, 2002 Sheet 7 of 8
`
`US 2002/0080928 Al
`
`A~-------..11--------,Y
`
`No
`
`430
`
`Select next
`Unplayed
`Message
`
`Get Priority
`
`Iii Pri=Priori ty
`SeTected=Message ID
`Crt_Grp=Caller ID
`
`No
`
`Yes
`
`Select next
`Unplayed
`Message
`
`Get Priority
`
`43]
`
`432
`
`433
`
`435
`
`436
`
`No
`
`Hi Pri=Priority
`- ~ - - , SeTected=Message ID
`Crt_Grp=Caller ID
`
`438
`
`FIG. 48-1
`
`Motorola Solutions, Inc., Ex1020, p. 8
`
`

`

`Patent Application Publication
`
`Jun. 27, 2002 Sheet 8 of 8
`
`US 2002/0080928 Al
`
`i-----
`440
`
`Play Message
`Mark
`
`FIG. 48-2
`
`451
`>N_o _ _ Reset Skip
`Delete Group
`
`Yes
`
`442
`
`Select next
`Unplayed
`Message
`
`443
`
`l
`
`No
`
`No
`
`Yes
`
`Mark
`
`446
`
`444
`
`No
`
`Yes
`
`449
`
`Delete
`Message
`
`450
`
`_ _ _ Play
`Message
`
`Motorola Solutions, Inc., Ex1020, p. 9
`
`

`

`US 2002/0080928 Al
`
`Jun.27,2002
`
`1
`
`TELEPHONE MESSAGE SYSTEM WITH
`FLEXIBLE PRESENTATION CAPABILITY
`
`FIELD OF THE INVENTION
`
`[0001] The present invention relates to telephone answer(cid:173)
`ing message systems, and in particular to message systems
`of the type that include digital data processors for recording
`and playback of telephonic messages.
`
`BACKGROUND OF THE INVENTION
`
`[0002] The latter half of the twentieth century has been
`witness to a phenomenon known as the information revo(cid:173)
`lution. While the information revolution is often associated
`with general purpose digital computers, digital data process(cid:173)
`ing technology has been incorporated into an ever increasing
`variety of applications, including automobiles, home appli(cid:173)
`ances, medical devices, security devices, etc. The list is
`almost endless.
`[0003] One application for digital technology is in tele(cid:173)
`phone answering message systems. A conventional tele(cid:173)
`phone message system typically contains a telephonic inter(cid:173)
`face and a data storage for storing multiple audible
`messages. The telephonic interface listens on the telephone
`line for an incoming call. If the call is not intercepted by a
`user ( call recipient) after a predetermined time, the answer(cid:173)
`ing machine takes over the line and plays a pre-recorded
`message to the caller. The caller is then allowed to record a
`spoken message for the call recipient on the answering
`machine. Various function buttons or switches permit the
`call recipient (user) to retrieve (play back) or delete the
`message at a later time. Such a message system is often a
`self-contained device which attaches to a single telephone
`line, but it may also be a larger device such as a computer,
`which services multiple telephone lines and stores messages
`for multiple users, each of whom accesses the messages by
`using appropriate buttons on a local telephone receiver.
`[0004] Many individuals receive a large number of such
`messages on their telephone message systems. The number
`of messages to deal with can be particularly large if the user
`has been away from the system (e.g., on vacation or out of
`town on business) for any length of time. It can be incon(cid:173)
`venient for a user to wade through a large number of
`messages.
`[0005] Many answering machines offer the user the capa(cid:173)
`bility to access the machine remotely to hear messages. As
`useful as this capability is, it offers only limited alleviation
`of the problem. Remote access may be difficult or impos(cid:173)
`sible due to the user's schedule or other factors. Remote
`access may be expensive; often it will only be possible from
`a hotel room at the end of the day, where phone charges are
`very high. But even without these problems, the user must
`still listen in sequence to a lot of messages, and make mental
`connections between some messages which are out of
`sequence.
`[0006] Older self-contained answering machines were
`basically tape recorders with a few switches for telephonic
`interface. Most modem self-contained message systems use
`semiconductor memory for message storage, and have on(cid:173)
`board digital processors which may support a variety of
`functions. Such machines are, in fact, small, limited-func(cid:173)
`tion computers. Yet even modem message systems have
`
`tended to mimic the capabilities of their older, tape recorder
`based counterparts, making limited use of digital technol(cid:173)
`ogy. An unappreciated need exists to provide improved
`function in telephone message systems, and in particular, to
`enhance the capability of the user to manage multiple stored
`messages.
`
`SUMMARY OF THE INVENTION
`[0007] A telephone answering message system identifies a
`caller with an incoming message. Messages are sorted
`electronically according to caller identifying information. A
`user may listen to messages in the sorted order, rather than
`in a time sequential order.
`[0008]
`the preferred embodiment, messages are
`In
`grouped according to the caller's telephone number. I.e.,
`multiple messages from the same telephone number are
`grouped together for playback. The message system may
`optionally identify a caller using voice recognition technol(cid:173)
`ogy, or a combination of voice recognition technology and
`calling number. Thus, when a user plays back a large number
`of messages, all messages from the same telephone number
`or person will be grouped together, making it easier to
`follow a chain of messages.
`[0009] The user may optionally prioritize message group(cid:173)
`ings. Specifically, the user may define certain calling num(cid:173)
`bers or voices as having a higher priority for response.
`During playback, messages in such groupings are played
`back first, in the order of established priority. Alternatively,
`the system may automatically assign a priority based on
`frequency of calling and/or receiving calls from a particular
`number.
`[0010] A message for which no priority has been set, or
`which originates from a telephone number which has
`blocked its caller ID function, will typically be assigned a
`low priority, and will be played back last. Often, such calls
`originate from telemarketers.
`[0011] Additional features provided include the ability to
`delete an entire group of messages or a single message
`within a group, to skip over one message or an entire group
`of messages, or to select a particular ID (telephone number)
`and play all the messages associated with that number.
`[0012] A telephone answering machine as described
`herein thus provides improved capability to manage multiple
`telephone messages. The ability to prioritize messages can
`be particularly
`important when
`retrieving messages
`remotely, thus allowing the user to abort the remote call after
`listening to the most important messages, saving time and
`money for the user.
`[0013] The details of the present invention, both as to its
`structure and operation, can best be understood in reference
`to the accompanying drawings, in which like reference
`numerals refer to like parts, and in which:
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`[0014] FIG. 1 is a block diagram illustrating the major
`components of a telephone message system, according to the
`preferred embodiment of the present invention.
`[0015] FIG. 2 shows the structure of a sorting profile used
`to control sorting of message for presentation, according to
`the preferred embodiment.
`
`Motorola Solutions, Inc., Ex1020, p. 10
`
`

`

`US 2002/0080928 Al
`
`Jun.27,2002
`
`2
`
`[0016] FIGS. 3A and 3B are a flowchart showing the
`operation at a high level of the system's control program,
`according to the preferred embodiment.
`[0017] FIGS. 4A and 4B are a flowchart showing in
`greater the steps performed by the control program during
`the playback function, according to the preferred embodi(cid:173)
`ment.
`
`DETAILED DESCRIPTION OF IBE
`PREFERRED EMBODIMENT
`[0018] Referring to the drawing, wherein like numbers
`denote like parts throughout the several views, FIG. 1 is a
`high-level block diagram illustrating the major components
`of a telephone answering message system which may be
`used to support flexible message presentation, according to
`the preferred embodiment of the present invention. Message
`system 100 includes programmable processor 101, tele(cid:173)
`phone line interface 102, non-volatile semiconductor read(cid:173)
`only memory (ROM)103, read/write semiconductor random
`access memory (RAM)104, and 1/0 device interface 105.
`Processor 101 executes control program 110 stored in ROM
`103 to control the operation of message system 100. Tele(cid:173)
`phone interface 102 includes a jack for receiving an incom(cid:173)
`ing telephone line 120, a jack for an outgoing telephone line
`connected to a telephone 121, and control electronics for
`taking control of the telephone line in response to an
`incoming signal. Telephone interface further includes hard(cid:173)
`ware for converting a telephone signal to appropriate digital
`form for storage and playback on telephone system 100.
`RAM 104 is used for storing volatile data; it includes a
`greeting file 111 containing one or more pre-recorded voice
`greetings to be played over the telephone line to a caller
`when the user does not intercept the telephone call; message
`in file 112 containing voice messages left for the user by
`callers; and sorting profile 113 containing data used to sort
`messages for playback, as further described herein. 1/0
`device interface 105 provides an interface to various 1/0
`devices within message system 100. Such 1/0 devices pref(cid:173)
`erably include a display 106, such as a light emitting diode
`(LED) or liquid crystal diode (LCD) display, for displaying
`system status; a plurality of buttons and switches 107 for
`user input and selection; and a speaker 108 for audibly
`playing stored messages to the user.
`[0019] While message system 100 is shown in FIG. 1 with
`a separate external telephone 121 attached via an outgoing
`telephone port in telephone interface 102, it will be under(cid:173)
`stood that message system 100 could contain an integral
`telephone handset.
`[0020] FIG. 2 shows the structure of sorting profile 113,
`which is used to control sorting of message for presentation,
`according to the preferred embodiment. Sorting profile con(cid:173)
`tains a header 201 and a variable number of caller entries
`202. The header includes a mode field 203 which identifies
`a sorting mode for playback of messages recorded in the
`message system, and may contain additional fields such as
`profile length specifying the length of profile 113, etc. Each
`caller entry 202 contains a caller ID field 204 and a priority
`field 205.
`[0021]
`In the preferred embodiment, five operational
`modes are defined for playback of stored messages. The
`current mode is determined by the value in the mode field
`203 of sorting profile 113. The mode values and their
`meanings are as follows:
`
`[0022] Sequential: All messages are played back in
`chronological order
`
`[0023] Grouped: Messages are grouped according to
`the caller's identifier, with the group having the
`oldest message being played first.
`
`[0024] Grouped prioritized: Messages are grouped
`according to the caller's identifier, with the group
`having the highest user-assigned priority being
`played first.
`
`[0025] Grouped auto prioritized: Similar to grouped
`prioritized, but the system automatically determines
`priority, without the need for user assignment.
`
`[0026] Prioritized: Messages are played back in the
`order of user-assigned priority, without grouping by
`caller ID.
`
`[0027] Priority field 205 is preferably an integer, which
`may be assigned by the user or may be determined by the
`system. When operating in Grouped auto prioritized mode,
`the system determines a priority for messages of each caller,
`as follows. Priority field is effectively a counter, which is
`incremented and decremented. The priority is incremented
`each time a call from the corresponding caller is sensed on
`telephone line 120. The priority is further incremented each
`time an outgoing telephone call is made from the user's line
`to
`the
`telephone number of the corresponding caller.
`Although the amount of increments may be the same in the
`two cases, preferably an outgoing call results in a larger
`increment. An incoming call indicates that the caller desires
`to talk to the user, but the reverse is not definitely indicated,
`whereas an outgoing call indicates definite interest on the
`part of the user, and is therefore a surer indication of higher
`priority. In order to age the priority numbers, the system
`periodically reduces all priorities by a pre-determined
`amount. While different formulae can be used, in an example
`embodiment the system increments priority by 1 for each
`incoming call, increments priority by 5 for each outgoing
`call, and divides all priorities in half every month to age the
`priority information. If the division results in a priority of
`less than 1, the corresponding caller entry 202 is deleted
`from profile 113, so that caller entries do not accumulate
`indefinitely. Messages from unidentified callers (i.e., those
`who have blocked the caller ID function on their telephones,
`so that a called party can not identify the source of the call)
`are assigned a priority of 0. It will be understood that there
`are many possible variations in the way in which a system
`may automatically assign priority to messages. Specifically,
`the system may take into account other or additional factors
`than the frequency of calling or receiving calls from a
`particular number. E.g., the system may take into account
`the lengths of messages.
`[0028]
`In the preferred embodiment, caller ID field 205 in
`each caller entry 202 contains the telephone number of the
`caller. This number is obtained from a caller ID signal
`received over telephone line 120. However, caller ID field
`205 could alternatively contain any data which would be
`used to identify a source of a message. For example, it would
`alternatively be possible to identify the caller using voice
`recognition techniques. In this case, a caller ID field could
`contain a voice sample, or some data abstracted from a voice
`sample from which it would be possible to identify the
`caller. Caller identification using voice recognition has the
`
`Motorola Solutions, Inc., Ex1020, p. 11
`
`

`

`US 2002/0080928 Al
`
`Jun.27,2002
`
`3
`
`advantage of identifying a caller personally, regardless of
`where the call originated. It will be appreciated that, since
`the present invention involves sorting of messages for
`presentation, an acceptable message system could tolerate
`some inaccuracy in caller identification using voice recog(cid:173)
`nition techniques.
`
`and the priority values are aged, which may also require than
`some caller entries be deleted if the associated priority
`values drop below some predetermined threshold (step 326).
`As explained above, in the preferred embodiment they may
`be aged by dividing each value by 2, although other forms
`of aging are possible. The program then returns to idle.
`
`[0029]
`In the preferred embodiment, one of the caller
`entries 202 in sorting profile 113 is used for unidentified
`callers, i.e., callers who have blocked the caller ID function.
`By default, the priority of this entry is 0, but it may be
`assigned a different priority by the user.
`[0030] FIGS. 3A and 3B are a flowchart showing the
`operation at a high level of control program 110 of messag(cid:173)
`ing system 100, according to the preferred embodiment. The
`system is initially in an idle state 301. In the idle state, the
`control program waits for an indication of an incoming call,
`an outgoing call, a function selection by the user, or a
`timeout of a priority aging timer. This idle loop is repre(cid:173)
`sented as steps 302-305, and when any of the above events
`occurs, the control program leaves the idle loop to perform
`some action.
`[0031] As shown in FIG. 3A, if an incoming call is
`detected on telephone line 120 (the "Y" branch from step
`302), the control program checks the mode setting in mode
`field 203. If mode is set to anything other than "Grouped
`Auto Prioritize", the "N" branch is taken from step 310. If
`the mode is set to "Grouped Auto Prioritize", the system is
`responsible for automatically assigning priorities to caller
`messages, and the "Y" branch is taken from step 310. The
`control program then determines whether it is possible to
`identify the caller using the caller ID function (step 311). If
`so, the program checks sorting profile 113 for the existence
`of a corresponding caller entry (step 312). If the caller entry
`exists, the priority of the entry is incremented (step 313); if
`the caller entry does not exist, a new caller entry is created
`and initialized with the caller ID and an initial priority value
`(step 314). In any of the above cases, the messaging system
`then waits for the user to take the call. If the user takes the
`call within some pre-determined time period (the "Y"
`branch from step 315), the program returns to idle. If the
`user does not take the call, the system plays a pre-recorded
`greeting from greeting file 111 (step 316), and then records
`a message from the caller in message file 112 (step 317). The
`program then returns to idle.
`
`If an outgoing call is detected (the "Y" branch from
`[0032]
`step 303), the control program checks the mode setting in
`mode field 203 (step 320). If the mode is anything other than
`"Grouped Auto Prioritize", the "N" branch is taken from
`step 320, and the program returns to idle. If the mode is set
`to "Grouped Auto Prioritize, the program checks sorting file
`113 for the existence of a caller entry corresponding to the
`destination telephone number of the outgoing call (step
`321). If such an entry exists, the priority value is incre(cid:173)
`mented (step 322); if not, a new entry is created for the
`number of the outgoing call, and its priority set to an initial
`value (step 323). In either case, the program then returns to
`idle.
`
`[0033]
`If a timeout of the priority aging timer is detected
`(the "Y" branch from step 304), then the program checks the
`mode. If the mode is "Grouped Auto Prioritize", then the
`system is maintaining priority values, and it is time to age
`them. In this case, the "Y" branch is taken from step 325,
`
`[0034]
`If the user has selected some function ( e.g., through
`a combination of one or more buttons and switches 107), the
`"Y" branch from step 305 is taken. The handling of four
`specific functions is illustrated in FIG. 3B, it being under(cid:173)
`stood that the system may support many others. If the
`function is to play all messages, the "Y" branch from step
`330 is taken. In this case, the control program prioritizes the
`order of messages for presentation to the user and plays the
`messages over speaker 108 in the determined order. This
`operation is represented at a high level as step 331 in FIG.
`3B, and is shown in greater detail in FIGS. 4Aand 4B. After
`playing all messages, the control program returns to idle.
`
`[0035] The user may elect to play only a single group of
`messages, i.e., messages originating from a single telephone
`number. If this option is selected by the user, the "Y" branch
`from step 332 is taken. The user then selects a group of
`messages to be played (step 333). Since a group is defined
`by a telephone number, the user may select a group by
`entering the telephone number of interest, using some com(cid:173)
`bination of buttons and switches 107. Alternatively, the
`system can scroll through all groups for which there is at
`least one message, displaying the telephone number of each
`in display 106. Once the user has selected a group, the
`system plays all messages in the group in chronological
`order (step 334), and then returns to idle.
`
`[0036] The user may elect to change the ordering mode for
`playing messages, as illustrated by the "Y" branch from step
`335. In this case, the user selects one of the modes above
`described. Selection may be accomplished by any of various
`means, e.g., the system cycles the various options and
`displays each on display 106, allowing the user to select one
`using an appropriate button. Once a mode has been selected,
`the new value is stored in mode field 203 of profile 113 (step
`337). The control program then returns to idle.
`
`[0037] The user may elect to change some caller entry in
`profile 113, which is illustrated as the "Y" branch from step
`338. In this case, the user first selects a group or telephone
`number (step 340) using any appropriate means, such as the
`means described above with respect to step 333. The user
`then inputs an integer priority value (step 341). The control
`program saves the priority value in the corresponding caller
`entry of profile 112 (step 342). If no such caller entry exists,
`the program creates one. The program then returns to idle.
`
`[0038] The exact form of input and user selection will vary
`depending on available hardware and other design consid(cid:173)
`erations, but it is well known that there are many possible
`ways to input simple numeric values and make selections
`from a relatively small number of choices. Where the
`message system is equipped with a numeric keypad (which
`would, of course, be the case if it contains an integral
`telephone handset), the simplest form of numeric input is to
`use the keypad. In other cases, an arrow button and a select
`button can be used to scroll through a sequence of choices
`or digits. While this mode of data entry is relatively slow, it
`is expected that a user will only rarely change the profile or
`the mode.
`
`Motorola Solutions, Inc., Ex1020, p. 12
`
`

`

`US 2002/0080928 Al
`
`Jun.27,2002
`
`4
`
`[0039] FIGS. 4A and 4B are a flowchart showing in
`greater the steps performed by the control program during
`the playback function, i.e., the playing of messages to the
`user, which is represented in FIG. 3B as the single block
`331. In the description below, it is assumed that stored
`messages have a header containing a pointer to the next
`sequential ( chronological) message, a marker flag indicating
`whether the message has been played, a caller ID, and other
`data. Referring first to FIG. 4A, upon entering the playback
`function all stored messages are marked as unplayed (step
`401). The mode field 203 is then examined. If the mode is
`sequential ("Y" branch from step 402), the control program
`looks for another unplayed message (step 403), selects the
`next unplayed message in sequential (chronological) order
`(step 404), and plays the message, marking it as played (step
`405). It then returns to step 403, and when no more unplayed
`messages remain, it exits the playback function.
`
`[0040] During playing of a message, the user may inter(cid:173)
`rupt play to either skip or delete the message. This interrupt
`capability is shown as an "I" inside a box, pointing to the
`various play steps. In the case of sequential mode, only a
`specific message is skipped or deleted. However, in the case
`of the other modes, the user may elect to skip all messages
`remaining in a group, or to delete all messages remaining in
`a group. In this case, a group skip or group delete flag is set.
`
`If the mode is Grouped unprioritized, the "Y"
`[0041]
`branch from step 410 is taken. In this case, the control
`program starts at the beginning of the sequential list of
`messages, and determines if any unplayed messages remain
`(step 411). If so, the next sequential unplayed message is
`selected (step 412), and the current group variable (Crt_ Grp)
`is set to the value of the caller ID of the selected message
`(step 413). The selected message is then played and marked
`(step 414). Beginning at the selected message, the program
`then parses the remaining messages in sequence. If there are
`any remaining unplayed messages (the "Y" branch from step
`415), the next sequential unplayed message is selected (step
`417). The caller ID of the selected message is then compared
`with the Crt_ Grp variable (step 418). If the two are not
`equal, the message is not in the same group, and the "N"
`branch is taken from step 418 to go on to the next message
`at step 415. If the "Y" branch is taken from step 418, the
`selected message is marked (step 419). The program then
`checks the status of the group skip flag, indicating whether
`an entire group of messages should be skipped (step 420). If
`the group skip is set, the "Y" branch is taken from step 420,
`causing the program to skip the selected message and go to
`step 415 to process the next message. If the group skip is not
`set, the program checks the group delete flag (step 421). If
`the group delete is set, the "Y" branch is taken from step
`421, causing the selected message to be deleted (step 422),
`after which the program goes to step 415 to process the next
`message. If the group delete is not set, the selected message
`is played (step 423), and the program then goes to step 415
`to process the next message. When the end of the message
`sequence has been reached, the "N" branch is taken from
`step 415. The group skip and group delete flags are then
`reset, and the program returns to the top of the message
`sequence at step 411, to determine the next unplayed mes(cid:173)
`sage. When no more unplayed messages remain, the "N"
`branch is taken from step 411, and the playback function
`terminates.
`
`[0042]
`If the mode is neither sequential nor grouped
`unprioritized, then the "N" branch is taken from step 410. In
`this case the mode is either grouped prioritized, grouped
`auto prioritized, or prioritized. The step followed by the
`control program are similar, and are illustrated in FIG. 4B.
`
`[0043] The program first finds the unplayed message hav(cid:173)
`ing the highest priority (steps 430-438), this being used to
`define a set of messages to be played together. Beginning at
`the start of the message sequence, the program determines
`whether any unplayed messages remain (step 430). If so, the
`"Y" branch is taken, and the next unplayed message is
`selected (step 431). The priority of this message is then
`determined. by comparing the caller ID of the message with
`the caller ID fields of the caller entries in profile 113 (step
`432). The variable Hi_Pri is then set to the priority value, the
`Crt_ Grp set to the caller ID value, and a selected variable is
`set to an identifier of the selected message, which may, e.g.
`be an address (step 433). The program then determines
`whether any unplayed message remain in the sequence (step
`434). If so, the "Y" branch is taken from step 434, and the
`next unplayed message is selected (step 435). The priority of
`this message is obtain as it was in step 432 (step 436). This
`priority is then compared with the Hi_Pri value (step 437).
`If the priority of the current message is less than or equal to
`Hi_Pri, the program goes to step 434 to process the next
`message. If not, the "Y" branch from step 437 is taken, and
`Hi_Pri is set to the priority of the current message, and the
`selected and Crt_ Grp are updated accordingly (step 438),
`after which the program goes to step 434 to process the next
`message. When the entire sequence of messages has been
`parsed, the "N" branch is taken from step 434; at this point,
`the Hi_Pri variable contains the highest priority encoun(cid:173)
`tered, the selected contains the message ID of the first
`message having this priority, and Crt_ Grp contains the caller
`ID associated with that message.
`
`[0044] The program then plays the selected message and
`marks it played (step 440). Beginning with the just played
`message, the program again parses the message sequence for
`unplayed messages. If any unplayed messages remain, the
`"Y" branch is taken from step 441. The next unplayed
`message is then selected (step 442). If the mode is "priori(cid:173)
`tized", then the "Y" branch is taken from step 443, and the
`program compares the priority of the just selected message
`to Hi_Pri (step 444). If the priorities are unequal, the
`program goes to step 441 to process the next message (the
`"N" branch from step 444). If the priorities are equal, the
`mode setting requires that this message be played with all
`others of the same priority, and the program continues to
`step 446. If, on the other hand, at step 443, the mode is either
`"grouped prioritized" or "grouped auto prioritized", the "N"
`branch is taken from step 443, and the program compares the
`caller ID of the just selected message to the Crt_ Grp variabl