(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2009/0265764 A1
`SCHULTZ et al.
`(43) Pub. Date:
`Oct. 22, 2009
`
`US 20090265764A1
`
`(54) AGGREGATION AND USE OF
`INFORMATION RELATING TO A USERS
`CONTEXT
`
`(21) Appl. No.:
`
`12/106,444
`
`(22) Filed:
`
`Apr. 21, 2008
`
`(75) Inventors:
`
`Paul T. SCHULTZ, Colorado
`Springs, CO (US); Robert A.
`SARTINI, Colorado Springs, CO
`(US); Martin W. McKEE,
`Herndon, VA (US)
`
`Publication Classification
`
`51) Int. Cl.
`(
`(2006.01)
`H04L 9/32
`(52) U.S. Cl. ............................................................ 726/4
`
`Correspondence Address:
`VERZON
`PATENT MANAGEMENT GROUP
`1320 North Court House Road, 9th Floor
`ARLINGTON, VA 22201-2909 (US)
`
`(73) Assignee:
`
`VERIZON BUSINESS
`NETWORKSERVICES INC.,
`Ashburn, VA (US)
`
`(57)
`
`ABSTRACT
`
`Information, called context information, relating to a current
`state of a user may be aggregated. In one implementation, the
`context information may include information that is auto
`matically generated by communication devices of the user
`and information, submitted by the user, that relates to the
`user's state. The context information may be used by autho
`rized context consumers.
`
`600-
`
`610
`
`BIOMETRIC
`VERIFICATION
`
`PASSWORD
`VERIFICATION
`
`
`
`
`
`
`
`
`
`
`
`
`
`CONTEXT
`AGGREGATION
`AND SECURITY
`ENGINE
`USe
`Context
`
`CONTEXT-
`DEPENDENT
`AUTHORIZATION
`ENGINE
`
`- - - - - -
`USER
`NOTIFICATION
`- - - - - - -
`
`
`
`640 COMMUNICATION
`SESSION
`ESTABLISHMENT
`
`
`
`AUDIT
`NFORMATION
`
`WEB
`
`http
`
`ims
`
`EMAIL
`
`VOICE, VIDEO,
`STB (TV), SMS,
`MMS, IM, ETC.
`
`Twitter Exhibit 1008
`Page 00001
`
`

`

`Patent Application Publication
`
`Oct. 22, 2009 Sheet 1 of 7
`
`US 2009/0265764 A1
`
`?IE WIT SNOO
`
`LXE LNO O
`
`
`
`
`
`0 || ||
`
`9 || ||
`
`
`
`Page 00002
`
`

`

`Patent Application Publication
`
`Oct. 22, 2009 Sheet 2 of 7
`
`US 2009/0265764 A1
`
`ST18
`
`0 LZ
`
`
`
`>]OSSE OORHc]
`
`Z "SDI
`
`
`
`Page 00003
`
`

`

`Patent Application Publication
`
`Oct. 22, 2009 Sheet 3 of 7
`
`US 2009/0265764 A1
`
`029
`
`929
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`0 || 9
`
`S?ueune?sey)
`
`'poo-, e?SIT Áppng •
`
`
`
`HO[/\EC]
`
`
`
`SELLITIEV&VO 088
`
`Page 00004
`
`

`

`Patent Application Publication
`
`Oct. 22, 2009 Sheet 4 of 7
`
`US 2009/0265764 A1
`
`7 " SDI
`
`
`
`N__007
`
`Page 00005
`
`

`

`Patent Application Publication
`
`Oct. 22, 2009 Sheet 5 of 7
`
`US 2009/0265764 A1
`
`099
`
`01.9
`
`NIEDERE
`
`’NO||L\/ZIPHOHLTIV
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page 00006
`
`

`

`Patent Application Publication
`
`Oct. 22, 2009 Sheet 6 of 7
`
`US 2009/0265764 A1
`
`
`
`
`
`
`
`
`
`Page 00007
`
`

`

