(12) United States Patent
`Gleichauf
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7.412,598 B1
`Aug. 12, 2008
`
`USOO7412598B1
`
`(54) METHOD AND SYSTEM FOR REAL-TIME
`INSERTON OF SERVICE DURING ACALL
`SESSION OVER A COMMUNICATION
`NETWORK
`
`(75) Inventor: Robert E. Gleichauf, San Antonio, TX
`(US)
`(73) Assignee: Cisco Technology, Inc., San Jose, CA
`(US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 744 days.
`(21) Appl. No.: 09/751,811
`
`(*) Notice:
`
`Dec. 29, 2000
`
`(22) Filed:
`(51) Int. Cl.
`(2006.01)
`H04L 9/32
`(2006.01)
`H04L 9/00
`(2006.01)
`H04M II/00
`(2006.01)
`H04M 5/00
`(52) U.S. Cl. ....................... 713/155: 713/168; 713/182:
`726/4; 726/10; 379/92.04; 379/93.02; 379/93.03;
`3797243
`(58) Field of Classification Search ................. 713/155,
`713/165, 185, 200, 201
`See application file for complete search history.
`References Cited
`
`(56)
`
`U.S. PATENT DOCUMENTS
`
`1, 1996 Loucks et al. ............... T13 201
`5,481,720 A
`5,560,008 A * 9/1996 Johnson et al. ............. T13 201
`5,764,887 A * 6/1998 Kells et al. .................. T13/200
`5,768,379 A * 6/1998 Girault et al. ............... T13,185
`5,787,170 A
`7, 1998 Op de Beek ................ T13,165
`5,815,574 A
`9/1998 Fortinsky .................... T13,153
`5,822,433 A * 10/1998 Bottle et al. ................ 713,155
`5,854,894. A * 12/1998 Lancaster et al. ........... TO9,219
`5,864,665 A
`1, 1999 Tran ........................... T13 201
`5,920,562 A
`7, 1999 Christie et al. .............. 370,395
`5,928,323 A * 7/1999 Gosling et al. .............. TO9,203
`
`5,974,566 A * 10/1999 Ault et al. ..................... T14? 15
`5,983,273 A * 1 1/1999 White et al. ................ 709,229
`6,088.430 A
`7/2000 McHale ............
`... 379,9328
`6,122,631 A
`9/2000 Berbec et al. .................. 707/9
`6,393,481 B1*
`5/2002 Deo et al. .........
`... 709,224
`6,401211 B1*
`6/2002 Brezak et al. .....
`... 713,201
`9/2002 Bittinger et al. ...
`6,453,362 B1*
`... 719.316
`6,477,708 B1 * 1 1/2002 Sawa ................
`... 25,116
`... 713, 176
`6,567,916 B1* 5/2003 Terao et al. ....
`6,678,733 B1* 1/2004 Brown et al. ...
`... 709,229
`6,760,759 B1* 7/2004 Chan ................
`... TO9,219
`6,819,652 B1 * 1 1/2004 Akhtar et al. .....
`... 370,230
`6,986,157 B1 *
`1/2006 Fijolek et al. ............... 725,111
`7,079,499 B1* 7/2006 Akhtar et al. ............... 370,310
`7,145,898 B1* 12/2006 Elliott ..............
`... 370,352
`2006/0106703 A1* 5/2006 Del Rey et al. ............... 705/35
`
`OTHER PUBLICATIONS
`Woo et al. Authentication for Distributed Systems, 1992, IEEE, pp.
`39-51.*
`Neuman et al. Kerberos: An Authentication Service for Computer
`Networks, 1994, IEEE, pp. 33-38.*
`Anonymous, Kerberos: A Model for Single Sign-On, 2004, Business
`Communications Review, p. 43.*
`Fontana, John, Web Services Security Spec Approved, 2004, Net
`work World, p. 22.*
`* cited by examiner
`Primary Examiner Ayaz Sheikh
`Assistant Examiner—Aravind K Moorthy
`(74) Attorney, Agent, or Firm Baker Botts L.L.P.
`
`(57)
`
`ABSTRACT
`
`A method and apparatus for real-time insertion of services
`into an IP telephony call session are disclosed. A client ini
`t1ates a service request message to a second server. The ser
`Vice request message includes the client identity and a
`requested service available from a second server. The first
`server determines if the client is authorized to use the
`requested service. If the client is authorized to use the
`requested service, the second server delivers the requested
`service to the client
`
`35 Claims, 3 Drawing Sheets
`
`
`
`18
`A
`SERVER
`
`
`
`
`
`20
`
`SERVER
`
`
`
`
`
`
`
`LIST OF
`SERVICES
`
`LIST OF CIENTS
`AND AUTHORIZATION
`
`9
`
`16
`
`IPR2018-00884
`Apple Inc. EX1007 Page 1
`
`

`

`U.S. Patent
`
`Aug. 12, 2008
`
`Sheet 1 of 3
`
`US 7412,598 B1
`
`
`
`
`
`18
`
`SERVER
`
`LIST OF
`SERVICES
`
`20
`
`SERVER
`
`LIST OF CIENTS
`AND AUTHORIZATION
`
`FIC.
`
`Eades
`
`
`
`
`
`FIC. 2B
`42
`
`20
`
`SERVER
`
`40
`
`18
`
`46
`
`
`
`
`
`IPR2018-00884
`Apple Inc. EX1007 Page 2
`
`

`

`U.S. Patent
`
`Aug. 12, 2008
`
`Sheet 2 of 3
`
`US 7412,598 B1
`
`REJECT SERVICE
`REQUEST MESSAGE
`
`
`
`FIC. 3
`
`80- REQUESTING CLIENT OBTAIN ADDRESSES
`FOR PARTICIPATING CLIENTS
`
`82
`
`84
`
`90
`
`
`
`
`
`REQUESTING CLIENT INITIATE
`A SERVICE REQUEST MESSAGE
`
`COMPARE CLIENT DENTITY AND
`REQUESTED SERVICE WITH A LIST
`OF AUTHORIZED CLIENTS
`
`86
`
`
`
`IS
`REQUESTING CLIENT
`AUTHORIZED
`p
`
`YES
`ISSUE AUTHORIZATION TICKET
`TO REQUESTING CLIENT
`
`REQUESTING CLIENT SEND AUTHORIZATION
`TICKET AND ADDRESSES TO SERVICE
`
`92
`
`94.
`
`READ TICKETAT SERVER
`TO RETRIEVE SERVICE
`
`DELIVER REQUESTED SERVICE TO
`961CLIENTS PARTICIPATING IN CALL SESSION
`
`
`
`
`
`is.
`
`SESSION
`ENDED?
`
`
`
`98
`
`YES
`DELETE SERVICE FROM CLIENTS
`
`100
`
`END
`
`IPR2018-00884
`Apple Inc. EX1007 Page 3
`
`

`

`U.S. Patent
`
`Aug. 12, 2008
`
`Sheet 3 of 3
`
`US 7412,598 B1
`
`FIG. 4
`
`110
`
`PARTICIPATING CLIENTS
`AUTHORIZED TO USE
`REQUESTED SERVICE
`
`
`
`
`
`
`
`OBTAN
`USAGE TOKEN FROM
`ALL CLIENTS?
`
`YES
`
`DELETE ONE TOKEN
`FROM EACH
`PARTICIPATING
`CLIENT ACCOUNT
`
`114
`
`
`
`
`
`
`
`
`
`
`
`
`
`120
`
`
`
`
`
`122
`
`DELETE REMAINING
`TOKENS FROM
`REQUESTING CLIENT
`ACCOUNT
`
`CHARGE REQUESTING
`CLEENT ACCOUNT FOR
`EXTRA TOKENS
`
`OBTAIN
`AL TOKENS FROM
`REQUESTING
`CLENT
`
`DELETE TOKENS
`FROM REQUESTING
`CENT ACCOUNT
`
`
`
`IPR2018-00884
`Apple Inc. EX1007 Page 4
`
`

`

`US 7,412,598 B1
`
`1.
`METHOD AND SYSTEM FOR REAL-TIME
`INSERTON OF SERVICE DURING ACALL
`SESSION OVER A COMMUNICATION
`NETWORK
`
`2
`includes a client, a first device and a second device coupled to
`a communication network. The first device includes a list of
`clients authorized to receive a plurality of services. The sec
`ond device inserts one or more of the services requested by
`the client into the call session if the list includes the client and
`the requested service.
`Important technical advantages of certain embodiments of
`the present invention include the ability to add services for use
`during a call session. In a conventional communication sys
`tem, a Subscriber may use an extra service installed on a
`network if the subscriber requests and pays for the service
`before beginning the call session. The present invention
`allows the Subscriberto add one or more services during a call
`session. If the equipment used by the Subscriberis not capable
`of receiving the requested service, the necessary Software
`may be configured at a remote location, Such as a server, and
`uploaded onto a cache, or other Suitable memory, associated
`with the subscriber's equipment. When the call session is
`terminated or the subscriber disconnects from or breaks com
`munication with the call session, the service and associated
`software may be deleted from the subscriber's equipment by
`flushing the cache.
`Another important technical advantage of certain embodi
`ments of the present invention includes the ability of a service
`provider to charge a Subscriber for a requested service based
`on use of the requested service. When the subscriber requests
`to use a service, either by subscribing to the service for
`specific time period, requesting the service prior to initiating
`a call session, or requesting the service during the call session,
`the service provider creates an account for the subscriber. The
`account may contain usage tokens for the requested service.
`Each time the subscriber uses the requested service, a usage
`token is deleted from the subscriber's account. The service
`provider, therefore, may track usage of the service and bill the
`subscriber based on the number of tokens used.
`Other technical advantages will be readily apparent to one
`skilled in the art from the following figures, descriptions, and
`claims.
`
`TECHNICAL FIELD OF THE INVENTION
`
`This invention relates in general to Internet Protocol (IP)
`telephony, and more particularly to a method and system for
`real-time insertion of services during a call session over a
`communication network.
`
`10
`
`BACKGROUND OF THE INVENTION
`
`15
`
`IP telephony uses the Internet Protocol (IP) to transmit
`Voice as packets over any data network that Supports IP.
`Traditional circuit switched networks, such as the public
`switched telephone network (PSTN), establish a call by set
`ting up an end-to-end circuit between two telephones. The
`switched connection is established for the duration of the
`telephone call, with a fixed bandwidth. In contrast, an IP
`telephony connection digitizes, compresses and converts the
`Voice signal into IP packets and transmits the packets over the
`data network. Numerous different calls may share the same
`network and each participant in a call may have a different
`bandwidth that varies over the duration of the call depending
`on the amount of data being communicated over the network
`at any given time.
`Conventional phone service provided over the PSTN
`requires a Subscriberto pay for long distance service based on
`30
`the number of minutes for the call. Furthermore, if the sub
`scriber would like to add a special service, such as caller id,
`call forwarding or call waiting, the Subscriber typically pays
`a monthly fee for the service. This fee is paid to the telephone
`company even if the subscriber does not use the service dur
`ing the month. IP telephony service operates in a similar way
`because the subscriber is limited to services provided by an
`Internet Service Provider (ISP) for a fee during a specific
`period.
`
`25
`
`35
`
`SUMMARY OF THE INVENTION
`
`40
`
`In accordance with the teachings of the present invention,
`disadvantages and problems associated with real-time inser
`tion of services during a call session over a communication
`network have been substantially reduced or eliminated. In a
`particular embodiment, Session-based Services Telephony
`Protocol (SSTP) for use in Internet Protocol (IP) telephony is
`disclosed that allows a user to add services, such as the ability
`to send data for use in a word processing application or the
`ability to increase the level of encryption provided, during an
`IP telephony call session by requesting a desired service from
`a server coupled to a packet-based network.
`In accordance with one embodiment of the present inven
`tion, a method for real-time insertion of services during a call
`session over a communication network includes initiating a
`Service Request Message (SRM) by a first client to a first
`server. The SRM includes the first client identity and a
`requested service available from a second server including a
`plurality of services. Upon receiving the message, the first
`server determines if the first client is authorized to receive the
`requested service. If the first client is authorized to receive the
`requested service, the second server delivers the requested
`service to the first client.
`In accordance with another embodiment of the present
`invention, a communication system for real-time insertion of
`services during a call session over a communication network
`
`45
`
`50
`
`55
`
`60
`
`65
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 illustrates a communication network incorporating
`one embodiment of the present invention;
`FIG. 2A illustrates a block diagram of one embodiment for
`inserting a requested service into a call session;
`FIG. 2B illustrates a block diagram of an alternative
`embodiment for inserting the requested service into the call
`session;
`FIG. 2C illustrates a block diagram of a further embodi
`ment for inserting the requested service into the call session;
`FIG. 3 illustrates a flowchart of a method for real-time
`insertion of services into a call session over the communica
`tion network;
`FIG. 4 illustrates a flowchart of a method for charging a
`client for use of the requested service.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`FIG. 1 illustrates a block diagram of a communication
`system 10 that Supports real-time insertion of services during
`a call session over network 12. System 10 includes network
`12, clients 14 and 16, and servers 18 and 20. Server 18
`includes a list of services that may be requested by clients 14
`and 16 during a call session and associated Software applica
`tions to execute the services. Server 20 includes a database
`containing a list of clients that may couple to network 12 and
`the services available from server 18 that each client is autho
`
`IPR2018-00884
`Apple Inc. EX1007 Page 5
`
`

`

`US 7,412,598 B1
`
`10
`
`15
`
`3
`rized to receive. Clients 14 and 16 may request authorization
`from server 20 to use one or more services stored on server 18.
`If server 20 determines that clients 14 and 16 are authorized to
`use a requested service, server 18 sends the requested service
`to clients 14 and 16. Although servers 18 and 20 are described
`as being separate, the list of authorized clients and the Ser
`vices and their associated applications may be physically
`located on a single device, such as a server, router, call man
`ager, or other Suitable network control device.
`Network 12 may be a local area network (LAN), a wide
`area network (WAN), the Internet or other similar network
`that transmits packets of Voice, video, data and other infor
`mation (generally referred to as media). In a particular
`embodiment, network 12 may be an Internet Protocol (IP)
`network. However, network 12 may be any type of network
`that allows transmission of audio and video telecommunica
`tion signals, as well as traditional data communications.
`Although the invention will be described primarily with
`respect to IP communications, it should be understood that
`other appropriate methods of transmitting media over a data
`network, Such as a Frame Relay, Asynchronous Transfer
`Mode (ATM), or other packet-based network, are also
`included within the scope of the present invention.
`Network 12 may be coupled to other IP networks and may
`communicate media between clients 14 and 16, and other
`clients (not expressly shown) located on different, but inter
`connected, IP networks (not expressly shown) Network 12
`may also be coupled to non-IP communication networks
`through the use of gateway devices. For example, network 12
`may be coupled to a private branch exchange (PBX) or the
`public switched telephone network (PSTN) through an
`appropriate gateway (not expressly shown). The gateway may
`digitize the telephone or data signal from the PBX or PSTN if
`it is not already digitized, compress the digitized signal and
`route it to a destination over network 12 in packet form. The
`gateway may also convert packets of data into telephone
`signals that may be transmitted across the PBX or PSTN.
`IP networks and other packet-based networks typically
`transmit media by placing data in cells, packets, frames, or
`other portions of information (generally referred to as pack
`ets) and sending each packet individually to the selected
`destination. Unlike a circuit-switched network, Such as the
`PSTN, dedicated circuits and bandwidth is not required for
`the duration of a call session over network 12. Instead, clients
`14 and 16 may send packets across network 12 as these
`resources become available for transmission. This feature
`makes resources available for additional communications
`when media is not being transmitted from clients 14 and 16.
`The technology that allows voice media in particular to be
`transmitted over a packet-based network may be referred to as
`Voice over Packet (VoP). Clients 14 and 16 have the capabil
`ity to encapsulate a user's voice or other content into IP
`packets so that the content may be transmitted over network
`12. Clients 14 and 16 may be IP telephones, computers run
`ning telephony Software, gateway devices, or any other
`device capable of performing telephony functions in an IP
`network. Clients 14 and 16 may also include a cache or any
`other type of storage medium for storing software applica
`tions and digital information.
`System 10 includes servers 18 and 20 that communicate
`with clients 14 and 16 via network 12. Servers 18 and 20 may
`have access to storage mediums that include databases of
`information. Multiple services and the applications required
`to support the services may be available from server 18.
`Server 18 may inject one or more of the services requested by
`clients 14 and 16 into a call session over network 12. Such
`services may include, but are not limited to, text documents,
`
`4
`telephone numbers, URLs, encoded music, graphics and Vid
`eos communicated between clients 14 and 16, encryption or
`increased encryption for packets communicated over net
`work 12, division of a conference call into multiple sub
`groups, and any other service Suitable to be transmitted across
`network 12 in packet form and used by clients 14 and 16
`during a call session. The applications available from server
`18 may include, but are not limited to, lightweight versions of
`a text editor, a spreadsheet tool, and a presentation tool similar
`to what can be found in MICROSOFT OFFICE application
`suite, ACROBAT READER, web browsers (e.g.,
`NETSCAPE or MICROSOFT EXPLORER), a software
`application that plays music, a software application that
`allows a user to view a graphic or a photograph on a monitor,
`a software application that allows a user to view a movie, a
`Software application that provides increased encryption for
`packets communicated over network 12, a Software applica
`tion that allows a user to break down a conference call into
`Subgroups, or any other Suitable application that may be con
`figured at a remote location, such as server 18, transmitted in
`packet form over network 12 and executed by clients 14 and
`16 during the call session.
`Server 20 includes a list or directory containing clients that
`may communicate with network 12 and the services available
`from server 18 that each client is authorized to use. When
`clients 14 and 16 are connected to network 12, clients 14 and
`16 may be assigned an IP address using dynamic host control
`protocol (DHCP) (not expressly shown) or another similar
`protocol or technique.
`In one embodiment, clients 14 and 16 issue a registration
`request to server 20 by submitting their respective IP
`addresses and their identities in the form of a digital certifi
`cate, a username and/or password, or any other Suitable way
`of providing identification information. Server 20 authenti
`cates clients 14 and 16 by submitting the IP addresses to a
`DHCP server and the client identity information to an authen
`tication system such as a Public Key Infrastructure (PKI)
`certificate authority, a Kerberos Domain Controller (KDC),
`or any other system suitable for authenticating the identity of
`a client or a user. If clients 14 and 16 are authenticated, the
`authentication system sends the authenticated credentials for
`clients 14 and 16 to server 20 and server 20 stores the creden
`tials in the list.
`Once the authenticated credentials for clients 14 and 16 are
`stored on server 20, the services available from server 18 may
`be added to the list. In one embodiment, client 14 may sub
`scribe to the desired service from a service provider and may
`have pre-existing authorization to use one or more of the
`services available from server 18 for each call session initi
`ated during a specific time period. In this example, the Ser
`vices may be added to the list on server 20 by the service
`provider and remain in the list until client 14 terminates the
`subscription for the service.
`In another embodiment, client 14 may subscribe to a ser
`vice provider for communication over network 12 but may
`not subscribe to any services available from server 18. After
`initiating a call session, client 14 may decide to add one of the
`services stored on server 18 to the call session. Server 20
`authenticates client 14 and adds the requested service to the
`list of services that client 14 is authorized to use. The
`requested service may be removed from the list when server
`20 receives a message indicating that the call session was
`terminated or client 14 disconnected from or otherwise broke
`communications with the call session.
`In a further embodiment, client 14 may contact a service
`provider prior to initiating a call session to request a service
`available from server 18. In this example, the service provider
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`IPR2018-00884
`Apple Inc. EX1007 Page 6
`
`

`

