WO 2011/119407
`
`PCT/US2011/028825
`
`architecture 900, however, is additionally applicable in situations where the user 102 mayinitiate
`
`a transaction at one place and point in time and then later complete the transaction upon arrival at
`
`the merchant 106.
`
`[0095]
`
`The user may initiate a transaction 904 through interaction with device 902.
`
`Device 902 may be the mobile device 104 or it may be a different computing or communication
`
`device such as a telephone, a desktop computer, laptop computer, thin client, set top box, game
`
`console, or the like. Device 902 may be connected directly or indirectly to a network 906. The
`
`network 906 may be the same network as network 116 illustrated in Fig. 1. A user identifier 208
`
`is associated with the transaction 904. The useridentifier 208 enables the merchant 106 to match
`
`transaction 904 with the correct user.
`
`Initiating that transaction may place that transaction in a
`
`transaction queue of the merchant 106.
`
`In some implementations this transaction queue may be
`
`maintained on the merchant server 108 illustrated in Fig. 1. The transaction queue could contain
`
`such things as a pre-order for a cup of coffee (to be delivered when the user arrives at the coffee
`
`shop) or a hotel reservation (to be confirmed with the user checks in to the hotel). Transactions
`
`may remain in the transaction queue for some period of time (e.g., minutes or days), but
`
`instantancous, or nearly instantancous, implementations are also possible.
`
`[0096]
`
`The user 102 later arrives at the merchant 106 with his or her mobile device 104.
`
`Recall that the mobile device 104 may also be associated with the user identifier 208 as
`
`illustrated in Fig. 2.
`
`In some implementations, a satellite 112 provides the mobile device 104
`
`with a geolocation that can be compared with or matched to a geolocation of the merchant 106.
`
`When at
`
`the merchant’s location the mobile device 104 and a computer system of the
`
`merchant 106 can communicate directly over a communication path 908 or indirectly via the
`
`network 906. The merchant 106 may access the network 906 to retrieve the transaction 904
`
`when the mobile device 104 associated with user identifier 208 is present at the merchant
`
`location.
`
`Information provided by the merchant 106 to the mobile device 104 may be used by
`
`the user 102 to complete the transaction 904.
`
`In some implementations, completing the
`
`transaction may involve the user being charged and subsequently gaining access to a secure
`
`location 910. The secure location 910 may comprise a hotel room, an airplane, a person’s home,
`
`a workplace, inside the borders of a country, or any other geolocation to which entry is regulated.
`
`Entry to the secure location 910 may be provided by a code personalized to the user 102. The
`
`personalized code may be stored in the user information 122. For example, the code may be a
`
`series of numbersandletters that the user 102 wishes to re-use whenever access requires entry of
`
`a code on a key pad or such. As a further example, the code may be basedat least in part on
`
`biometric data from the user 102. Biometric data is discussed below in more detail in relation to
`
`23
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`Fig. 14.
`
`In some implementations, this code may be hidden from the merchant 106 so that the
`
`merchant 106 only receives the user identifier 208, but cannot access the user’s personalized
`
`code.
`
`[0097]
`
`For example, a user may make a hotel reservation from his home computer. The
`
`reservation along with his user identifier is transmitted across a communication network to the
`
`computer systemsof the hotel. Sometime(e.g., days) later when the userarrives at the hotel and
`
`his mobile device is detect at the geolocation of the hotel, the user identifier contained in his
`
`mobile device is used to retrieve the reservation. After confirming payment, such as by a credit
`
`card also linked to his useridentifier, the hotel sends a text message or other communication to
`
`his mobile device that contains his room number. This may happen while he is walking through
`
`the lobby to the elevators without ever stopping at the front desk. Onceat his room, the presence
`
`of his mobile device outside the door may be detected by a wireless communication network in
`
`the hotel and the door may be automatically unlocked. Room keys may be provided inside the
`
`hotel room.
`
`In implementations in which the useridentifier is also linked to a userprofile (and
`
`the user has elected to share his user profile with the hotel), the user profile may be used to
`
`customize his gucst expcricnee at the hotcl by, for cxample, instructing the hotcl staff to placc
`
`his favor type chocolate on the pillow. Similar to the purchase of goods, the system can provide
`
`a friction-free experience for the purchase of services.
`
`[0098]
`
`As a further example, the architecture and systems described herein can be applied to
`
`immigration and border security.
`
`In this context, the transaction 904 may be the granting of
`
`entry to a country.
`
`Initially, the person wishing to travel to a different country may enter user
`
`information about the potential trip into a computing device 902 and associate that information
`
`with the transaction 904 as well as a user identifier 208 for the potential traveler.
`
`In some
`
`implementations, a passport number could be used as the user identifier 208. Upon arrival at
`
`immigration in the destination country, mobile device 104 carried by the traveler may signal to
`
`the immigration authority that this person has arrived and is requesting entry.
`
`In some
`
`implementations, the user identifier 208 may be associated with a mobile device 104, such as a
`
`mobile phone, that the user 102 is instructed to bring when they travel to the other country.
`
`In
`
`other implementations, the mobile device 104 may be a miniaturized electronic device that is
`
`attached to the user’s passport as an entry visa.
`
`In yet other implementations, the passport itself
`
`may comprise the mobile device 104 and an RFID in the passport may be the user identifier 208.
`
`This system may reduce the friction associated with processing people entering a country by
`
`allowing the immigration transaction to be partially completed in advance and by automatically
`
`identifying the people and the corresponding information whenthey are located at an entry point.
`
`24
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`[0099]
`
`‘Fig. 10 illustrates a process 1000 for completing a transaction between a user and a
`
`merchant when the user arrives at a geolocation of the merchant. At operation 1002, a
`
`transaction is initiated between the user and the merchant.
`
`Initiation of the transaction may be
`
`separated in space and in time from completion of the transaction; however, such separation is
`
`not necessary.
`
`[0100] Upon arrival at the merchant’s geolocation,
`
`the mobile device is detected at the
`
`merchant in operation 1004. The detection may be direct such as implementations in which a
`
`signal broadcast by the mobile device is picked up by a receiver at the merchant. Alternatively,
`
`the detection by be indirect or inferred by correlating a current geolocation of the mobile device
`
`with a geolocation of the merchant. At operation 1006, the presence of the user is communicated
`
`to the merchant. The communication may trigger the merchant to access the transaction.
`
`[0101] User information may be provided to the merchant at operation 1008. The user
`
`information may be provided dircctly from the memory of the mobile device or a user identificr
`
`associated with the mobile device may be used to retrieve user information from a network or
`
`other remote data source. As discussed earlier, the user information may include payment
`
`information, a user profile, and the like. The user profile may include user preferences that the
`
`merchant uses to modify the transaction. User preferences may include such things as window
`
`or aisle scat on an airplanc, smoking or non-smoking rooms in a hotel, and the like. Next, at
`
`operation 1010, the transaction between the user and the merchant is completed. Completion
`
`may include collecting a payment, confirming a reservation, making a purchase,etc.
`
`[0102]
`
`Following completion of the transaction, at operation 1012, the merchant may send a
`
`message to the mobile device confirming completion of the transaction. The message may be a
`
`receipt for the transaction, or in some implementations, it may be a code or other information
`
`that is necessary to access a secure location such as a hotel room or an airplane. For example,
`
`the message may comprise a boarding pass barcode that can be displayed on a screen of the
`
`mobile device and scanned by conventional equipment when the user boards an airplane.
`
`In
`
`other implementations,
`
`the message may be an electronic token that provides additional
`
`functionality to the mobile device. For example,
`
`the electronic token may allow the mobile
`
`device to broadcast a signal (e.g., analogous to a garage-door opener) that may be used to open a
`
`door and gain access to the secure location.
`
`Illustrative Parent and Child Devices
`
`[0103]
`
`Fig. 11 showsanillustrative architecture 1100 in which a two devices having a parent-
`
`child relationship interact to complete a transaction with a merchant. While this example
`25
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`describes the techniques in the parent/child context, these techniques may similarly apply for
`
`employer/employee contexts, teacher/student contexts, adult child/senior parent, and/or any other
`
`context. This relationship may be generally thought of as a master-slave relationship between
`
`computing devices. The child 1102 is a user of a child device 1104. The child device 1104 may
`
`be associated with a given user(i.e., the child 1102) based on a login or authentication of the
`
`user on the child device 1104.
`
`In some implementations, the login may be tied to the user
`
`information 122 of the child 1104 thus providing the same features, and parentally imposed
`
`limitations, on any device that the child 1102 uses. The child device 1104 may be a mobile
`
`device similar to the device 104 illustrated in Fig. 1.
`
`In some implementations,
`
`the child
`
`device 1104 may be designed with a simple user interface, limited features, large buttons, bright
`
`colors, and/or otherwise adapted for a younger user. A parent 1106 interacts with a parent
`
`device 1108. The parent 1106 and the parent device 1108 may be similar to the user 102 and the
`
`mobile device 104 illustrated in Fig. 1. However, the parent device 1108 may be a non-mobile
`
`device, such as a desktop computer. Although designated herein as a “parent” and a “child” the
`
`two users may have a relationship other than a parent-child relationship, as discussed above.
`
`However, as will be described in more detail below the parent device 1108 may have limited
`
`control and/or supervision functionality with respect to the child device 1104. This hierarchical
`
`relationship between the two devices could be implemented in an employment context as well as
`
`a family context.
`
`[0104]
`
`The satellite 112 and the radio antenna 114 are the same as shown in Fig. 1. The child
`
`devicc 1104 is aware of its gcolocation, or another entity is able to track this gcolocation. The
`
`geolocation information may be provided by the satellite 112, the radio antenna 114, and/or
`
`alternative sources as discussed above. The child device 1104 and the parent device 1108 share
`
`at least one communicative connection.
`
`In some implementations, such as mobile phones, the
`
`two devices may communicate via the radio antenna 114.
`
`In the same or different
`
`implementations, the two devices may have a connection to a network 1110 such as the Internet.
`
`The network 1110 may be the same as the network 116 shown in Fig.
`
`1.
`
`In other
`
`implementations, it may be a different network such as a subset of the network 116 restricted to
`
`only content and connections that are deemed suitable for a child.
`
`[0105]
`
`The merchant 106 may also have a connection to the network 1110 over which
`
`information may be shared with either the child device 1104 or the parent device 1108. The
`
`child device 1104 may communicate with the merchant 106 across the network 1110 and/or
`
`communicate directly with the merchant 106 over a direct communication link 1112. The direct
`
`26
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`communication link 1112 may be similar to the direct communications link 120 illustrated in
`
`Fig. 1.
`
`[0106]
`
`Fig. 12 illustrates process 1200 for completing a transaction between a child device
`
`and a merchant and transmitting an indication of the transaction to the parent device. At
`
`operation 1202, a geolocation of the child device is determined. The geolocation of the child
`
`device may be determined in reference to the satellite 112 or radio antenna 114 shownin Fig. 10.
`
`Next, at operation 1204 the geolocation of the child device is correlated to a merchant.
`
`Correlation may be accomplished through any of the mechanisms discussed above such as, for
`
`example, comparing the geolocation of the child device to a map of merchant locations. At
`
`operation 1206, a transaction is initiated between the user of the child device and the merchant.
`
`The transaction may be initiated automatically in some implementations, or
`
`in other
`
`implementations the transaction may involve one or more inputs from the user of the child
`
`device beforeinitiation.
`
`[0107] An indication of the transaction is transmitted to a parent device at operation 1208.
`
`The indication may inform the user of the parent device about the details of the transaction
`
`between the child device and the merchant.
`
`In some implementations, the indication may be
`
`provided in real-time to the parent device. A record or log of transactions of the child device
`
`may be maintained for access by the user of the parent device. The log may store any
`
`combination of transactions initiated, completed, and/or denied.
`
`In some implementations the
`
`log may be similar to the transaction record 406 illustrated in Fig. 4. The log may be stored in
`
`association with the user identifier of either the parent or the child. Depending on the level of
`
`control for parent wishes to cxcrcisc over transactions made by child, parental authorization from
`
`the parent device to the child device may be necessary to complete the transaction. A
`
`requirement for parental authorization may depend on the nature of a transaction. For example, a
`
`parent may configure the system to allow the child to purchase books without parental
`
`authorization, but to require parental authorization for purchases of candy. Additionally, or
`
`alternatively, the requirement for parental authorization may depend of a value of the transaction
`
`(i.e., dollar value), a geolocation of the child device, and/or other
`
`factors.
`
`In one
`
`implementation, the parent may provide the child with a budget (in terms of money or other
`
`metric) and when the child is under budget authorization may not be required, but authorization
`
`may be required for transactions that exceed the budget.
`
`In situations for which parental
`
`authorization is required, the indication may include a request that the parent respond by either
`
`authorizing or denying the transaction.
`
`27
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`[0108] At decision point 1210,
`
`is determined whether or not parental authorization is
`
`required. When parental authorization is not required, process 1200 proceeds along the “no”
`
`path to operation 1212. At operation 1212, the transaction between the child device and the
`
`merchant is completed.
`
`In some implementations, the transaction may be completed based in
`
`part upon a user profile associated with the child.
`
`Furthermore,
`
`in the same or different
`
`implementations, a user profile associated with the parent may also affect how the transaction is
`
`completed. For example, if the child has indicated that he or she wishes to automatically a
`
`purchase particular candy upon entering a candy store, that portion of the child’s user profile
`
`may be used to complete a purchase of that type of candy. The userprofile associated with the
`
`parent may be used for, among other things, a source of payment information to complete the
`
`candy purchase.
`
`[0109] When parental authorization is required, the process 1200 proceeds from decision
`
`point 1210 along the “yes” path to decision point 1214. At decision point 1214, it is determined
`
`whether or not the parental authorization has been granted. When parental authorization is
`
`granted, for example by the parent interacting with the parent device, process 1200 proceeds
`
`along the “yes” path to operation 1212 and the transaction is completed. However, when
`
`authorization is denied the process 1200 proceeds along the “no”path to operation 1216 and the
`
`transaction is terminated. Termination of the transaction may result in a message being sent to
`
`the child device and/or the merchant.
`
`Security for Mobile Devices
`
`[0110]
`
`Fig. 13 shows an illustrative map 1300 of temporal-geo-locations of a mobile device
`
`during a workday of a user of the mobile device. By creating a map of where the device is
`
`typically located and when the device is at those locations, variance from those patterns can
`
`serve as a trigger to suggest that the device may have been stolen or misplaced and initiate a
`
`security event such as shutting down the device or requiring a password to complete purchases
`
`with the device. This type of security feature may be implemented automatically by the device
`
`itself before the user is even aware that a problem exists. The mobile device may include a
`
`security module 214 as illustrated in Fig. 2 for implementing these security features.
`
`[0111]
`
`The user may begin his workday at his home which hasa fixed geolocation. Typically
`
`he—specifically his mobile device—may be at home from approximately 6:00 PM_ until
`
`approximately 7:00 AM and this comprises a first temporal-geo-location 1302 for his workday.
`
`Commuting from home to work may involve driving along the road to work between
`
`approximately 7:00 AM to approximately 7:30 AM. His automobile may include an additional
`28
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`device, such as an on-board navigation systern, that is also associated with his user identifier
`
`208, and thus, also contributes to building a map of temporal-geo-locations for the user. He may
`
`use the same route every day in commuting to work so the systems of the user device may
`
`recognize this temporal-geo-location 1304 even thoughit is not a single fixed position but rather
`
`a series of geolocations and a series of time points. After arriving downtown, the user’s day may
`
`include another temporal-geo-location 1308 that comprises his walk from a parking area to his
`
`office between approximately 7:30 AM and approximately 7:45 AM. While at the office the
`
`user and the user device may move around within the office but remain at the geolocation of the
`
`office from about 7:45 AM to about 12:00PM. This is another temporal-geo-location 1310.
`
`[0112] Up until
`
`lunchtime this user’s typical weekday schedule may befairly consistent.
`
`However, during lunch he may move to a variety of geolocations associated with various
`
`restaurants shown here as Restaurant A, Restaurant B, and Restaurant C.
`
`The user may
`
`generally
`
`be
`
`inside
`
`one
`
`of
`
`the
`
`restaurants
`
`from approximately
`
`12:10
`
`PM to
`
`approximately 12:50 PM. This temporal-geo-location 1312 may have a well-defined time but a
`
`loosely defined location. For example, any geolocation within a 10 minute walk of the office
`
`may be decmed part of this user’s typical weckday movements during the lunch hour. After
`
`lunch the user may return to the office. The office is at the same geolocation it was during the
`
`moring, but the time period is different so being in the office from about 1:00 PM until about
`
`5:00 PM creates yet another temporal-geo-location 1314 in the map ofthis user’s workday.
`
`[0113]
`
`The user may have more than one route he takes home from work. During the winter,
`
`for example, the user may take a more direct road home leaving office at about 5:10 PM and
`
`arriving home at about 6:00 PM. This creates a temporal-gco-location 1314 across a range of
`
`space and time similar to the temporal-geo-location 1304 representing the road to work.
`
`In the
`
`summer, this user may take the scenic route home. The road home in summer may have a
`
`different geolocation in all or in part from the road homein winter. The road home in summer
`
`may also take longer so that while the user leaves the office at 5:10 PM he does not arrive home
`
`until 6:10 PM. This creates an alternate temporal-geo-location 1316 to the temporal-geo-
`
`location 1314 representing the road home in winter. Depending on the security settings of the
`
`mobile device, the mobile device may not trigger a security event no matter which route the user
`
`takes home even if he uses the winter road during the middle of summer. Alternatively, if
`
`stricter security settings are applied then taking the summerroad during midwinter may trigger
`
`security event, but during mid-March the mobile device may tolerate the user taking either road
`
`without triggering a security event.
`
`29
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`[0114]
`
`By recording times, dates, and geolocations as the mobile device is used and moved it
`
`is possible for a security system, for example security module 214, to learn what are typical
`
`movements through space and time. This “geolocation signature” of the user can be stored in a
`
`data file as a series of time-location data points. Someorall of these data points may be layered
`
`together to create a multidimensional map containing past geolocation and time information for
`
`the mobile device.
`
`[0115]
`
`Fig. 14 illustrates process 1400 for securing a mobile device based on variance from a
`
`map of temporal-geo-locations. At operation 1402, a geolocation of the mobile device is
`
`detected. At operation 1404, a time point when the geolocation is detected is recorded. Next at
`
`operation 1406,
`
`the geolocation is stored in association with the time point at which the
`
`geolocation was detected. This combination of geolocation and a time point is a temporal-geo-
`
`location. Temporal-geo-location data points may be recorded with varying levels of granularity
`
`based on things such as a memory capacity of the mobile device 104, velocity at which the
`
`mobile device 104is traveling, and the like. Granularity of recording temporal-geo-location data
`
`points may occur with a regular frequency such as every 30 seconds or every 10 minutes.
`
`In
`
`some implementations this data may be stored in the memory 204 of the mobile device 104
`
`shown in Fig. 2. The temporal-geo-location data may be stored, among other places, as user
`
`information 210 or in the security module 214 also shown abovein Fig.2.
`
`[0116] A mapis created from movements of the mobile device over time based on a plurality
`
`of the temporal-geo-locations at operation 1408.
`
`As
`
`indicated above,
`
`this may be a
`
`multidimensional map comprising a latitude dimension,
`
`a longitude dimension,
`
`a time
`
`dimension, and a date dimension. Including additional and/or alternate dimensions in the map is
`
`also possible. This map may become morc detailed, and potentially more uscful, as a greater
`
`amount of data is accumulated. For example, when a userinitially purchases a mobile device it
`
`may not be possible for the mobile device to detect whether or not it has moved away from the
`
`user’s “regular” temporal-geo map. If the user knowsthat he or she will be moving in ways that
`
`are atypical(i.e., “going off the map”), the user may manually turn off the recording of temporal-
`
`geo-location data points. This may prevent inclusion of data into the map that would degrade
`
`rather than improve the accuracy of the map.
`
`[0117]
`
`In order to detect whether or not the mobile device has been stolen, misplaced, or is
`
`otherwise in the wrong place at the wrong time, decision point 1410 may compare the current
`
`temporal-geo-location of the mobile device with the map and determine whether or not the
`
`current temporal-geo-location varies more than a threshold amount from the map.
`
`In some
`
`implementations, this comparison may be achieved at least in part through the use of artificial
`30
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`intelligence, heuristics, or fuzzy logic.
`
`In some implementations,
`
`the threshold may be
`
`configurable by the user of the mobile device. The analysis may also draw upon calendar or
`
`scheduling information of the user to see if the user has a scheduledtrip that varies from his
`
`regular map. The calendar information may be included in the user information 210 and
`
`provided to the security module 214.
`
`[0118] When an amountofvarianceis less than the threshold amount, process 1400 proceeds
`
`along the “no” path and returns to decision point 1410 to once again query whether or not the
`
`mobile device has varied too far from the map. This loop may be repeated continuously,
`
`periodically, or randomly. The frequency of repeating this loop may be based in part upon
`
`processor power of the mobile device 104, a velocity at which the mobile device 104 is moving,
`
`and/or other factors.
`
`For example,
`
`the frequency of performing the analysis at decision
`
`point 1410 may be lower when the mobile device 104 is moving at a walking pace and the
`
`frequency maybe higher when the mobile device 104 is movingat a highway speed (.e.g., while
`
`in a car).
`
`[0119]
`
`The threshold amount may also be based at least in part on the presence of other
`
`mobile devices in the same geolocation or near to the mobile device. For example, a user may
`
`vary from his or her established map during a vacation. However, during the vacation the user
`
`may travel with his or her family members who may have their own mobile devices.
`
`In one
`
`implementation, the mobile devices of the family members(or, as a further example, coworkers)
`
`may be associated with each other. One type of association is the parent-child relationship
`
`illustrated in Fig. 8 above. The presence of these other mobile devices may be usedto adjust the
`
`threshold. The absence of other devices may also be used to adjust the threshold.
`
`If, for
`
`example, the mobile device is rarely found in a particular geolocation unless other mobile
`
`devices are nearby, then the absence of those devices may be a variance from the user’s map.
`
`For example, the mobile device associated with a parent may occasionally be located at a soccer
`
`field on evenings during whicha child is playing soccer. However, on those evenings the child’s
`
`mobile device is also at the soccerfield.
`
`If, for example, the user forgot her mobile device at the
`
`soccer field a security event might be triggered once the child’s mobile device leaves the
`
`geolocation of the soccer field. Presence or absence of other mobile devices may comprise an
`
`additional dimension of the temporal-geo-location map.
`
`[0120]
`
`Returning to process 1400, when the current temporal-geo-location varies more than a
`
`threshold amount, process 1400 proceeds along the “yes” path to decision point 1412. At
`
`decision point 1412 the threshold may be adjusted based on the presence of other mobile devices
`
`in the same geolocation as the mobile device. When the threshold is adjusted, process 1400
`
`31
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`proceeds along the “yes” path and returns to decision point 1410 to reevaluate based on the
`
`adjusted threshold. When the threshold amount of variance is not adjusted, process 1400
`
`proceeds along the “no” path to operation 1414 and initiates a security event. The security event
`
`may comprise shutting down the mobile device,
`
`initiating an automatic phone call or text
`
`message to another device that includes the current location of the mobile device, requiring input
`
`of a password before the mobile device can be used, and the like. The user 102 may manually
`
`turn off the security eventsif, for example, the user 102 is travelling to a newplace (or travelling
`
`at a newtime) and wishesto avoid “false positive” security events.
`
`[0121]
`
`Fig.
`
`15 illustrates process 1500 for securing a device based on biometric data.
`
`Providing security based at
`
`least
`
`in part on biometric data can minimize opportunities for
`
`someone other than a legitimate user of a mobile device to misuse the mobile device by, for
`
`example, making unauthorized transactions with merchants.
`
`In order to balance between
`
`providing the zero-interaction transaction experience and validating the user’s identity, biometric
`
`data may besolicited periodically such as once per hour or once per day (or at any periodic or
`
`random time) in order to continue using the zero-interaction transaction feature. Alternatively, in
`
`implementations in which the uscr makes transactions with a single intcraction, cntcring
`
`biometric data may comprise that single interaction.
`
`[0122] At operation 1502, biometric data is received from a sensor of the mobile device.
`
`Many mobile devices, such as the mobile device 104 illustrated in Fig. 2, are equipped with input
`
`devices that may be used for multiple purposes including receiving biometric data. For example,
`
`the mobile device 104 may include a camera 222. The mobile device may also include a
`
`microphone 1504. In other implementations, the input device that collects biometric data may be
`
`used specifically for collecting biometric data such as a fingerprint scanner 1506. Other types of
`
`general purpose input devices used to collect biometric data and/or special-purpose biometric
`
`data input devices are also envisioned within the scopeofthis disclosure.
`
`[0123] Next at operation 1508, the biometric data is analyzed.
`
`In some implementations, the
`
`biometric data may be analyzed by a processor and software present on the mobile deviceitself.
`
`This implementation may allow the mobile device to offer stand-alone confirmation of a user’s
`
`identity without a need to access
`
`a network or other computing device.
`
`In other
`
`implementations, the biometric data may be sent from the mobile device to another computing
`
`device for analysis. This implementation may allow more sophisticated and computationally
`
`intensive techniques for analyzing biometric data than could be readily implemented on a mobile
`
`and potentially low-power device. Analysis of the biometric data may convert analog input into
`
`digital data or convert a complex sct of data such as a fingerprint into a relatively simple string
`
`32
`
`