`Patent Application Publication
`
`Oct. 22, 2009 Sheet 7 of 7
`
`US 2009/0265764 A1
`
`
`
`
`
`HO NOI LVOICINI LOCH LITO ‘ESNOCHSENH
`
`
`
`
`
`97/
`
`'ESNOCHSEN Å HIN-HE/\
`
`07/
`
`0Z/
`
`
`
`">HEST LOV/LNO O
`
`GZZ
`
`2. CIECTEE
`
`ESNOdS=||}}
`
`ON
`
`
`
`
`
`TENNVHO NOI LVOINT||NWOO ETEISSO,
`
`* N15DE E
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Page 00008
`
`

`

`US 2009/0265764 A1
`
`Oct. 22, 2009
`
`AGGREGATION AND USE OF
`INFORMATION RELATING TO A USERS
`CONTEXT
`
`BACKGROUND INFORMATION
`0001 Modern telecommunication networks can provide a
`number of different types of services to users. For example, a
`user may, at any particular time, be communicating using a
`portable telephone, watching television using a set-top box,
`or interacting with a personal computer. Further, the user may
`be physically present in any number of different locations
`(i.e., the user may be at home, at work, or someplace else).
`0002. The on/off state of a user's communication devices,
`the physical location of the user, the user's presence and
`availability via various devices, and possibly other informa
`tion relating to the user's state, such as user preferences, may
`be useful to other people or businesses with whom the user
`interacts.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0003 FIG. 1 is a diagram illustrating an exemplary system
`in which concepts described herein may be implemented;
`0004 FIG. 2 is a diagram of an exemplary computing
`device used to implement elements shown in FIG. 1;
`0005 FIG. 3 is a diagram illustrating exemplary types of
`information that may be received and stored to define a user's
`context;
`0006 FIG. 4 is a diagram of an exemplary system for using
`context information collected by a context aggregator,
`0007 FIG. 5 is a flow chart illustrating exemplary opera
`tions for accessing and using a user's context by a context
`consumer,
`0008 FIG. 6 is a diagram of an exemplary system for using
`context information to enhance transaction authorization; and
`0009 FIG. 7 is a flow chart illustrating exemplary opera
`tions for performing authorization services of a transaction
`based on a user's context.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`0010. The following detailed description of exemplary
`implementations refers to the accompanying drawings. The
`same reference numbers in different drawings may identify
`the same or similar elements. Also, the following detailed
`description does not limit the invention.
`0011
`Implementations described herein may provide for
`systems that aggregate information relating to a state, called
`user "context information” or “context herein, correspond
`ing to a user. The aggregated context may be accessed by
`other users or businesses to potentially enable a number of
`possible services for the user. In some implementations, the
`ability or extent of others to access a user's context can be
`controlled by the user. Also, in some implementations, con
`text may be leveraged to provide context-based authentica
`tion for a wide variety of transactions.
`0012 FIG. 1 is a diagram illustrating an exemplary system
`100 in which concepts described herein may be implemented.
`As shown, system 100 includes a network 110, a user 115, a
`context consumer 120, and a context aggregator 125.
`0013 Network 110 may generally include one or more
`networks that provide telephony or data services to user 115,
`content consumer 120, or context aggregator 125. Network
`110 may include one or more networks of any type, including
`
`a Public Land Mobile Network (PLMN), a Public Switched
`Telephone Network (PSTN), a cellular network, a VOIP net
`work, a metropolitan area network (MAN), a wide area net
`work (WAN), a local area network (LAN), a private network,
`the Internet, an intranet, and/or another type of network.
`Network 110 may particularly represent a number of different
`types of networks, such as a cellular network, a PSTN, and a
`wide area data network (e.g., the Internet). In this situation,
`network 110 may also include gateway devices that provide
`interfaces between different network types.
`0014. User 115 may represent a person using telecommu
`nication services provided through network 110. User 115
`may interact with network 110 using one or more of a number
`of client devices. Such as a telephone device 116, a personal
`computer 117, or a television set-top box 118 (collectively
`referred to as devices 119). Telephone device 116 may gen
`erally include any type of telephone device. Such as a cellular
`or other mobile phone, a VoIP phone, or a personal digital
`assistant (PDA) or other type of smartphone. Personal com
`puter 117 may generally include any type of computing
`device. Such as a personal computer or laptop computer.
`Set-top box 118 may include set-top boxes designed to con
`nect a user's television to television content delivered via
`coaxial cable, fiber optic cable, or over the air. The functions
`of set-top box 118 may potentially be integrated within a
`television or computing device.
`0015 Context consumer 120 may represent one or more
`devices that, in some way, use ("consume') context informa
`tion for user 115. Context information, as used herein, refers
`to information relating to the state of user 115 and/or devices
`119. Context information may include, for example, presence
`and availability information (e.g., the on/off state of devices
`119, online/offline, busy, away, available, DoNotDisturb,
`etc.), capability information relating to devices 119 (e.g.,
`bandwidth, the services available on the device, etc.), the
`physical location of the user (at home, at work, etc.), status
`information provided by a user via one or more of devices
`119, and preference information of the user. Context infor
`mation and sources for context information will be described
`in more detail below with reference to FIG. 3.
`0016 Context consumer 120 may represent one or more
`computing devices. For example, context consumer 120 may
`be a server device, such as a web server, that uses context
`information to generate personalized web pages for user 115.
`As another example, context consumer 120 may be a client
`device, such as one of devices 119, that is being used by
`another user that is interacting with user 115.
`0017 Context aggregator 125 may keep track of context
`information for users. Context aggregator 125 may addition
`ally provide context information to context consumers 120,
`e.g., via network 110. Context aggregator 125 may represent
`one or more computing devices. The functionality associated
`with context aggregator 125 will be described in more detail
`below.
`0018. The number of networks 110, users 115, context
`consumers 120, and context aggregators 125 illustrated in
`FIG. 1 is provided for simplicity. In practice, there may be
`more networks 110, users 115, context consumers 120, and
`context aggregators 125.
`0019 FIG. 2 is a diagram of an exemplary computing
`device 200, such as one of devices 119, a computing device
`used to implement context consumer 120, or a computing
`device used to implement context aggregator 125. Computing
`device 200 may include a bus 210, a processor 220, a main
`
`Page 00009
`
`

`

`US 2009/0265764 A1
`
`Oct. 22, 2009
`
`memory 230, a read only memory (ROM) 240, a storage
`device 250, an input device 260, an output device 270, and a
`communication interface 280. Bus 210 may include conduc
`tors or a pathway that permit communication among the
`components of computing device 200.
`0020 Processor 220 may include a processor(s), a micro
`processor(s), or processing logic that interprets and executes
`instructions. Main memory 230 may include a random access
`memory (RAM) or another type of dynamic storage device
`that stores information and instructions for execution by pro
`cessor 220. ROM 240 may include a ROM device or another
`type of static storage device that stores static information and
`instructions for use by processor 220. Storage device 250 may
`include a magnetic and/or optical recording medium and its
`corresponding drive.
`0021. Input device 260 may include one or more mecha
`nisms that permit a user to input information to computing
`device 200. Such as a keyboard, a mouse, a pen, Voice recog
`nition and/or biometric mechanisms, etc. Output device 270
`may include one or more mechanisms that output information
`to the user, including a display, a printer, a speaker, etc.
`Communication interface 280 may include any transceiver
`like mechanism that enables computing device 200 to com
`municate with other devices and/or systems. For example,
`communication interface 280 may include mechanisms for
`communicating with another device or system via a network,
`such as network 110.
`0022. As will be described in detail below, context aggre
`gator 125 may aggregate and provide access to context infor
`mation from multiple users 115. Additionally, users 115 and
`context consumers 120 may send context information to con
`text aggregator 125 or access context information through
`context aggregator 125. Software implementing these func
`tions may be stored in a computer-readable medium, Such as
`memory 230. A computer-readable medium may be defined
`as one or more physical or logical memory devices.
`0023 The software instructions defining the operations of
`computing device 200 may be read into memory 230 from
`another computer-readable medium, Such as data storage
`device 250, or from another device via communication inter
`face 280. The software instructions contained in memory 230
`may cause processor 220 to perform processes that will be
`described later. Alternatively, hardwired circuitry or other
`logic may be used in place of, or in combination with, Soft
`ware instructions to implement processes described herein.
`Thus, embodiments described herein are not limited to any
`specific combination of hardware circuitry and software.
`0024. The context for a user, as previously mentioned,
`may be generally defined as the state of that user. Context
`information may be stored and maintained by context aggre
`gator 125. A user's current context may be defined based on
`information drawn from a number of different sources. FIG.
`3 is a diagram illustrating exemplary types of information that
`may be received and stored by context aggregator 125 to
`thereby define a user's context.
`0025 Device presence information 305 may be used to
`define a user's context. Device presence information may
`include any information automatically generated by devices
`119 that are associated with the user. As shown in FIG. 3,
`devices that may generate presence information can include
`telephone device 116, personal computer 117, or television
`set-top box 118. Other devices may also generate presence
`information.
`
`0026. One example of device presence information may
`include the current state of a device, such as whether the
`device is on or off. Many networked devices, such as portable
`phones, VoIP phones, and set-top boxes may register or oth
`erwise inform, via network 110, the service provider for the
`device when the device is turned on. For these devices, the
`presence information for the device may be automatically
`updated in context aggregator 125 as the device changes state.
`Other devices, such as personal computers, may be config
`ured to update their presence information with context aggre
`gator 125. For example, an instant messaging application or
`other application installed on personal computer 117 may
`apprise context aggregator 125 of whether user 115 is cur
`rently using the computer.
`0027. Another example of automatically generated pres
`ence information may include the location of the device.
`Telephone device 116, for instance, may include a global
`positioning system (GPS) unit that allows the device to deter
`mine its geographical location. Telephone device 116 may
`transmit this information to context aggregator 125 as part of
`its presence information.
`0028. User generated status information 310 may also be
`used to define a user's context. User generated Status infor
`mation 310 may include information generated by the user
`that relates to the user's status or state. User 115 may submit
`user generated Status information 310 to context aggregator
`125 using devices such as devices 119. For example, tele
`phone device 116 may include an application that allows the
`user to send a text message to context aggregator 125 that
`indicates the user's currentactivity. For instance, the user may
`indicate that his current activity is “sleeping.” “in a meeting.”
`“working out.” “cooking,” “do-not-disturb’, etc. As another
`example, the user may enter current status information at a
`web site provided by context aggregator 125, through inter
`action with set-top box 118, or via an application executing at
`personal computer 117. The activities that the user can choose
`from may be customized by the user or pre-set by the provider
`of context aggregator 125.
`0029 Labeled location information 315 may also be used
`to define a user's context. Labeled location information 315
`may include labels that symbolically define the location of the
`user. Such labels may include “work.” “home,” “school.” etc.
`that provide an indication of the user's location. Although
`labeled location information 315 is shown as a separate ele
`ment in FIG. 3, labeled location information 315 may be
`automatically generated by devices 119 as presence informa
`tion (e.g., GPS data sent to context aggregator 125 by the
`devices) or as information that is part of user generated Status
`information 310. For example, the user may explicitly send a
`message to context aggregator 125 indicating that his location
`is “work.
`0030 Labeled location information 315 may also be gen
`erated using other techniques. For example, location labels
`may be generated based on user-defined rules relating to
`device presence information. For instance, the user may indi
`cate that whenever he is logged into his home computer, his
`location label should be set to “home.” As another example,
`context aggregator 125 may infer a label appropriate for the
`user's current location based on geographical location infor
`mation. For example, the geographic coordinates of the user's
`home (i.e., latitude and longitude coordinates) may be used to
`infer that the user is at home whenever telephone device 116
`indicates it is at a geographic location corresponding to the
`coordinates of the user's home. As yet another example,
`
`Page 00010
`
`

`

`US 2009/0265764 A1
`
`Oct. 22, 2009
`
`labeled location information 315 may be set based on infor
`mation taken from calendar information shared by the user. It
`can be appreciated that these examples of the generation of
`labeled location information are exemplary only and that
`numerous other rules or techniques could be used by context
`aggregator 125 to generate labeled location information 315.
`0031
`Recent activities information 320 may also be col
`lected and used by context aggregator 125 to define a user's
`context. Recent activity information 320 may include infor
`mation relating to the user's activities. For instance, recent
`telephone numbers called, web searches, and stock quote
`requests may all be relevant to the user's current context.
`0032 Home subscriber service (HSS) 325 may also be
`used as a source of information for context aggregator 125. As
`is known in the art, HSS may refer to systems used to support
`IP Multimedia Subsystems (IMS). HSS325 may contain user
`and service profiles, potentially including the geographical
`location of a user, that are used to Support the handling of calls
`and sessions. The user profiles and user location information
`that is known by HSS 325 may be transmitted to or otherwise
`used by context aggregator 125.
`0033 Context aggregator 125 may use additional infor
`mation when maintaining a user's context. As shown in FIG.
`3, this information may include device capabilities 330, con
`tact information 335, and general preferences information
`340. Information 330, 335, and 340 may be obtained in a
`variety of ways, Such as by the user explicitly setting this
`information via a graphical interface (e.g., a web interface).
`0034 Device capabilities 330 may include information
`relating to the devices, such as devices 119, that are typically
`used by the user. Device capabilities 330 may be provided by
`the user or known in advance by context aggregator 125. Such
`as if context aggregator provided one or more of devices 119
`to a user as part of a service contract. Device capabilities may
`also be provided by the device itself. Device capabilities 330
`may generally include any information describing devices
`119 that may be relevant to context aggregator 125. For
`example, device capabilities information 330 may include
`features of a device (e.g., whether a mobile phone includes
`GPS capability, bandwidth of the device, video capability of
`the device, etc.), applications installed on a device (e.g., a
`personal computer may be running an instant messaging
`application designed to work with context aggregator 125),
`and a list of devices 119 that are possessed by the user.
`0035 Contact information 335 may include information
`relating to contact or calendar data of the user. For example,
`context aggregator 125 may maintain a copy of the user's
`calendar(s), address book(s), or instant messaging “buddy' or
`“friends' lists. Such information may be useful in inferring
`the user's current state or in determining which other users are
`allowed to access a user's context.
`0036 General preferences 340 may include any informa
`tion relating to user preferences. For example, Stocks the user
`is interested in watching, hotels the userprefers to stay at, and
`restaurants the user prefers may all be stored as part of pref
`erences information 340.
`0037. As previously discussed, context aggregator 125
`may gather and maintain information relating to a user's
`context in a number of ways. For example, information relat
`ing to a user's context may be explicitly Submitted by a user,
`gathered automatically from user devices 119, inferred from
`user activity and/or predefined rules, or gathered from exter
`
`nal information sources. At any particular point in time, the
`most recent set of gathered information for a user may define
`the user's "current context.
`0038 FIG. 4 is a diagram of an exemplary system 400 for
`using context information collected by context aggregator
`125. System 400 is similar to system 100, except that in
`system 400, two additional components are shown: Security
`preferences storage 410 and security and authentication
`engine 415. Security preferences storage 410 and security and
`authentication engine 415 may function to limit access to
`context aggregator 125 by content consumer 120. Limiting
`access to a user's context to authorized entities can be impor
`tant to protect the user's privacy and personal information.
`0039. Security preferences storage 410 may include a
`database or other storage structure that stores information
`relating to who or what may access a user's context informa
`tion. Security preferences storage 410 may, for example, store
`an “allow list” that only permits certain people or certain
`businesses to access the user's context information. Addition
`ally, differententities on the allow list may be given a different
`Scope of access rights. For example, a user may configure
`security preferences storage 410 so that family members are
`given full access to the user's context while friends are only
`allowed to access certain fields of the user's context.
`0040. The security preferences information maintained in
`storage 410 may be set or configured by the user in a number
`of ways. For example, the operator of context aggregator 125
`may permit a user to change their security information via a
`web interface or through another interface, such as one pro
`vided through devices 119.
`0041) Security and authentication engine 415 may handle,
`based on user security preferences from security preferences
`storage 410, securing of the user context information in con
`text aggregator 125. In other words, security and authentica
`tion engine 415 may receive requests for user content from
`context consumers 120 and determine whether the request
`should be fulfilled.
`0042 FIG. 5 is a flow chart illustrating exemplary opera
`tions for accessing and using a user's context by a context
`COSU.
`0043. To begin, assume context consumer 120 would like
`to access a user's context. Context consumer 120 may be, for
`example, an acquaintance of the user, the employer of the
`user, or an entity that has a business relationship with the user.
`Context consumer 120 may request one or more portions of
`context from context aggregator 125 (block 510). For
`example, a friend may request the user's current location and
`activity; a business, such as a pizza delivery service, may
`request which toppings the user prefers on a pizza; etc.
`0044. In response to the request, security and authentica
`tion engine 415 may determine whether the requesting con
`text consumer 120 has authority to make the request (block
`515). This determination may include authenticating the
`requesting entity and then comparing the requesting entity to
`the security settings, as stored in security preferences storage
`410.
`0045. If the request is accepted (block 520), the requested
`context may be sent to the context consumer (block 525).
`Otherwise, the request may be denied (block 530).
`0046. To further illustrate applications of the operations
`illustrated in FIG. 5, a number of examples of the use of user
`context will now be given.
`0047 Consider a customer that wishes to order pizza from
`a pizza deliver restaurant. The customer and restaurant may
`
`Page 00011
`
`

`

`US 2009/0265764 A1
`
`Oct. 22, 2009
`
`use the consumer's context to improve the pizza delivery
`experience. For example, instead of calling the restaurant,
`providing the consumer's name, delivery address, and pizza
`order, the customer may simply call or text message the
`restaurant with an order such as “bring me my usual.” The call
`or message may also include information, such as the cus
`tomer's phone number, that allows the restaurant to identify
`the customer.
`0048. The restaurant may query context aggregator 125 to
`get the information needed to satisfy the customer's order. For
`instance, the customer may have configured general prefer
`ences information 340 in contextaggregator 125 to include an
`entry listing the toppings for the customer’s “usual” or favor
`ite pizza toppings. Further, context aggregator 125 may also
`provide the restaurant with the customer's current location,
`thus allowing the restaurant to deliver the pizza to the address
`at which the customer is currently residing.
`0049. The restaurant’s query to context aggregator 125
`may be subject to security restrictions imposed by security
`and authentication engine 415. For instance, the customer
`may have previously indicated that the particular pizza res
`taurant is to be given access to information of the user's
`context relating to the customer's current location and pizza
`topping preferences. Alternatively, the customer may have
`indicated that any restaurant in an approved network of res
`taurants should be given access to the customer's current
`location and food preferences. Requests for context informa
`tion outside the scope of the customer's security settings may
`be rejected.
`0050. As another example of the use of user context, con
`sider the sharing of context with friends. Assume people on a
`user's list of approved friends are given permission to view
`device presence information 305 and user generated status
`information 310. These friends may then be able to view, for
`example, the television show the user is currently watching,
`the communication devices available to the user, and the
`presence state of these devices. Thus, if a friend sees that the
`user's home phone is “busy, the user's mobile phone is off,
`but the user is logged into an instant messaging (IM) appli
`cation, the friend will know that the best way to reach the user
`is via IM.
`0051. The user may configure security restrictions
`imposed by security and authentication engine 415 to give the
`user's boss or business associate a different view of the user.
`For example, the user's boss may only be allowed to view
`presence information relating to the status of the user's
`mobile phone and only be allowed to view certain labeled
`location information that relates to work, such as “at my
`desk.” “in a meeting.” “traveling.” etc.
`0052. As another example of the use of user context, con
`sider the use of context by a user to capture information that
`the user may later need. For example, assume a user is view
`ing a streaming media presentation on a portable device. The
`user may need to disconnect during the middle of the presen
`tation. Later, the user may desire to resume the presentation at
`the point at which the user disconnected. In this situation, the
`user may have saved or context aggregator 125 may have
`automatically saved the user's position in the presentation,
`thus allowing the user to easily restart the presentation at the
`desired location.
`0053 As another example of the use of user context, con
`sider the use of context to adapt a communication request to
`one that is most appropriate for the user's current situation.
`For example, the user may be in a library and may conse
`
`quently set the user context to indicate “quiet.” When a friend
`attempts to initiate a multimedia communications session
`with the user, the user's context may be used to determine the
`communication channel. For instance, the telecommunica
`tion service provider for the friend's communication request
`may first consult context aggregator 125. In response, the
`telecommunication service provider may notify the friend
`that the user's current status is “quiet” and that the multimedia
`communication request cannot be completed. When the
`user's status becomes available, the telecommunication Ser
`Vice provider may automatically attempt to set up the multi
`media communication request. Alternatively, instead of
`delaying the communication request, the user's "quiet”
`device status may result in the communication request being
`automatically initiated as a “quiet” compatible communica
`tion session. For example, the user's mobile phone may be
`automatically set to ring in vibrate mode and an IM session
`may be set up between the two parties.
`0054 As yet another example of the user of user context,
`consider the use of a user's context to provide the richest
`possible delivery of multimedia content. For example, if a
`user requests content, the content provider may deliver a
`content stream that is optimized for the highest resolution
`device that is currently available to the user based on the
`user's location and based on a list of devices associated with
`the user. Further, the content delivery may be adapted in
`real-time based on the user's context. Accordingly, if a user's
`context is updated to indicate a better device is available, the
`content stream may be switched to the newly available device.
`0055. In one implementation, access to a user's security
`settings in security preferences storage 410 may be given to a
`parent or supervisor to thereby create a “parental control
`feature. Accordingly, a parent may control access to their
`child's context, including location, presence information,
`preferences, and media sessions.
`0056. In addition to providing user context to a context
`consumer, user context can be used to leverage additional
`context-dependent transaction authorization services. More
`specifically, user context may additionally be used to enhance
`an authorization procedure for certain transactions. There are
`many transactions, such as credit card charges, bank with
`drawals, and delivery restaurant orders in which one party to
`the transaction may desire or need further authentication or
`notification before proceeding with the transaction.
`0057 FIG. 6 is a diagram of an exemplary system 600 for
`using context information to enhance transaction authoriza
`tion. System 600 includes context aggregation and security
`engine 610 and context dependent authorization engine 620.
`Context aggregation and security engine 610 may function
`equivalently to context aggregator 125, security and authen
`tication engine 415, and security preferences storage 410, as
`shown in FIG. 4 and as previously discussed. In short, context
`aggregation and security engine 610 may generally function
`to aggregate and provide secure access to user context.
`0.058 Context dependent authorization engine 620 may,
`based on user context, provide context-dependent authoriza
`tion services to parties Such as context consumers 120. A
`context-dependent authorization may be implemented using
`a number of different technologies or communication ses
`sions. A number of exemplary functional elements that may
`be used in a context-dependent authorization are shown in
`FIG. 6, and, as shown, may include biometric verification
`
`Page 00012
`
`

`

`US 2009/0265764 A1
`
`Oct. 22, 2009
`
`630, password verification 635, audit information 640, user
`notification 645, and communication session establishment
`650.
`0059 Biometric verification 630 may include any combi
`nation of hardware or software used to provide biometric
`verification. Biometric verification may be based on biomet
`ric verification technologies such as Voice verification, face
`recognition, eye (e.g., retinal or iris) recognition, or finger
`print recognition. Some biometric verification technologies,
`Such as fingerprint recognition, may require specialized hard
`ware. Whether a particular user, based on their current loca
`tion, has access to such hardware may be stored and tracked as
`part of the user's context.
`0060 Password verification 635 may include any combi
`nation of hardware or software used to provide verification
`based on a user ente