`US 7,412,598 B1
`
`5
`may add the requested service into the list of clients stored on
`server 20 so that client 14 will be authorized to receive the
`requested service when the call session is initiated. If client 14
`requests authorization to use the service for more than one
`call session, the service provider adds the requested service to
`the list stored on server 20 and specifies the number of times
`that client 14 may use the service. For example, if client 14
`requests to use the service four different times, the service
`provider updates the authorization list on server 20 to reflect
`that client 14 is authorized to use the requested service four
`times. When server 20 receives a SRM from client 14 to use
`the requested service, server 20 authorizes client 14 to use the
`requested service during the call session and deletes an entry
`from the list authorizing client 14 to use the requested service.
`The updated list contains authorization for client 14 to use the
`requested service three additional times.
`Although subsequent description refers to clients 14 and 16
`as the participants in a call session, other clients coupled to
`network 12 or other networks coupled to network 12 may
`participant in the call session. During a call session, client 14
`obtains a list of services available from server 18 and deter
`mines the IP address for client 16, which is participating in the
`call session. In one embodiment, client 14 may receive the list
`of services available from server 18 after being authenticated
`and authorized to use the services by server 20. Client 14 then
`initiates a Service Request Message (SRM) to server 20 to
`obtain authorization to use one or more requested services
`during the call session. In one embodiment, the SRM may
`include the requested service and the client identity for client
`14 in the form of a digital certificate, username and/or pass
`word, or any other Suitable means for providing identification
`information.
`Server 20 authenticates client 14 by comparing the client
`identity with a list containing the authenticated credentials for
`each client that may communicate with network 12. If authen
`tication fails, server 20 rejects the SRM from client 14. If the
`client identity matches one of the authenticated credentials in
`the list, server 20 determines if client 14 is authorized to use
`the requested service. If client 14 is not authorized to use the
`requested service, server 20 rejects the SRM from client 14. If
`client 14 is authorized to use the requested service, server 20
`sends an authorization ticket to client 14. In one embodiment,
`the authorization ticket includes the client identity for client
`14 and the requested service.
`Client 14 sends the authorization ticket to server 18. In one
`embodiment, client 14 also sends the IP address associated
`with client 16 to server 18. Server 18 reads the authorization
`ticket and retrieves the requested service. Server 18 then
`sends the requested service to client 14 based on the client
`identity in the authorization ticket and to client 16 by using
`the IP address received from client 14. Although client 14 has
`been described as the requesting client, it should be under
`stood that client 16, or any other client participating in the call
`session, may perform the described functions.
`In one embodiment, clients 14 and 16 may not include the
`Software application required to execute the requested Ser
`vice. Server 18 may configure the application associated with
`the requested service for use by clients 14 and 16 and load the
`required application into a cache or other Suitable memory
`associated with clients 14 and 16. In another embodiment,
`client 14 may have access to the Software application associ
`ated with the requested service, but client 16 may not have
`access to the application. If client 14 is authorized to use the
`requested service, server 18 may configure the Software
`application associated with the requested service for client 16
`and load the required application into the cache or other
`suitable memory associated with client 16.
`
`40
`
`45
`
`6
`In one embodiment, the Software application and its asso
`ciated service are transmitted over network 12 in packet form.
`Each packet travels through a protocol stack at the Source and
`destination devices. The protocol stacks may be based on the
`OpenSystem Interconnection Reference model (OSI model).
`The OSI model defines the communication characteristics for
`any given computer network and breaks communication
`between clients 14 and 16 coupled to network 12 into seven
`specific layers. The upper layers of the protocol stack are
`typically implemented in Software and include the session
`layer, the presentation layer and the application layer. The
`session layer ensures that communication sessions, including
`service requests and service responses between applications,
`are properly established and maintained. The presentation
`layer manipulates the packets of information and ensures that
`information sent from the application layer for client 14 will
`be readable by the application layer of client 16. The appli
`cation layer acts as a user interface for clients 14 and 16 to
`access network 12 services.
`The services and applications available from server 18 may
`be inserted into the call session in one of the upper layers of
`the protocol stack. If the requested service is inserted into the
`call session, more media information is being transmitted
`between clients 14 and 16. Due to the increased media, client
`14 may make a request for more bandwidth. In one embodi
`ment, the request for more bandwidth may be made using the
`Resource Reservation Protocol (RSVP). RSVP is a network
`control protocol that enables networks to obtain special quali
`ties of service (QoS) for the media flow across the network.
`RSVP operates in conjunction with routing protocols in the
`transport layer of the protocol stack. If an RSVP server deter
`mines that the bandwidth for the call session may be
`increased, an acknowledgement message may be sent to cli
`ent 14 indicating that the bandwidth has been increased.
`Otherwise, the RSVP server notifies client 14 that a best
`effort mode may be used for communication on network 12.
`If the minimum required bandwidth is available, the call
`session provisioning proceeds by using the bandwidth to
`transfer the service over network 12 and between clients 14
`and 16.
`Referring to FIGS. 2A through 2C, communication
`between servers 18 and 20 and clients 14 and 16 may occur
`over a single communication medium or multiple different
`communication mediums. The communication medium may
`be twisted pair wire, coaxial cable, fiber optic links, or any
`Suitable communication medium for transmitting packets of
`information over network 12.
`FIG. 2A illustrates a block diagram of one embodiment for
`real-time insertion of services into a call session. In the illus
`trated embodiment, client 14 initiates SRM 30 to server 20.
`SRM30 includes the client identity associated with client 14
`and one or more requested services available from server 18.
`Server 20 determines if client 14 is authorized to use the
`requested services by comparing the client identity and the
`requested services with a list and/or directory. The list
`includes authenticated credentials for each client that may
`communicate with network 12 and the services available
`from server 18 that each client is authorized to use. If server
`20 determines that client 14 is authorized to use the requested
`services, server 20 sends authorization ticket 32 to client 14.
`Authorization ticket 32 includes the client identity and the
`requested services. In one embodiment, server 20 encrypts
`authorization ticket 32 using its private key.
`Upon receiving authorization ticket 32, client 14 deter
`mines the IP address for client 16. Client 14 then sends
`authorization message 34 to server 18. Authorization mes
`sage 34 includes the client identity and the requested Services
`
`10
`
`15
`
`25
`
`30
`
`35
`
`50
`
`55
`
`60
`
`65
`
`IPR2018-00884
`Apple Inc. EX1007 Page 7
`
`