`

`WO 2011/119407
`
`PCT/US2011/028825
`
`of data like a hash code. The analysis of the biometric data may be matchedto the type of data
`
`received. For example, if the camera 222 is used to collect biometric data by taking a picture of
`
`a person’s face, that picture may be analyzed using facial recognition techniques. Alternatively,
`
`if the microphone 1504 is used to record a sample of a voice, then that data may be analyzed by
`
`using voice recognition techniques. For added levels of security, multiple types of biometric
`
`data may be used together such as, for example, taking a picture of a person’s face and recording
`
`that person’s voice then analyzing both sets of biometric data.
`
`[0124] At decision point 1510, a determination is made as to whetherthe analysis of the input
`
`of biometric data matches stored biometric data associated with the mobile device. For example,
`
`the hash code generated from a fingerprint scan could be compared to a stored hash code that the
`
`user entered while she was setting up the mobile device.
`
`In some implementations, the stored
`
`biometric data which is used for comparison is stored locally on the mobile device. The
`
`biometric data may be stored, for example, as part of the user information 210 shownin Fig 2.
`
`Again,
`
`this may allow the mobile device to provide stand-alone analysis.
`
`In other
`
`implementations, the stored biometric data may be stored remote from the mobile device, for
`
`example, as a part of the uscr profile 404 illustrated in Fig. 4. Storing the biometric data
`
`remotely may conserve memory space on the mobile device and may provide greater security by
`
`preventing an unauthorized person from extracting biometric data from a lost or stolen mobile
`
`device.
`
`[0125] When the analysis of the biometric data matches
`
`the stored biometric data,
`
`process 1500 proceeds along the “yes” path and grants access to a functionality of the mobile
`
`device at opcration 1512. The functionality may comprise any type of opcration feature, data,
`
`and the like available on or implemented by the mobile device. For example, the ability to
`
`initiate and complete a transaction with a merchant is one type of functionality. The ability to
`
`make phonecalls is a type of functionality on mobile telephone devices. As