The present invention relates generally to wireless communications, and more particularly, a method and system for anonymity and incentives in user-assisted services.
Mobile devices have seen enormous growth in the recent years. The number of mobile connections has crossed the 4 billion mark in February 2009, and is expected to cross 6 billion by 2013. It is envisioned that this ubiquity of mobile devices will soon enable a rapid growth of a new class of location-specific real-time services. In these services, a user U at a location B is interested in current information about location A. At the same time, there are users at location A that can potentially provide the necessary information to U. Examples of such location-specific real-time information include traffic conditions, parking availability in busy locations, population density in a mall, live videos of an event such as a football game, radio spectrum availability (such as in opportunistic cognitive radio networks) and radio resource parameters (such as best base station to handoff, transmit power and bit rate) for efficient communication, etc. In effect, such real-time applications can be enabled easily by having user devices upload location-specific information as opposed to using dedicated sensor infrastructure.
To sustain a service under the above model, where users are continuously willing to provide real-time information at different locations, a service provider has to encompass three features. 1) Similar to payments for receiving continued updates from a service, users need incentives to be continuously engaged with the service for uploading even when they have no need for using the service. 2) Users desire anonymity while providing information mainly to ensure that the knowledge of presence of the particular user at a particular location, or the information itself sent by a user (such as speed above the speed-limit of a road) is not used against him. 3) The service infrastructure has to validate the location specific information received from each user at a location, and give incentives according to the validity of the information, i.e., how well a user's updates conform to other users' updates. It appears that the two features-anonymity and incentives are conflicting; while information can be anonymized when the user uploads, it makes providing incentives hard. Even the use of pseudonyms have limitations in that when the incentives are encashed, the user has to reveal his real information to receive the actual reward (such as cash, gift cards, coupons, etc.), which can in turn be used to map back to the specific information uploaded. Hence, pseudonyms will be only useful in providing anonymity as long as they are encashed within the system.
A user-assisted mobile service is considered to have three factors: 1) A pseudo-ID for the user to conceal the actual identity, which can be used during location-specific updates and for receiving reward points. 2) The location in which the user herself is present. 3) A real ID for the user (that may include a bank account information or address information, for instance) in order to encash reward points.
There are problems with providing anonymity in a mobile services environment. First, a mapping between pseudo-ID and real-ID will reveal the identity of the user, which can be used to map the updates to the specific real-ID. Second, a mapping of the most frequently visited location and an address information database (such as yellow pages) can reveal the real identity of the user, which can be mapped to the pseudo-ID and finally the updates the user made. Third, a pseudo-ID that cannot be mapped to a real-ID can be abused by an adversary to provide fake updates and disturb the accuracy of the service.
Traditionally, the anonymity problem in mobile services has focused on the second problem above. The main idea of the solutions is to provide k-anonymity to a user, which essentially means that the update will look like it came from any of k users around (the location of) the actual user. The method is often called “spatial cloaking”. This method, however, cannot be used for our purpose, since our goal is also to provide incentives to the specific user for her update. Secondly, it is not yet a common scenario that mobile services include updates from users, and that services provide incentives, along with providing anonymity. In the few applications where incentives are provided, anonymity has been compromised.
Accordingly, there is a need for providing anonymity in a mobile services environment in which the real identity of the user is not be revealed either by the location they are updating from, or when the users encash the reward points.
A method includes transmitting location-specific information by a user device to a service provider, preserving anonymity of the user device in the transmitting, providing incentives to the user device for information upload to the service provider, and disabling the service provider from associating the user device with the information upload and the location specific information for promoting the information upload.
A wireless system includes a service provider responsive to a user device transmitting its location-specific information by a user and for providing an incentive to said user device for an information upload to said service provider while preserving anonymity of said user device with said service provider being incapable of associating said user device with said respective information upload and said location specific information.
These and other advantages of the invention will be apparent to those of ordinary skill in the art by reference to the following detailed description and the accompanying drawings.
The invention is directed to a method and apparatus that considers the three factors that can reveal the identity of a user: 1) a Pseudo-ID for the user to conceal the actual identity, which can be used during location-specific updates and for receiving reward points; 2) the location in which the user herself is present; and 3) a Real-ID for the user (that may include a bank account information or address information, for instance) in order to encash reward points; and decouples each of them during the various operations (of providing updates to services and encashing reward points) in such a way that the actual identity is not associated with the update a user makes. The Pseudo-ID is generated such that it can be easily verified by the service provider, and it cannot be generated by the user herself.
For avoiding the mapping between Pseudo-ID and Real-ID, the invention includes a two-step anonymous-but-verifiable encashment protocol that is described below. For avoiding the mapping between location updates and the real identity of the user through the use of public address databases, a randomly structured secret zone is used around the top few most frequently visited locations by the user. The user device either does not provide updates within this zone or provides updates with the location re-mapped onto the edge of the secret zone. The size of the secret zone can be made user configurable to allow users to make informed decisions. In densely populated places, the zones can be smaller than in sparse places. It is noted that the bigger the zone, the lower is the reward a user receives.
Turning now to
In one instantiation of Pseudo-IDs, we assume that a network provider, who is trusted by both the user and the service provider, generates the Pseudo-ID for each user. Further, we assume that the network provider knows the Real-ID of the user, but will not reveal it to the service provider. Under this setup, the Pseudo-ID has the following structure shown in
Optionally, we can use a hash function to find the message digest for the entire random number and user number with secret initial value which is known only to the service provider and the network provider. Finally, the field signed hash is the signed version of the message digest or directly the signed version of the random number concatenated with the user number. This can be done by choosing a pair of public-private keys by the network provider where the public key is only provided to the service provider. It is of no harm to even reveal the public key to everybody as it only makes possible to check if a certain Pseudo-ID is valid or not; nobody other than the network provider can generate such Pseudo-ID as it requires the knowledge of the private key of the network provider. In an alternate implementation, the signed hash can be replaced by an encrypted hash which is only available to the service provider and network provider and nobody else.
The properties of the inventive Pseudo-ID are as follows:
A two step cash redemption process is used for the reward points acquired by a user in his account. In the first step, the user generates the e-cash and does it by using his Pseudo-ID; the generated e-cash will be anonymous, which cannot by itself be used to trace either Real-ID or Pseudo-ID. In the second step, the user holding an e-cash certificate will redeem it for real money (or gift cards, merchandise, etc) by using his Real-ID. The diagrams of
Turning now to the diagram of
The user explicitly asks for the system parameters that are necessary to generate e-cash currency for all or certain denominations. This information is public domain information and can be requested anytime and well ahead of time that the actual encashing is performed.
During encashment, the user first engages with the service provider in a transaction in which the user generates verifiable information, while at the end of the transaction the anonymity of the user is preserved. The process goes by asking the service provider to blindly sign a piece of information with a given signature. The SP will do so and return the result to the user and reduces a nominal point from the user account. The point reduction depends on the type of the requested signature. Depending on different denomination amounts, the service providers deduct different number of points from the user account for different signature types. For error control, to make sure that the user does not lose money, the service provider keeps the record of the point reduction in the user account with the reply provided to the user. Thus, the user can later ask for the certain verification in case that the user has not received the service provider's response.
The diagram of
(re1.(xe2 mod N2) mod N1)d1 mod N1
The currency generation can be done alternatively by using a combination of a one-way cryptographic hash function and a public-private key system in the following way.
This approach significantly reduces the computational complexity at the user (mobile) end and also would help the recordkeeping by the service provider as well. The idea is that the hash function has already been embedded in the initial seed and thus, the SP can store and search the database based on this value. In this implementation, the Hash function can be unified for all the denomination amounts and the signature would change from one denomination to another.
In the second step, the user generates a request using the Real-ID (and bank account information or postal address information) and the e-cash certificate received in the previous step. Since the generated e-cash certificate does not have any association to the user's Pseudo-ID, the service provider cannot make association between the e-cash certificate (and hence the real ID) to the information updates it corresponds to.
RECORDKEEPING: When a user redeems an e-cash certificate
{x, (xe2 mod N2)d1 mod N1, C}
as above, this value x is recorded into a table so that the same user or other users cannot re-claim it.
EFFICIENT SEARCH: The procedure of cash redemption at the service provider also involves searching the table of used certificates to ensure the originality of the newly claimed e-cash certificate. The size of this database will grow large over time as the number of certificates encashed increases. To enable efficient search in this database, we propose using hierarchical hash functions.
The idea is to use a hash function, say H1(x) where x is the e-cash seed, and keep the sorted values of x in order of their H1(x). When a new inquiry comes, the hash function of the new e-cash seed, say w, is calculated and is searched in the table. In case of collision, the original value w is compared with all the other e-cash seed x previously recorded in the table for the same hash value.
This idea can be used recursively to build a hierarchical hash function. When the number of entries in the table corresponding to a given hash value h1=H1(x) increases and passes a threshold level, e.g., 10 entry, then we use the second level hash function H2(.) to sort these entries. We build the hash function such that they are independent and have uniform distribution, i.e., if the input is taken uniformly from the input space, the output is also uniformly distributed in the output space.
In the simplest form, the random polygon can be a circle of a certain radius, with the center shifted by a certain distance from the actual sensitive location of the user. More sophisticated polygons with different length sides, and varying distances from the actual sensitive location further increase the complexity of identifying the user location. The circle or the polygon is locally generated by the user and known only to the user. To determine the radius of the circle or the sides of the polygon, a public database of addresses can be used by the user to ensure that enough other addresses are present within the security zone.
Alternately, a large enough area can be chosen by the user herself through explicit knowledge of the location. For example, in a densely populated area, the region can be very small, where as in a sparse area such as rural locality or a farm house, the zone can be large. This way of generating the zone ensures that even after knowing enough points on the edges of the zone, the exact location of the user cannot be accurately determined by anyone.
The present invention has been shown and described in what are considered to be the most practical and preferred embodiments. It is anticipated, however, that departures may be made therefrom and that obvious modifications will be implemented by those skilled in the art. It will be appreciated that those skilled in the art will be able to devise numerous arrangements and variations, which although not explicitly shown or described herein, embody the principles of the invention and are within their spirit and scope.
This application claims the benefit of U.S. Provisional Application No. 61/166,031, entitled “Mechanisms for Incentives, Data Validation and Anonymity in User-assisted Mobile Services”, filed on Apr. 2, 2009, and U.S. Provisional Application No. 61/166,029, entitled “Mechanisms for Incentives, Data Validation and Anonymity in User-assisted Mobile Services”, filed on Apr. 2, 2009, the contents of which are incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
61166031 | Apr 2009 | US | |
61166029 | Apr 2009 | US |