[19]
`United States Patent
`[11] Patent Number:
`4,837,798
`Cohen et a1.
`[45] Date of Patent:
`Jun. 6, 1989
`
`[54] COMIMUNICATION SYSTEM HAVING
`UNIFIED MESSAGING
`
`[75]
`
`Inventors: Roberta S. Cohen; Kenneth M.
`Huber, both-of Middletown; Deborah
`J. Mills, Eatontown, all of N.J.;
`Myron E. Drape], Lafayette, Col.;
`Jam's R. Asterwesl, Corona Del.
`Mar, Calif.
`
`[73] Assignees: American Telephone and Telegraph
`Company, New York, N.Y.; AT&T
`Information Systems Inc.,
`Morristown, NJ.
`App1.No.: 869,277
`
`1211
`1221
`
`Filed:
`
`Jun. 2, 1986
`
`[511
`
`1521
`
`[581
`
`[56]
`
`Int. Cl.4 ....................... H04M 1/00; H04M 3/50;
`HO4M 11/00
`US. Cl. . ....................................... 379/88; 379/94;
`379/396
`Field of Search ............... 370/62, 60, 58; 379/88,
`379/89, 94, 100, 67, 396
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`9/1986 Emerson et a1.
`4,612,416
`4,646,346 2/1987 Emerson et a1.
`
`...................... 379/88
`379/214
`
`FOREIGN PATENT DOCUMENTS
`
`9/1983 Japan ..................................... 379/89
`0157247
`0169262 9/ 1984 Japan ................................... 379/ 100
`
`0214365 12/1984 Japan ..................................... 379/88
`
`,
`r: .
`M 92132911311234 @2119;
`0248057 12/1985 Japan ................................... 379/100
`OTHER PUBLICATIONS
`
`21].,
`“Electronic Switching Systems”, R. Sugioka et
`Fujitsu Scientific & Technical Journal (Japan), vol. 21,
`No. 3, Jul. 1985, pp. 225—258.
`“A Voice Mail System and Service Environment”, K.
`Sakiya et al., Globecom 85, IEEE Globe] Telecommu-
`nications Conf., Dec. 1985 (New Orleans, U.S.), Conf.
`Rec. vol. 1, pp. 43.1—43.6.
`.“ISDN in the Office-HICOM” (Siemens), Special Is-
`sue,
`telcom report and Siemens Magazine COM, Dec.
`1985, pp. 1—111.
`Primary Examiner—Thomas W. Brown
`Attorney, Agent, or Firm—David H. Tannenbaum;
`David R. Padnes
`
`[57]
`
`ABSTRACT
`
`Unified messaging is a concept that provides for a single
`electronic mailbox for different types of messages. The
`mailbox can be on a user’s host computer, PBX, PC,
`etc., and the user has consistant facilities available to
`originate, receive and manipulate messages. Messages
`can be translated from one media to another for recep-
`tion, and a single message may be composed of parts
`that use different native media. The message recipient
`has a single controllable point of contact where all
`messages can be scanned and/or viewed.
`
`34 Claims, 14 Drawing Sheets
`
`(9i
`
`10?
`
`
`
`, I
`
`)"
`
`%§
`
`Elm
`1:}
`
`‘ _ J
`
`UNIFIED
`
`"21:11:10
`(U115)
`
`.113
`
`»2
`
`,.
`TTS
`
`lil’
`
`109
`
`110
`
`111
`
`106 g
`
`CENIER
`112
`
`Page 1 of 23
`
`AT&T EXHIBIT 1005
`
`Page 1 of 23
`
`AT&T EXHIBIT 1005
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 1 of 14
`
`4,837,798
`
`r:<ZmeZHwZ
`
`
`
`
`1:a\s<E‘._ill-1»Vmo__556:2d4:
`
`
`_:a:02IQ«WI
`
`Exam:329:8:88>._M—Ifls
`
`
`
`UHZOMHUMIE|_<QOI_
`
`<mm<
`
`N:
`
`no—
`
`we”,
`
`a» a
`
`Cl
`0—0
`
`.1.
`
`m:
`
`x
`<[
`LI.
`
`u.)
`was<
`m"
`m2
`mm
`:0
`
`szsv
`
`ozzmowmmmwzEN_\5&erm3.
`mHHbmwwmw
`
`
`
`SH52:WWxflwm_&fl
`
`
`
`9_1E
`
`Page 2 of 23
`
`Page 2 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 2 of 14
`
`4,837,798
`
`FIG. 2
`
`MESSAGE RETRIEVAL VOICE STATION
`
`DELETE
`DEF
`
`FIRST
`
`{—
`
`
`
`1
`
`HELP
`CHI
`4
`
`RESTART
`.U
`[__EJ
`\Jm
`
`7F
`
`
`
`20
`
`BACKUP
`ABC
`2
`
`REPEAT
`JKL
`5
`RETURN
`CALL
`
`
`
`/// 20
`
`
`
`L3—
`
`SAVE
`MNO
`
`_Ji_
`
`NEXT
`
`
`V:2OX}:'<—0
`
`MESSAGE LAMP
`
`ENTER AS * (COMMAND)
`
`Page 3 of 23
`
`Page 3 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 3 of 14
`
`4,837,798
`
`I’IG. 3
`
`USER
`INTERFACE
`LAYER
`
`
`
`USER
`
`USER INTERFACE
`
`301
`
`
`
`.
`
`USER
`APPLICATIONS
`
`' "
`
`
`
`
`302N
`
`I
`
`APPLICATION LAYER SERVICES
`
`CONTENT DESCRIPTION ARCHITECTURE
`(FIG. 3)
`
`SO
`
`MESSAGE SERVICE ARCHITECTURE
`(FIG. 4)
`
`40
`
`/
`
`r——_—_-———__
`PRESENTATION LAYER SERVICES .
`
`303
`
`SOS-IO
`
`
`
`
`CODING
`AND
`
`303-20
`
`ENCRYPTION
`CODING
`AND
`CONVERSION
`
` DOCUMENT
`CONVERSION
`
`VOICE
`CODING
`AND
`
`CONVERSION
`
`.
`
`{
`
`Page 4 of 23
`
`Page 4 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 4 0f 14
`
`4,837,798
`
`FIG. 4
`
`MESSAGE SERTICE ARCHITECTURE
`404
`_.“__ _L_-
`NOTIFICATION
`---
`
`______#é:_
`
`M IL
`{
`
`A MESSAGE
`
`PROTOCOL
`
`-
`
`--.
`
`---
`
`MESSAGE
`PRCT
`STA
`
`40
`
`
`
`
`
`MESSAGE
`fifiggfifigg
`STATUS
`_ AOT
`
`l
`,
`
`
`
`
`‘
`
`:ERQMr
`MESSAGE
`
`
`0-
`REPORT
`HEADER
`
`.
`:
`
`MESSAGE TRANSPORT HEADER
`
`________________________________________________________
`
`FIG. 5
`CONTENT DESCRIPTION ARCHITECTURE
`CONTENT
`CONTENT
`CONTENT
`NORD
`VOICE
`TEXT
`PROCESSOR
`
`5O2
`.
`rSTANO'A‘RO' “““““ ‘1
`;REPRESENTATIONS
`:
`}
`CONTENT
`CONTENT’
`1
`I PROTOCOL -- PROTOCOLT;
`L_
`FAX
`VOICE ‘J
`
`SOO
`
`.--
`
`
`
`
`
`
`
`
`
`
`CONTENT EXCHANGE
`COMPOUND
`CONTENT
`- PROTOCOL
`
`CONTENT
`PROTOCOL ~
`OBJECT
`
`,SO
`
`'
`
`503
`
`T
`
`~-
`
`
`
`SOT
`
`UNIVERSAL
`CONTENT TYPE: TEXT
`CONTENT DESCRIPTION
`-
`
`
`HEADER (UCDH)
`’
`
`
`
`.
`
`
`
`Page 5 of 23
`
`Page 5 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 5 of 14
`
`4,837,798
`
`¢z<4
`
`\xma
`
`monb<QHLHhozmo
`
`N_
`
`
`
`HXMFoofi
`
`‘
`
`~00
`
`
`
`\mmmo<m:mz~gz<um
`
`HIQHJ.¢ IQHHzm
`
`moo
`
`muHo>
`
`Jqu
`
`
`
`ommqmIUHHzm
`
`HXMH
`
`4H<z
`
`mzog<uoz<Hm
`
`
`4H<z«aUHzoabom4m
`o4H4:quoaHUM4m
`
`
`
`
`
`
`.zu~m>mozHHmmgqzu~m>mozH>HmommEmpm>wozHDzmm
`
`
`
`
`
`
`
`
`
`
`
`HzmHmHumm4H<zbXMHQmm<mIUPHzm
`
`
`
`
`
`
`
`monp<monLzoooz~o<mmmz
`
`o.3...
`
`Page 6 of 23
`
`Page 6 of 23
`
`
`
`
`
`

`

`US. Patent
`
`Jun.6,1989
`
`Sheet 6 0f 14
`
`4,837,798
`
`\xmm
`
`Iuszm
`
`moo
`
`cm42:
`
`meh
`
`moo
`
`moHo>
`
`4H<z
`
`
`
`Qmm<mIUFHzm
`
`m2©4<loz<km
`
`
`
`qoogupq4mz<apPXMP/V
`
`PXMHmeH
`
`
`
`4H<zonkquHLHpoz
`
`\moHo>OF
`
`_©o
`
`
`
`
`
`az<4PIQHJFKJqumoHo>
`
`mop
`
`o__
`
`
`
`
`
`zu~m>mOszmm4<zmhm>mozH>Hmummzu»m>mozHszw
`
`
`
`
`
`
`
`
`
`
`
`HzmHmflumm4H<zmoHo>omm<mIuHHzm
`
`
`
`
`
`
`
`
`
`monzmjoEzouozHo<wwmzm..DHh—
`
`Page 7 of 23
`
`Page 7 of 23
`
`
`
`
`
`
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 7 of 14
`
`4,837,798
`
`
`
`
`
`
`
`
`
`
`
`
`
`ZMHm>mozHHmm4<zu~m>mozH>HmummZMHm>mozHozmm
`
`_so
`
`
`N_muHo>
`
`»_a<2aSAMHloo—
`
`IUFHzm
`
`QmHmHz:
`
`oz~o<mmmz
`
`zu~m>m
`
`m2:
`
`
`
`FIQHJ4H<z
`
`
`
`Qmm<mIUHHzm
`
`HXMh
`
`n.2,:WIDE4/
`
`quomHumgm
`
`4H<z
`
`
`
`
`
`mzeéiazfim\4::328:8:
`
`
`HzmHmHumm4H<zm:MHz04<Q2<Hm
`
`monH<usonzzoxuozHo<mmmz
`
`w.0:
`
`Page 8 of 23
`
`Page 8 of 23
`
`
`
`
`
`

`

`
`
`
`
`
`
`zapm>mozHHQMJ<gubm>mDZH>Hmumm
`
`J:5
`6,:3.mN_uoHo>
`
`1bag
`
`
`
`9\mmIprzmo4H4:muflo>
`
`HXMP
`
`4H<z
`
`mew/3
`
`
`
`
`
`_ILH4omm<mIQHHzm
`
`00aehcu
`
`41
`
`JmQuHLHza
`
`
`
`ozHo<mmmzL\\\\\\\
`
`
`
`Zm‘rm‘rm$24HIQHJMUHO>O._.53%
`
`CAB\zofijmzqwfi
`
`4,837,798
`
`
`
`‘4H<zHXMH
`
`u204<xaz<Hm
`
`onH<oHLHHoz
`
`V
`
`flmmmwwxmmmmzmm
`
`S
`
`tnuma
`
`
`up;monh<monmzouozfio<mmmz
`
`
`
`oaHzmHmHomm4H4:muHo>m204<-oz<km
`
`o.“UHL
`
`Page 9 of 23
`
`Page 9 of 23
`
`
`
`

`

`§§EQMT
`DATEl
`
`I
`
`‘
`
`
`
`
`
`TD:
`EEEJECT'
`
`CONTENT
`TYPE:
`CONTENT
`LENGTH:
`[MSG]
`
`CONSTRUCT MTA
`UNIVERSAL
`HEADER (ENVELUP)
`10T2
`
`//
`SERVICE (MAIL)
`
`1013
`CONTENT
`
`E_‘__—'_—‘__‘_—‘___
`UNIVERAL HEADER
`
`
`SERVICE: MAIL
`
`
`CONTENT HEADERm
`
`[MSG]
`
`
`OBJECT DESCRIPTION”1015
`
`DOCUMENT
`
`US. Patent
`
`Jun. 6, 1989
`
`Sheet 9 of 14
`
`4,837,798
`
`-—FIG.
`
`ID
`
`
`MESSAGE CREATION
`
`"USER ACTIONS"
`
`CREATE
`MAIL
`
`100’
`
`"SYSTEM ACTIONS"
`
`[ENTER RECIPIENT eg.
`'TDM.SMITH”]
`
`TDID
`
`MAPPING TO MACHINE
`ADDR TUM.SMITH
`MACHINE! TSMITH
`DEVICE LINE 1 ,
`XXX—5755
`
`/
`
`TCII
`
`;
`
`
`
`
`
`
`T0=
`
`T002
`
`1003
`
`SUBJECT:
`
`[ENTER TEXT]
`
`
`
`[ENTER MSG]
`
`ATTACH
`DOCUMENT
`
`DELIVERY
`
`1004
`
`1005
`
`YES
`
`1006
`
`FILE NAME:
`
`{008
`
`1009
`
`
`
` DEFERRED
`
`
`
`
`Page 10 of 23
`
`Page 10 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 10 of 14
`
`4,837,798
`
`I]
`
`FIG.
`TELEPHONE
`<VOICE MAIL OR
`TEXT SYNTHESIS)
`
`
`
`RETRIEVE A MESSAGE
`
`DISPLAY
`
`TERMINAL OR PC
`
`.
`
`C 101
`
`1
`
`20
`
`0
`11
`DIAL SERVICE
`4
`ACCESS SERVICE
`ACCESS P
`
`I 1
`102
`i
`/1
`1
`10;;
`ME IN
`ENTER LOGIN/
`LOOIN
`PASSWORD
`
`
`
`
`
`
`
`
`1122
`
`
`
`
`
`
`
`
`-
`
`
`
`103
`
`104
`
`PASSNORD
`
`SEE SCANLINE
`151 M50
`
`I
`ENTER MAIL SOC
`[:::
`SEE SCREEN 0F
`SCANLING #
`
`23
`
`HEAR FIRST :Z lamMSG i
`
`SCANLINE *
`
`I
`ME IN
`PASSNORD
`WELCOME MSG
`1
`g 105
`24
`
`READ MSG OR CD To
`106
`NEXT M88
`1
`;
`25
`DELETE. OPEN. NEXT
`:::::::::1:
`1
`‘5
`L
`READ IT #
`107
`AEAENEHET Mggg 1M
`1:
`AT END OF M503
`HAS M368 IN
`1EVBENSEAP§ROPR§ATE
`HEAR THAT USER
`OTHER SERVICES
`PROCESS TO HANDLE
`HAS MSCS IN
`CONTENTS
`SERVICES I
`SAVE MSC
`DELETE MSC
`REPLV MSC
`FND M50
`CREATE MSG
`‘—-—————-
`1
`
`1105
`
`.1:
`END OF RETRIEVAL SESSION. SVSTEM TELLS
`UMMCR TO EXTINCUISH THE LICHT.
`
`' n
`
`1120
`
`
`FROM
`PDSTMARK
`LENCTH
`TYPE
`SUBJECT
`D, MILLS
`APR 4 10:05
`256
`TEXT
`UMS SCENARIOS
`K. HUBER
`APR 5 15:07
`12312
`TEXT
`PATENT APPLICATION
`A. HUFFMAN
`APR 5 12:10
`1059
`BINARY BUSINESS CASE
`
`Page 11 of 23
`
`Page 11 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 11 0114
`
`4,837,798
`
`12O1
`
`‘202
`
`‘203
`
`VOICE SERVICE
`, SENOER
`
`CREATE MSG
`(FIG.
`1O)
`
`AOORESS MSC—
`(PHONE a)
`
`
`
`1204
`
`ATTACH OBJECT
`
`1205
`
`1206
`
`CREATE
`ENVELOPE
`
`CREATE MSG
`
`FIB'
`
`12
`
`TEXT SERVICE
`SENOER
`
`1‘23
`
`122‘
`
`1222
`
`CREATE MSO
`(FIG.
`10)
`
`CREATE MSC
`(PHONE a)
`
`
`
`ATTACH OBJECT
`
`‘223
`
`CREATE
`ENVELOPE
`
`/1224
`
`CREATE MSC
`
`1225
`
`1225
`
`1227
`~
`
`1207
`
`CREATE CONTENT
`
`CREATE CONTENT
`
`‘205
`
`SEEBIE?EN10
`SYSTEM
`
`A
`SENO MOO TO
`RECIPIENT
`SYSTEM
`
` (1)
`
`SENDS
`SCANLINE
`
`SENDS
`MESSAGE
`
`12OP
`
`RECEIVINC SYSTEM (VOICE ONLY}
`
`121O
`
`“1 RECEIVES NEH MAIL
`
`1211\\
`
`
`
`‘
`1
`1311119113
`SERVICE
`
`N0
`
`1217
`FORNAROS M80
`
`
`
`1213
`
`1214
`
`1215
`
`
`
` 1216
`
`1212
`| TURN ON ONE
`
`
`
`
`
`M56 TRANSMITTED TO UMNCR
`
`CALLS UMM PROCESSOR AND
`TRANSMITS MSG
`
`PLACES MSG IN USER'S MBOX
`
`USER RETRIEVES AND HEARS
`VOICE MAIL
`
`
`
`
`
`
`Page 12 of 23
`
`Page 12 of 23
`
`

`

`
`
`
`
`‘306 \
`
`CREATE NSC
`
`1307‘1 CREATE CONTENT
`
`1308
`
`1309
`
`SEND MSG TO
`RECIPIENT
`VOICE MAILBDX
`
`SEND
`NOTIFICATION
`0
`NEW MAIL
`
`
`
`US. Patent
`
`Jun. 6, 1989
`
`Sheet 12 of 14
`
`4,837,798
`
`___.__________1
`1301\\ VOICE SERVICE
`SENOER
`
`FIG'
`
`13
`
`
`
`1502“
`
`CREATE NSC
`
`1503\‘
`ADDRESS NSC
`(PHONE a)
`
`ATTACH OBJECT
`
`
`
`
`130“
`
`‘305
`
`CREATE
`ENVELOPE
`
`_______________
`TEXT SERVICE V/ISZD
`
`SENOER
`
`
`
`CREATE NSC
`
`CREATE MSC
`(PHONE :)
`
`f’132:
`
`1322
`
`ATTACH OBJECT v/‘1325
`
`CREATE
`ENVELOPE
`
`CREATE NSC
`
`1524
`
`,//1325
`
`CREATE CONTENT V/4326
`
`SEND MS; :0
`REQ;PI:N1
`PASTE“
`
`13¢7
`
`///
`
`
`
`MESSAGE
`
`/131U
`RECEIVINC SYSTEM (TEXT ONLY)
`
`13“
`
`RECEIVES NEN HAIL
`
`NO
`
`1313
`
`TURN ON NNL
`
`1332
`
`
`
`PORNAROINC
`
`TO ANOTHER
`SERVICE
`
`
`
`YES
`
`MSG TRANSMITTED TO UMMCR
`
`CALLS UMM PROCESSOR AND
`TRANSMITS MSG
`
`PLACES MSG IN USER'S MBOX
`
`USERS RETRIEVES AND
`HEARS VOICE MSC
`
`1314
`
`1315
`
`1316
`
`1317
`
`1315
`
`EORNAROS NSC
`
`END
`
`Page 13 of 23
`
`Page 13 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 13 of 14
`
`4,837,798
`
`V401
`
`VOICE SERVICE
`SENOER
`
`FIG'
`
`‘4
`
`TEXT SERVICE
`SENOER
`
`1420
`
`‘402
`
`1403
`
`CREATE NSC
`
`ADDRESS MSG
`(PHONE a)
`
`CREATE NSC
`
`CREATE NSC
`(PHONE :1)
`
`'404
`
`ATTACH OBJECT
`
`ATTACH OBJECT /"423
`
`142‘
`
`1‘22
`
`1424
`
`‘425
`
`1426
`
`1427
`
`CREATE CONTENT // 1408
`
`‘405
`
`CREATE
`ENVELOPE
`
`‘406
`
`CREATE NSC
`
`T407
`
`CREATE CONTENT
`
`SEND MSC To
`RECIPIENT
`SYSTEM
`
`CREATE
`ENVELOPE
`
`CREATE NSC
`
`SEND MSG T0
`RECIPIENT
`SYDTEM
`
`1428
`
`SENDS
`MESSAGE
`
`1409
`
`\ R
`
`ECEIVING SYSTEM (VOICE TEXT INTEGRATED)
`
`‘415
`EORNAROS NSC
`
`ENO
`
`1‘10
`
`RECEIVES NEN NAIL
`T4”
`
`.
`1‘12
`TURN ON MNL
`
`\\
`
`
`TEACHER
`SERVICE
`
`
`NSC TRANSNITTEO T0 UNNCR
`
`CALLS UNN PROCESSOR AND
`TRANSNITS NSC
`
`.
`-
`PLACES NSC IN USER S MBOX
`
`USER ENTERS MBOX
`READS TEXT
`HEARS VOICE
`
`T413
`
`1474
`
`1415
`
`1416
`
`SVSTEN TELLS UNN TO
`TURN OFF LIGHT
`
`‘417
`
`
`
`Page 14 of 23
`
`Page 14 of 23
`
`

`

`US. Patent
`
`Jun. 6, 1989
`
`Sheet 14 of 14
`
`4,837,798
`
`mum:uzpmegQZHHH<2mmcqmmmz2mzm><ImmuH>mmmquznom3p<~mMI»mHmam:.m.mvuwzouwmmHmozq20Hp<uHLHHOZIm<
`
`
`
`
`
`
`
`
`“Ame2HQmQH>ommmHumzommmmvmuo<mmmzmHJmzszDz<MQHD>2mznomozmmMmmmomhmuncmmmDH<bmlo<
`
`
`
`
`
`
`
`“awhzmmmo<mmmz2H><hmAmmHJmzzmmvmmo<mmmzawhzmomo<mmuz44<OmquoqumoLoHD<mmozmzhlq<
`
`
`
`
`
`u“mm.mugqcm_zouQZHHuu4<mIH20mmHmmncmmFHQ3<2<ohmmzomwwmanl
`
`
`
`
`
`
`
`
`
`“muH>mmm4H<zOF00AmaHAmzszvmmu<mmmzmmkzmumo<mmmz44<omquom<zuomO~3<zoZMDHLm<
`
`
`
`
`
`uuu_>umw4H<zquHCHZuhw>m02Ho<mmmzQMHLHZD20mmmmo<mmmz
`
`
`
`
`
`
`
`w82.9»mHmmzommumvxom4H<zHXMHmopmunommhHQD<I_m
`
`
`
`
`
`aom:
`
`
`
`
`
`
`
`un_mohmmzommmmzHVmuzoH<mumms4<mm>mmmomumzommmmFHQD<:D_<
`
`
`
`
`
`“A_mOHmmzommmmzHVmum:mzomomumzommmmhHosqxo<
`
`
`
`umuzoH<mumms4<mu>mmmommmoxzoothmu4<2m3h|®<
`
`
`
`
`
`
`
`"quHmHuumawhzmouo<mmmzmom4H<zFXMHI__<
`
`
`
`
`
`
`
`“ozHQm<szLLOm2p<pm>mm3cum_<
`
`
`
`.>m<mmthHmom3F<~m>mmzaum_<
`
`
`
`
`
`“Mum:mzomomunexzoothmM4<2m3h|n<
`
`
`
`“mum>mmmAquohmmbzmumu<mmmz20mmmmo<wmmzpzmmmao44<om<2aomohhmchme—<
`
`u>m<mmzHHHmh<ombnm<
`
`
`
`
`
`
`
`mu_>mmmHXMFmo
`
`
`
`
`
`
`Ommmmuommmom:oszmm><uomzHmum:zquUI
`
`
`
`
`mommzAymuscvFHQD<IMQQ<xomznl
`
`
`
`
`mm>hum:zuqu-oszzomx
`
`xomzZHJquWPDLI
`
`
`
`mum:mH<ZmCLI
`
`cummmuoma
`
`
`
`
`
`
`
`Ammmoomm=4H<2mgxHZD.m.mv
`
`
`
`zo~w<2u~mzou.DMZI
`
`
`
`mom:wp<zmoul
`
`
`
`>mobummuemmJJOmpzou
`
`
`
`Amuamo<meauazxouHuaz.m.wv
`
`awhmmUmmz:
`
`mohsmHuhmHaz:
`
`mmHszm
`
`m—.9:
`
`Page 15 of 23
`
`
`
`
`
`xUqu<Haupwmuszu
`
`
`
`
`
`
`
`
`
`“awhm>mozHo<mmmzomHmszOhmuH>umm“4H<:wah20mgmuo<mmmz
`
`oh
`
`
`
`AxmmvIUHHzm
`
`gcm:
`
`“Ao<mHpmmsoumvmQHJmzszdo4H4:uuHo>zuzLomuzmmmmmmommmzommmm>mm30|mm
`
`
`
`"mQHAmzzHLmo4H<zmoHo>zmzLomuzmmummLoonpquHLHhozlvm
`
`
`
`
`"muH>mmmHXMHopomom<zmommqumszmawhzmumo<mmm21mm
`
`
`
`
`uAm<mHmmzommmavHmmncumHHQ3<onh<onHHOZINm
`
`
`
`
`
`
`
`.oz_om<3momLomsb<hmmompmmjcmmDHumzommmmxmm
`
`u>mqumzfihwLom3H<hmyouhmuzommOHuozommmm«om
`
`Page 15 of 23
`
`
`
`
`
`
`
`

`

`2
`so that the user could hear the message even though no
`data terminal is available. Some voice terminals have
`data displays associated with them. In such situations,
`the data message can be retrieved via the voice terminal
`display.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`These and other objects and features, together with
`the operation and utilization of the present invention,
`will be more apparent from the illustrative embodiment
`shown in conjunction with the drawings in which
`FIG. 1 is an overall block diagram of our system;
`FIG. 2 shows a typical key pad and alerting device;
`FIGS. 3—5 show a block layout of the control struc-
`ture for our system;
`FIGS. 6-9 show various message scenarios;
`FIGS. 10-14 show flow charts of message process-
`ing; and
`FIG. 15 shows a block diagram of our message sys-
`tem.
`
`GENERAL DESCRIPTION
`
`The unified messaging system (UMS 10), shown in
`FIG. 1, is based on several basic principles of integra-
`tion that underlie all aspects of our messaging system.
`These fall into three areas. First, UMS provides guide-
`lines for a basic set of consistent service attributes such
`as unified messaging mailbox, unified messaging re-
`trieval and unified messaging preparation. Secondly,
`user interface guidelines are established for messaging
`services to give users a consistent set of names and
`semantics for all messaging services. This is provided by
`unified alerting/notification and unified message re-
`trieval commands Finally, UMS provides an underlying
`application architecture, or unified connectivity, that
`enables all messaging services to communicate with
`each other.
`
`Unified messaging system 10 is the one access point
`for all messages regardless of the message type and
`regardless of the message origination. This capability is
`made possible by an underlying message transfer archi-
`tecture, to be described hereinafter, that forwards mes-
`sages and message notifications from one service to
`another. Forwarding can be done automatically under
`system control, or under direct control by the user.
`Users are able to retrieve messages from their chosen
`unified messaging mailbox using any of several terminal
`types, such as, for example, terminals 101-108, from any
`location, local or remote. Thus, a user has unified access
`to any messaging service such as, by way of example,
`electronic mail 110, voice mail 109, private data system
`111, local area network 112, message coverage 113 or
`fax 114. Some of these services, as shown, are con-
`trolled directly from PBX 12 and some by unified mes-
`sage system 10.
`limitations of
`Depending upon the technological
`some retrieval devices or some message services, how-
`ever, users may only be able to retrieve parts of a mes-
`sage or messages in certain forms. For example, from a
`data terminal (103-107) a user can retrieve only the
`voice mail header or abstract identifying the sender,
`date, time, etc. Using this header information, a user
`could select the desired message and hear the entire
`voice message on an associated voice station 101—102. A
`limited display telephone 102 can only retrieve abstracts
`and short messages. Text-to-speech converter 13 uses
`the well-known text-to-speech technology for media
`
`1
`
`4,837,798
`
`COMMUNICATION SYSTEM HAVING UNIFIED
`MESSAGING
`
`BACKGROUND OF THE INVENTION
`
`5
`
`10
`
`15
`
`This invention relates to communication system mes-
`sage notification systems and more particularly to such
`systems where messages received from various medi-
`ums are all reported to a user at a single point.
`It has become common practice within the past few
`years to arrange a communication system to receive
`voice messages when a called party is unavailable. The
`received message is recorded and a notification, usually
`a lighted lamp, is given to the called party indicating the
`presence of a message that is waiting.
`As data terminals become popular, people have
`begun to communicate over the data network by send-
`ing ‘mail’ messages to one another. These messages
`arrive at
`the called party’s host computer and are
`queued waiting for the called party to request their 20
`presentation in display form on the screen of a terminal
`connected to the host computer. While this arrange-
`ment is a great step forward in the evolution of commu-
`nication, it still presents problems in that terminals are
`not always available for use by a called party. For ex- 25
`ample, if a data message were to be sent to an electronic
`address and the addressee were to be away at a location
`remote from his or her host computer, the received
`message would not be available to the addressee. Of
`equal concern, the addressee would not even know that 30
`a message has been delivered.
`The problems compound when users have several
`different electronic ‘mail’ services. Users must log on to
`each such service just to find out if messages are wait-
`ing. Then each message is retrieved from each service in 35
`a different manner and possibly using different termi-
`nals.
`
`SUMMARY OF THE INVENTION
`
`50
`
`' We have constructed a messaging system which al- 40
`lows a user (addressee) to specify one service as a cen-
`tral
`repository of messages which are delivered
`from/by any of the other services available to that user.
`For example, if a user has a voice mail service associ-
`ated with a telephone station set and a data mail service 45
`available with a terminal (or PC), that use may specify
`either service as the recipient service. Thus, when a
`message arrives in either service, the notification of the
`arrival of that message is given only in the recipient
`service.
`For example, assuming that the user has selected the
`data mail service as the recipient service, then a voice
`message which arrives via the voice service would
`cause a message to be displayed on the data terminal
`associated with the host computer serving the mail 55
`service indicating that a voice message has arrived. The
`user could then retrieve the voice message in the normal
`manner via the voice terminal or the user could view an
`abstract of the message on the terminal screen. On the
`other hand, assuming that the user had signified that the 60
`voice service was to be the recipient, then the lighted
`lamp, or other means, associated with the voice termi—
`nal would indicate that messages have arrived. The user
`then would attempt to retrieve the messages and would
`be told that some of the messages which are waiting are 65
`electronic messages available at the terminal. The user,
`in one embodiment, could then request via the voice
`terminal that the data message be converted to speech
`
`Page 16 of 23
`
`Page 16 of 23
`
`

`

`4,837,798
`
`4
`ward message delivery and application specific service
`functions, and (2) content description architecture 50
`which provides a standard way of identifying and de-
`scribing contents across dissimilar systems.
`The presentation layer 303 handles protocol negotia-
`tions between peer applications concerning the choice
`of formats for representing information for transmission
`(the choice of transfer syntax). Presentation layer 303
`services also define such functions as document coding
`and conversion (303-10), encryption coding and con-
`version (303—20), and voice coding and conversion
`(303—30).
`'
`As shOWn in FIG. 4, message service architecture 40
`contains three components; message transport header
`401, message services protocols 404-405 and message
`report header 402.
`Message transport header 401 is the message enve-
`lope that contains inforrnation relevant to the transmis-
`sion of the message: the origination and destination
`addresses, a time-stamp and various transport options
`(e.g., grade-of service). Message report header 402 is
`used to return transmission related status information.
`Message services protocols 404—405 contain functions
`required by specific messaging applications such as
`electronic mail 405 (e.g., copy-to, subject) and notifica-
`tion services 404 (e.g., message waiting indicator, mes-
`sage forwarding).
`To digress momentarily, FIG. 15 details the messages
`exchanged between the unified messaging system
`(UMS) and the mail service. The messages fall into four
`categories of actions: (1) update, (2) query, (3) response,
`and (4) notification. Update messages include requests
`for updating the alerting mechanism (e.g., turn the lamp
`on/off), requests for updating the itinerary information
`stored on the call coverage (message center) service for
`accurately answering phone calls and requests for up-
`dating forwarding status (e.g., turning the autoforward-
`ing on/off from the call coverage service to the mail
`service). Queries are used to ask for accurate status
`information (e.g., is the forwarding on/off, what is the
`latest
`itinerary information,
`is there new voice mail
`waiting, etc.) and the responses are used to reply to the
`queries. Notifications are sent from the UMS to the mail
`service to notify the users of the presence of new mes-
`sages in their other messaging services.
`FIG. 5 shows content descriptor architecture 50
`which describes the contents of the message. Contents
`may be as simple as a user-entered text message or as
`complex as a voice message embedded in a word-proc-
`essing document containing a graph and spreadsheet.
`The basic structure of content descriptor architecture
`50 parallels that of the message service architecture. It
`consists of the unified content description header
`(UCDH 501), content services protocol and the de—
`scribed contents The UCDH 501 contains fields de-
`scribing the type, encoding characteristics and length of
`the contents It is entirely adequate for describing simple
`contents (e.g., an unfonnatted text message) or contents
`having well-defined and standardized structures. The
`content descriptor architecture 501 also provides fUnc-
`tions for describing non-standard structures.
`Following the UCDH are the content services 502,
`503. These services provide additional information re-
`garding the content sent with the message 401, 404, 405.
`This information might include the specific format of
`the content, the type of application used to create the
`content, the date of creation, the author’s name, etc.
`Finally, the actual contents follows 504, 505, 506, 507.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`3
`conversion so that most types of messages can be re-
`trieved in voice form from a conventional voice tele=
`phone 101,102.
`Message senders are able to create a message without
`knowing the recipient’s retrieval system or retrieval
`device. For instance, an electronic mail user can create
`a meeting notice and send it to several people. These
`recipients may or may not be electronic mail users. One
`recipient may receive the meeting notice from (1) the
`United States Postal Service via an electronic paper
`mail gateway; (2) through text-to-speech conversion; or
`(3) by calling the message center agent. Yet another
`recipient may receive the meeting notice on a personal
`computer. In each case, the sender simply creates the
`meeting notice, enters the names and addresses of the
`recipients in a consistent way and sends the mail with-
`out having to be aware of the recipients’ retrieval ser-
`vices or retrieval devices. It is the recipient who desig-
`nates one of his/her services 109—114, as the receptor
`service and all messages, or notifications of messages,
`go to the designated receptor.
`Whenever a user-designated receptor receives a new
`message, be it text, voice or facsimile, that user is alerted
`to that fact. Alerting is achieved, for example, by light-
`ing message waiting lamp (MWL) 20 (FIG. 2) which is
`part of face plate 201 of users” voice terminal 101 or 102
`(FIG. 1). Alerting on data terminals is achieved by
`activating the terminal screen indicator on electronic
`terminals Users see the illuminated lamp or screen indi-
`cator and may then enter their receptor service in the
`prescribed manner to retrieve their messages Notifica-
`tion of new messages is done within the mailbox by
`icons or single-line entries on the screen. In cases where
`messages cannot be forwarded, these notifications tell
`the users where they have new messages on other ser-
`vices.
`A consistent set of message retrieval commands is
`available from every terminal FIG. 2 illustrates the
`layout of the basic message retrieval commands that are
`available via the typical voice terminal key pad. This
`interface is used, for example, for voice store-and-for-
`ward services and for text-to—speech retrieval of text
`messages. These same message retrieval commands
`could be available on limited-character display tenni—
`nals, and on full screen terminals.
`DETAILED DESCRIPTION
`
`FIG. 3 shows the control or application architecture
`for the described system. The goal of the application
`architecture is to provide a basis for interoperation and
`cooperation between applications distributed through-
`out a network, and to ensure a consistent end-user view
`of basic communication services across various prod-
`ucts. The application architecture includes an applica-
`tion layer 302, a presentation layer 303, as well as a user
`interface layer 301.
`The user interface layer 301 is the end-user point of
`interaction with the system. It defines standard formats
`and capabilities for collecting use input and for display:
`ing information (including feedback, error messages and
`data) to the user. User applications (109, 110, 111) can
`also make use of the user interface layer 301 services to
`collect user input and to display information in standard
`ways.
`As shown in FIG. 3, application layer 302 includes
`two major components, namely, (1) message service
`architecture 40 which contains application independent
`transmission related services that support store-and-for-
`:
`
`Page 17 of 23
`
`Page 17 of 23
`
`