`

`US 7,412,598 B1
`
`10
`
`15
`
`7
`from authorization ticket 32, and the IP address for client 16.
`Server 18 decrypts authorization message 34 with a public
`key associated with server 20 and reads authorization mes
`sage 34 to retrieve the requested services. Server 18 then
`sends service message 36 in a secure manner to client 14 by
`using the client identity from authorization message 32 and
`service message 38 to client 16 based on the IP address.
`Service messages 36 and 38 include the requested services
`from authorization message 34.
`FIG. 2B illustrates a block diagram of an alternative
`embodiment for real-time insertion of services into a call
`session. In the illustrated embodiment, client 14 determines
`the IP address for client 16. In one embodiment, the IP
`address for client 16 may be obtained from a call manager
`(not expressly shown) coupled to network 12. Client 14 ini
`tiates SRM 40 to server 20 that includes the client identity
`associated with client 14, one or more requested services, and
`the IP address for client 16. Server 20 determines if client 14
`is authorized to use the requested Services by comparing the
`client identity and the requested services with a list of autho
`rized clients.
`If client 14 is authorized to use the requested services,
`server 20 sends authorization ticket 42 to server 18. By send
`ing authorization ticket 42 to server 18, server 20 reduces the
`amount of communication occurring over network 12. Autho
`rization ticket 42 includes the client identity associated with
`client 14, the requested services, and the IP address for client
`16. In one embodiment, server 20 encrypts authorization
`ticket 42 using its private key. Server 18 decrypts authoriza
`tion ticket 42 using a public key associated with server 20 and
`retrieves the requested services based on authorization ticket
`42. Server 18 then sends service message 44 to client 14 based
`on the client identity in authorization ticket 42 and service
`message 46 to client 16 by using the IP address for client 16.
`Service messages 44 and 46 include the requested Services
`from authorization ticket 42.
`In an alternative embodiment, once server 20 determines
`that client 14 is authorized to use the requested service, server
`20 uses the IP address to request a client identity for client 16.
`Client 16 receives the request and sends its identity to server
`20. Server 20 compares the client identity for client 16 and the
`requested service with the list of authorized clients. If client
`16 is authorized to use the requested service, server 20 sends
`authorization ticket 42 to server 18. The authorization ticket
`includes the client identities for clients 14 and 16, and the
`requested services. Server 18 reads authorization ticket 42
`and sends the requested services to clients 14 and 16 based on
`the respective client identities.
`FIG. 2C illustrates a block diagram of a further embodi
`ment for real-time insertion of services into a call session. In
`the illustrated embodiment, client 14 determines the IP
`address for client 16. Client 14 initiates SRM 50 to server 20
`that includes the client identity associated with client 14, one
`or more requested services, and the IP address for client 16.
`Server 20 determines if client 14 is authorized to use the
`requested services by comparing the client identity and the
`requested services with a list of authorized clients.
`If client 14 is authorized to use the requested services,
`server 20 locates client 16 based on the IP address in the
`service request message and sends identity request message
`52 to client 16. Client 16 sends client message 54, containing
`its identification information, to server 20. Server 20 com
`pares the client identity for client 16 to the list of authorized
`clients. If client 16 is authorized to use the services requested
`by client 14, server 20 issues first authorization ticket 56 to
`client 14 and second authorization ticket 58 to client 16. First
`authorization ticket 56 includes the client identity associated
`
`8
`with client 14 and the requested services, and second autho
`rization ticket 58 includes the client identity associated with
`cl