`

`4,837,798
`
`6
`a single point of message retrieval, one conceptual mes-
`sage box (universal mailbox) is established for each user.
`This can be established, ideally, under user control. A
`second goal is to provide a single, common alerting
`when messages are received in the universal mailbox.
`The user has the choice of where (i.e., in what control-
`ling service) the universal mailbox will be located. This
`is accomplished, for example, by users instructing their
`other messaging services to forward their messages to
`the unified mailbox. This can be done from the users
`terminal or by a central administrator. The universal
`mailbox will be referred to as the prime message recep-
`tor and can be classified into one of four message serv-
`ers:
`
`(1) a switch (PBX) based text messaging service;
`(2) a switch (PBX) based voice messaging service;
`(3) a stand-alone text messaging service; and
`(4) a stand-alone voice messaging service. Each of
`these four major categories will now be described.
`FIG. 6 shows a switch based text messaging service
`which can receive text (data) messages from any remote
`text messaging service, such as electronic mail service
`110 of a message sender, that supports the MHS.ASCII
`protocol. Services 109 and 110 are advantageously
`sending user controllable software residing on any pro-
`cessor associated with the sending user. Services 601
`and 602 are receiving user controllable software resid-
`ing on processors integral with PBX switch 12. Services
`603 and 604 are receiving user controllable software
`residing on stand-alone processors.
`When the receiving text messaging service cannot
`accept voice messages and the sending service is a voice
`service, such as voice mail 109 (which can be the well-
`known Audio Information Exchange Service provided
`by AT&”I), the receiving service can still provide text
`notifications of messages intended for the end-user,
`provided the sending service transmits some informa-
`tion pertaining to the message. This information can be
`the scanline headers or notifications associated with
`each message. These notifications are used to announce
`the arrival of new mail in the remote system (e. g. “You
`Have Voice Mail”). Complete header, or abstract, in-
`formation is sent instead of notifications when the send-
`ing service can support header creation and transmis-
`sion (e.g. “32 second voice mail from Bill Evancho at
`xxx-5555 delivered at 12:15 am on April 15”). When
`new mail or notifications arrive at the text mail service,
`the associated PBX switch 12 is signaled to alert the
`end-user to new messages. This alerting can be the light-
`ing of lamp 20 at voice terminal 101.
`FIG. 7 shows a switch based voice messaging service
`which receives voice messages from all remote voice
`messaging systems that support the MHSASCII proto-
`col. Remote text messaging services can deliver to the
`voice messaging system either (I) the entire message
`using conventional, well-known text-to-voice translated
`information;
`(2) headers about
`the text
`information
`stored on the remote text system (e.g. “text mail of 532
`characters, from Tony Selemi, at 3:20 pm on 4/17, sub-
`60 ject: meeting cancellation”); or (3) a notification mes-
`sage (e.g. “You Have Text Mail”). As discussed above,
`when new messages arrive at the voice messaging ser-
`vice, the associated switch is signaled to alert the end-
`user to new messages.
`FIG. 8 shows a stand-alone text mail service where
`messages are received exactly as in scenario 1 (FIG. 6).
`However, the alerting function is achieved by means of
`a message request sent from text messaging service 604
`
`5
`This is the content that was fully described by 501—503
`so that the receiving system has enough information to
`process the contents.
`A user agent (UA) process on the user’s actual mes-
`saging service takes the information provided by the
`sending user (FIG. 10: 1001, 1002, 1003, 1004, 1005,
`1006, 1007, 1008, 1009) and formats it according to the
`architecture (FIG. 10: 1010, 1012, 1013, 1015—1019) for
`the particular service. The user agent process then
`passes this formatted message to a message transport
`agent located within the user’s particular service. The
`MHSASCII is responsible for transmitting the mes-
`sage. It takes the message from the UA and creates the
`“envelope” for the message (FIG. 10: 1011, 1014). Once
`the envelope is constructed, the MHS.ASCII takes the
`necessary steps to assure accurate transmission of the
`message to the destination service.
`The architectural model underlying MHS.ASCII is
`derived from CCITT’s Messaging Handling System
`(MHS), the international standard for exchanging elec-
`tronic mail messages. The application layer services
`provided by MHS.ASCII are a superset of those de-
`fined by MHS. With respect to presentation layer ser-
`vices, MHSASCII is American Standard Code for
`Information Interexchange (ASCII) coded, providing
`compatibility with standard AT&T UNIX ® Operating
`System mail and a human-readable format. In contrast,
`MHS is binary encoded. Thus, if the underlying proto-
`col layers are compatible, communication between mes-
`sage Transfer Architecture and MHS services requires
`a straightforward conversion at the presentation layer.
`SPEECH CODING
`
`Digital encoding of speech is an old technology,
`presently used in extensively deployed digital carrier
`systems. Pulse Code Modulation (PCM) is the most
`commonly used method, encoding voice into 56 or 64
`Kbps. The encoded voice form is a well-defined stan-
`dard (although two versions exist
`internationally).
`More recently, Adaptive Differential Pulse Code Mod-
`ulation (ADPCM) techniques have been developed that
`reduce the voice coding rate to 32Kbps, yet retain “toll
`quality” fidelity. Standards are also in place for these
`algorithms. When voice coding and storage is intended
`to occur in customer premises equipment, product de-
`signers frequently compromise voice fidelity slightly to
`obtain reduced storage requirements by using a lower
`encoding rate.
`
`TEXT-TO-SPEECH CONVERSION
`
`10
`
`15
`
`20
`
`25
`
`3O
`
`35
`
`45
`
`50
`
`55
`
`Unified messaging retrieval is greatly enhanced by
`use of text-to-speech technology. This technology al-
`lows text message retrieval when the user is at a voice-
`only instrument. ASCII text is subjected to format pro-
`cessing (e.g., for abbreviations), syntactical analysis and
`letter-to-phone-me conversion. The resulting represen—
`tation of phone-mes and stress marks is converted to
`sound by a set of rules that drive a speech synthesizer.
`Dictionaries are included to provide proper sounding
`phone-me strings for words and names that would be
`incorrectly pronounced by the ASCII-to-phone-me
`translation al