HK1207190B - Profile noise anonymity for mobile users - Google Patents

Description

Profile noise anonymity for mobile users

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to U.S. Patent Application No. 13/595,764, filed on August 27, 2012, entitled “Profile Noise Anonymity For Mobile Users,” which is incorporated herein by reference.

Technical Field

The present invention relates generally to managing online user data and, more particularly, but not exclusively, to providing aggregated subsets of non-unique user data to user data buyers that can be employed as a basis for targeting online advertising campaigns.

Background Art

The online advertising industry uses user data to provide targeted advertising campaigns, which can optimize ad placement, ad content, real-time bidding, and the like. This user data can be collected for individuals or groups of individuals and can include demographic data (e.g., gender, age, race), psychographic data (e.g., interests, opinions), geographic data (e.g., zip code, state, country), in-market data (e.g., user interest in luxury cars, travel to Polynesia), and social media data. Various types of user data are collected from multiple sources over time. Historically, group user data that is not unique to an individual is often not very useful for targeted advertising campaigns. Although individual unique user data may be much more useful for targeted advertising campaigns than group user data, the collection of such unique user data for individual users may be invasive, and the unique user data itself may infringe on the privacy rights of individual users. Therefore, the present invention is proposed with respect to these and other considerations.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the present invention will be described below with reference to the accompanying drawings, in which like reference numerals refer to like parts throughout the various figures unless otherwise specified.

For a better understanding of the present invention, reference will now be made to the detailed description which should be read in conjunction with the accompanying drawings, in which:

FIG1 is a system diagram of an environment in which embodiments of the present invention may be implemented;

FIG2 illustrates one embodiment of a client device that may be included in the system shown in FIG1 ;

FIG3 illustrates one embodiment of a network device that may be included in the system shown in FIG1 ;

FIG4 illustrates a logic flow diagram generally illustrating one embodiment of a process for resolving queries for user data and providing an overview of aggregated user data to a user data buyer;

FIG5 illustrates a logic flow diagram generally illustrating one embodiment of a process for collecting and storing user data;

FIG6 illustrates a logic flow diagram generally illustrating one embodiment of a process for resolving a query for user data by aggregating the user data based on the query to generate multiple subsets of non-unique user data;

FIG7 illustrates a logic flow diagram generally illustrating an alternative embodiment of a process for collecting and storing user data;

FIG8 illustrates one embodiment of a use case, showing a system diagram of a system that may be utilized to collect user data from user data suppliers and provide aggregated user data to user data buyers;

FIG9 illustrates a logic flow diagram generally illustrating one embodiment of an overview process for determining direct and/or recommended attributes and including them in a user profile;

FIG10 illustrates a logic flow diagram generally illustrating one embodiment of a process for determining recommended attributes based on mappings between attributes;

FIG11 illustrates a logic flow diagram generally illustrating one embodiment of a process for generating a mapping between multiple attributes;

FIG12 illustrates a logic flow diagram generally illustrating one embodiment of a process for determining recommended attributes for a user based on attributes of other similar users; and

FIG. 13 illustrates one embodiment of a use case, showing mappings between multiple attributes corresponding to multiple users.

DETAILED DESCRIPTION

Unless the context clearly indicates otherwise, throughout the specification and claims, the following terms will be taken to have the meanings explicitly associated herein. As used herein, the phrase "in one embodiment" does not necessarily refer to the same embodiment, but it may. Additionally, as used herein, the phrase "in another embodiment" does not necessarily refer to a different embodiment, but it may. Thus, as described below, the various embodiments of the present invention may be readily combined without departing from the scope or spirit of the invention.

Furthermore, unless the context clearly indicates otherwise, the term "or" as used herein is an inclusive "or" operator and is equivalent to the term "and/or." Unless the context clearly indicates otherwise, the term "based on" is not exclusive and allows for being based on additional factors not described. Furthermore, in this specification, the meanings of "a," "an," and "an" include the plural. The meaning of "in..." includes "in" and "on."

The phrase "user data" as used herein generally refers to information about one or more users. User data may include a zip code, an extended zip code, one or more attributes, and/or any combination thereof. The term "attribute" as used herein generally refers to type information and/or characteristics of user data. Attributes may include, without limitation: age; gender; occupation; location; other demographic information; applications utilized by a user; the user's online or offline behavior and actions; direct or indirect communications and/or tendencies or preferences corresponding to specific products, events, or entities; and/or direct or indirect indications of user preferences, inclusion or exclusion in specific groups or categories, and the like. Such online behavior may include, without limitation, browsing, searching, purchasing, and the like. Lack of specific behavior and/or negative preferences may also be used as attributes. Attributes may also include characteristics of a device utilized by a user, such as, without limitation, device capabilities, device identifiers, and the like.

The term "attribute" may also refer to a promotional activity that is seen or experienced by a user. Such promotional activity may include advertising campaigns, promotional campaigns, informational campaigns, and the like. Such promotional activity may be experienced by a user through online advertising placed on a website or other web service, including email, SMS, IM messages, and the like; or other offline advertising in virtually any medium, including, but not limited to, television, radio, print, physical displays, and the like.

In some embodiments, the term "direct attributes" may refer to attributes determined for a user based on user data provided for the user, such as those obtained by analyzing the user data. In at least one embodiment, direct attributes may also be referred to as direct behaviors. In other embodiments, the term "recommended attributes" may refer to attributes determined for the user independently of and/or indirectly from the user data provided for the user, such as those based on a mapping of attributes, attributes of other similar users, random attributes, and the like.

As used herein, the term "user data buyer" (also referred to as a "buyer") refers to any entity, individual, partnership, company, enterprise, etc. that may purchase, rent, lease, bid for, and/or otherwise acquire aggregated user data. In one embodiment, a user data buyer may refer to an application that may wish to receive user data from another application.

The term "user data supplier" (also referred to as a "supplier") as used herein refers to any entity, individual, partnership, company, enterprise, etc. that may collect user data and may sell, rent, lease, and/or otherwise provide the collected user data to a user data aggregator. In one embodiment, a user data buyer may refer to an application that may wish to share user data with another application.

The following will briefly describe embodiments of the present invention to provide a basic understanding of certain aspects of the present invention. This brief description is not intended to be an exhaustive overview. It is not intended to identify key or critical elements, nor is it intended to define or otherwise narrow its scope. Its purpose is simply to present some concepts in a simplified form as a prelude to the more detailed description that will be given later.

In short, various embodiments are directed to collecting, aggregating, and indexing unique and non-unique user data from multiple users. Results of queries targeting this indexed aggregation of user data are provided across multiple subsets of the aggregated user data. Each subset of the aggregated user data corresponds to a specific portion of the multiple users. Furthermore, each of these specific portions of users is configured to be at least large enough to provide general anonymity for each individual user. While user data can be collected in a variety of ways, in at least one of the various embodiments, multiple third-party entities may collect and provide user data to a user data aggregator, or the user data aggregator may collect at least a portion of the user data itself. In at least one of the various embodiments, user data may be collected as unique user data, non-unique user data, and/or any combination thereof. Unique user data typically includes information that uniquely identifies a user, while non-unique user data typically identifies a group of users who share common memberships, interests, and the like.

In at least one of the various embodiments, multiple subsets of aggregated user data may be provided as a result of a query regarding targeted behavior. In various embodiments, the query may be provided by a user data buyer, a user data aggregator, or the like. In various embodiments, the subsets of user data may be aggregated based on non-unique geographic information, such as a five-digit zip code, a nine-digit zip code, a neighborhood, a country code, and/or any combination thereof. In at least one embodiment, each subset of aggregated user data may include a weight indicating its relevance to the query.

In various embodiments, the number of anonymized users in each aggregated user data subset can be reduced or increased, as long as the number of users is not less than a minimum number that is at least partially responsible for protecting the anonymity of the users. In at least one embodiment, a user data buyer requesting search results for an aggregated user data subset corresponding to a smaller number of anonymized users can be charged a higher fee. Additionally, a user data buyer requesting search results for an aggregated user data subset corresponding to a larger number of anonymized users can be charged a lower fee. In some embodiments, the user data buyer can utilize the search results to allow online advertising campaigns to target users associated with at least one targeted behavior.

In some other embodiments, a user's profile can be modified to include direct attributes and/or recommended attributes. In at least one embodiment, attributes can be stored in the profile so that they are indistinguishable in the profile as to whether they are provided or recommended for the user, which can add noise to the user's profile. By including recommended attributes in the user's profile, the user's anonymity can be increased while maintaining the relevance of the attributes to the user. In some embodiments, at least one direct attribute corresponding to the data provided for the user can be determined. In some other embodiments, at least one recommended attribute can be determined, which can be related to the direct attribute. In some embodiments, the recommended attributes can be based on a mapping of attributes. In other embodiments, the recommended attributes can be based on attributes of other users similar to the user.

Illustrative operating environment

Figure 1 illustrates various components of one embodiment of an environment in which the present invention may be practiced. Not all components are required to practice the present invention, and changes may be made in component arrangement and type without departing from the spirit or scope of the present invention.

As shown, system 100 of FIG1 includes a local area network ("LAN")/wide area network ("WAN") (network) 108, a wireless network 107, client devices 102-105, a user data supplier server ("UDSS") 109, and a user data aggregator server ("UDAS") 111. Network 108 communicates with each element of system 100 and allows communication between each element of system 100. Wireless network 107 also allows communication with wireless devices, such as client devices 103-105.

An embodiment of client devices 102-105 will be described in more detail below in conjunction with FIG2 . In one embodiment, at least some of the client devices 102-105 may operate over a wired and/or wireless network, such as networks 107 and 108. Generally speaking, client devices 102-105 may include virtually any computing device capable of communicating over a network to send and receive information (including instant messaging), perform various online activities, and the like. It should be appreciated that more or fewer client devices may be included in a system such as that described herein, and thus, embodiments are not limited by the number or type of client devices employed.

Devices that can operate as client devices 102 may include devices that typically connect using wired or wireless communication media, such as personal computers, servers, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, and the like. In some embodiments, client devices 102-105 may include virtually any portable computing device capable of connecting to another computing device and receiving information, such as laptop computer 103, smartphone 104, tablet computer 105, and the like. However, portable computing devices are not limited thereto and may also include other portable devices, such as cellular phones, display pagers, radio frequency ("RF") devices, infrared ("IR") devices, personal digital assistants ("PDAs"), handheld computers, wearable computer integrated devices that combine one or more of the aforementioned devices, and the like. Consequently, client devices 102-105 generally have a wide range of capabilities and features. Furthermore, client devices 102-105 may provide access to a variety of computing applications, including browsers or other web-based applications.

A web-enabled client device may include a browser application configured to receive and send web pages, web-based messages, and the like. The browser application may be configured to receive and display graphics, text, multimedia, and the like using virtually any web-based language, including wireless application protocol ("WAP") messages and the like. In one embodiment, the browser is enabled to use Handheld Device Markup Language ("HDML"), Wireless Markup Language ("WML"), WMLScript, JavaScript, Standard Generalized Markup Language ("SGML"), Hypertext Markup Language ("HTML"), Extensible Markup Language ("XML"), and the like to display and send messages. In one embodiment, a user of the client device may use the browser application to perform various activities over the network (online). However, various online activities may also be performed using another application.

The client devices 102-105 may also include at least one other client application that is configured to receive and/or send data between another computing device. The client application may include the ability to send and/or receive content, etc. The client application may also provide information identifying itself, including type, capabilities, name, etc. In one embodiment, the client device 102-105 may uniquely identify itself through any of a variety of mechanisms, including a telephone number, mobile identification number ("MIN"), electronic serial number ("ESN"), or other mobile device identifier. The information may also indicate the content format that the mobile device is allowed to use. Such information may be provided in network packets, etc., and sent between other client devices, UDSS 109, or other computing devices.

The client devices 102-105 may also be configured to include a client application that allows an end user to log into an end user account that can be managed through another computing device, such as UDSS 109, UDAS 111, etc. In a non-limiting example, such an end user account may be configured to allow the end user to manage one or more online activities, which in a non-limiting example include search activities, social networking activities, browsing various websites, communicating with other users, participating in games, interacting with various applications, etc. However, participation in online activities may also be carried out without logging into an end user account.

Wireless network 107 is configured to couple client devices 103-105 and their components to network 108. Wireless network 107 may include any of a variety of wireless subnetworks, which may also encompass independent ad hoc networks, etc., to provide infrastructure-oriented connectivity for client devices 102-105. Such subnetworks may include mesh networks, wireless LAN ("WLAN") networks, cellular networks, etc. In one embodiment, the system may include more than one wireless network.

The wireless network 107 may also include an autonomous system of terminals, gateways, routers, etc. connected by wireless radio links, etc. These connectors may be configured to move freely and randomly and organize themselves arbitrarily, so that the topology of the wireless network 107 may change rapidly.

The wireless network 107 may also employ a variety of access technologies, including second generation (2G), third generation (3G), fourth generation (4G) radio access for cellular networks, WLAN, wireless router ("WR") mesh, and the like. Access technologies such as 2G, 3G, 4G, and future access networks may allow wide area coverage for mobile devices, such as client devices 103-105 with varying degrees of mobility. In one non-limiting example, the wireless network 107 may allow radio connectivity through radio network access, such as Global System for Mobile Communications ("GSM"), General Packet Radio Service ("GPRS"), Enhanced Data GSM Environment ("EDGE"), Wideband Code Division Multiple Access ("WCDMA"), and the like. In essence, the wireless network 107 may include nearly any wireless communication mechanism that enables information to travel between the client devices 103-105 and another computing device, a network, and the like.

Network 108 is configured to couple network devices with other computing devices, including UDSS 109 and UDAS 111, and to client devices 102-105 via wireless network 107. Network 108 is permitted to utilize any form of computer-readable media for transmitting information from one electronic device to another. Furthermore, network 108 may include, in addition to a LAN, the Internet, a WAN, a direct connection (such as via a Universal Serial Bus ("USB") port), other forms of computer-readable media, or any combination thereof. On an interconnected set of LANs (including those based on different architectures and protocols), routers act as links between LANs, allowing messages to be sent from one LAN to another. While communication links within a LAN typically include twisted pair or coaxial cable, communication links between networks may utilize analog telephone lines, fully or partially dedicated digital lines including T1, T2, T3, and/or T4, and/or other carrier mechanisms, including, for example, E-carrier, Integrated Services Digital Network ("ISDN"), Digital Subscriber Line ("DSL"), wireless links including satellite links, or other communication links known to those skilled in the art. In addition, the communication link can also use any of a variety of digital signaling technologies, including, for example, but not limited to, DS-0, DS-1, DS-2, DS-3, DS-4, OC-3, OC-12, OC-48, etc. In addition, remote computers and other related electronic devices can be remotely connected to the LAN or WAN via a modem and a temporary telephone link. In one embodiment, the network 108 can be configured to transmit Internet Protocol ("IP") information. Essentially, the network 108 includes any communication method that allows information to travel between computing devices.

Furthermore, communication media typically embodies computer-readable instructions, data structures, program modules, or other transport mechanisms, and includes any information delivery media. For example, communication media includes wired media such as twisted pair, coaxial cable, optical fiber, waveguides, and other wired media, and wireless media such as acoustic, RF, infrared, and other wireless media.

An embodiment of UDSS 109 is described in greater detail below in conjunction with FIG. In short, UDSS 109 comprises virtually any network device that can be used to collect user data from client devices 102-105, website server 110, carrier networks providing access to wireless network 107, service providers providing access to networks 107 and 108, and so forth, and provide the collected user data to UDAS 111. In some embodiments, UDSS 109 can operate as a website server, collecting user data from visits to websites hosted by UDSS 109 and/or other websites hosted by other devices, such as website server 110. In other embodiments, UDSS 109 can operate as a server, storing data online for applications, such as smartphone applications. In at least one of the various embodiments, UDSS 109 can collect unique user data, non-unique user data, and/or any combination thereof. In at least one embodiment, UDSS 109 can provide the collected user data to UDAS 111 as aggregated user data. Devices that may be configured to operate as UDSS 109 include a variety of network devices including, but not limited to, personal computers, desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, server equipment, network appliances, and the like.

Although FIG1 illustrates UDSS 109 as a single computing device, the present invention is not limited thereto. For example, one or more functions of UDSS 109 may be distributed across one or more different network devices. Furthermore, UDSS 109 is not limited to a particular configuration. Thus, in one embodiment, UDSS 109 may include multiple network devices for collecting user data from client devices 102-105. Similarly, in another embodiment, UDSS 109 may include multiple network devices operating using a master/slave approach, wherein one of the multiple network devices of UDSS 109 operates to manage and/or otherwise coordinate the operations of the other network devices. In other embodiments, UDSS 109 may operate as multiple network devices within a cluster architecture, a peer-to-peer architecture, and/or even a cloud architecture. Therefore, the present invention should not be construed as limited to a single environment and other configurations and architectures are also contemplated.

At least one embodiment of the UDAS 111 is described in greater detail below in conjunction with FIG. 3 . However, in short, the UDAS 111 may comprise virtually any network device capable of generating multiple aggregated subsets of non-unique user data. In some embodiments, the UDAS 111 may provide multiple subsets of aggregated user data corresponding to anonymized users to user data buyers in response to queries. The user data buyers may utilize the provided aggregated user data subsets in online advertising campaigns. In at least one of the various embodiments, the UDAS 111 may be configured to implement at least some of the operations of the UDSS 109, such as collecting user data. Devices capable of operating as the UDAS 111 include various network devices, including, but not limited to, personal computers, desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, server equipment, network appliances, and the like.

Although FIG1 illustrates UDAS 111 as a single computing device, the present invention is not limited thereto. For example, one or more functions of UDAS 111 may be distributed across one or more different network devices. Furthermore, UDAS 111 is not limited to a particular configuration. Thus, in one embodiment, UDAS 111 may include multiple network devices for aggregating user data. Similarly, in another embodiment, UDAS 111 may include multiple network devices operating using a master/slave approach, wherein one of the multiple network devices of UDAS 111 operates to manage and/or otherwise coordinate the operations of the other network devices. In other embodiments, UDAS 111 may operate as multiple network devices within a cluster architecture, a peer-to-peer architecture, and/or even a cloud architecture. Therefore, the present invention should not be construed as limited to a single environment, and other configurations and architectures are also contemplated.

Illustrative Client Devices

FIG2 illustrates one embodiment of a client device 200 that can be included in a system implementing an embodiment of the present invention. Client device 200 may include many more or fewer components than those shown in FIG2 . However, the components shown are sufficient to disclose an illustrative embodiment for practicing the present invention. Client device 200 may, for example, represent an embodiment of at least one of client devices 102-105 of FIG1 .

As shown, client device 200 includes a central processing unit ("CPU") 202 in communication with mass storage 226 via a bus 234. Client device 200 also includes a power supply 228, one or more network interfaces 236, an audio interface 238, a display 240, a keypad 242, an illuminator 244, a video interface 246, an input/output interface 248, a tactile interface 250, and a global positioning system ("GPS") receiver 232.

The power supply 228 provides power to the client device 200. Rechargeable or non-rechargeable batteries may be used to provide power. Power may also be provided by an external power source, such as an AC adapter or a powered docking cradle that replenishes and/or recharges the batteries.

The client device 200 may optionally communicate with a base station (not shown) or directly with another computing device. The network interface 236 includes circuitry for coupling the client device 200 to one or more networks and is configured for one or more communication protocols and technologies, including, but not limited to, Global System for Mobile Communications ("GSM"), Code Division Multiple Access ("CDMA"), Time Division Multiple Access ("TDMA"), User Datagram Protocol ("UDP"), Transmission Control Protocol/Internet Protocol ("TCP/IP"), Short Message Service ("SMS"), General Packet Radio Service ("GPRS"), WAP, Ultra-Wideband ("UWB"), IEEE 802.16 Worldwide Interoperability for Microwave Access ("WiMax"), Session Initiation Protocol/Real-Time Transport Protocol ("SIP/RTP"), or any of a variety of other wireless communication protocols. The network interface 236 is sometimes also referred to as a transceiver, a transceiver device, or a network interface card ("NIC").

Audio interface 238 is arranged to produce and receive audio signals such as the sound of human speech.For example, audio interface 238 can be coupled to a speaker and microphone (not shown) to communicate remotely with other people and/or generate audio confirmation for some action.

Display 240 may be a liquid crystal display ("LCD"), a gas plasma display, a light emitting diode ("LED"), or any other type of display used with computing devices. Display 240 may also include a touch-sensitive screen configured to receive input from an object such as a stylus or a human finger.

The keypad 242 may include any input device configured to receive input from a user. For example, the keypad 242 may include a button numeric dial or a keyboard. The keypad 242 may also include command buttons associated with selecting and sending images.

Illuminator 244 can provide status indication and/or provide light. Illuminator 244 can remain active for a specific time period or in response to an event. For example, when illuminator 244 is active, it can backlight the buttons on keypad 242 and can remain on while the client device is powered. In addition, illuminator 244 can also backlight these buttons in various patterns when performing specific actions (such as dialing another client device). Illuminator 244 can also cause a light source located within a transparent or translucent housing of the client device to illuminate in response to an action.

The video interface 246 is configured to capture video images, such as still photos, video clips, infrared video, and the like. For example, the video interface 246 can be coupled to a digital video camera, a webcam, and the like. The video interface 246 can include a lens, an image sensor, and other electronics. The image sensor can include a complementary metal oxide semiconductor ("CMOS") integrated circuit, a charge coupled device ("CCD"), or any other integrated circuit for sensing light.

The client device 200 also includes an input/output interface 248 for communicating with external devices, such as a headset or other input or output device not shown in FIG2 . The input/output interface 248 can utilize one or more communication technologies, such as USB, infrared, Bluetooth ^™ , etc. A tactile interface 250 is configured to provide tactile feedback to the user of the client device. For example, the tactile interface 250 can be used to vibrate the client device 200 in a specific manner when another user of the computing device calls.

The GPS transceiver 232 can determine the physical coordinates of the client device 200 on the Earth's surface. The GPS transceiver 232 may be optional in certain embodiments. The GPS transceiver 232 typically outputs a location as latitude and longitude values. However, the GPS transceiver 232 may also employ other geolocation mechanisms, including, but not limited to, triangulation, Assisted GPS ("AGPS"), Enhanced Observed Time Difference ("E-OTD"), Cell Identifier ("CI"), Service Area Identifier ("SAI"), Enhanced Timing Advance ("ETA"), Base Station Subsystem ("BSS"), and the like, to further determine the physical location of the client device 200 on the Earth's surface. It should be understood that under various conditions, the GPS transceiver 232 may determine the physical location corresponding to the client device 200 within millimeters; and in other cases, the determined physical location may be less precise, such as within meters or at much larger distances. However, in one embodiment, the mobile device may provide other information, including, for example, a Media Access Control ("MAC") address, an IP address, and the like, that can be employed to determine the device's physical location through other components.

The mass storage 226 includes random access memory ("RAM") 204, read-only memory ("ROM") 222, and other storage devices. The mass storage 226 illustrates an example of a computer-readable storage medium (device) for storing information, such as computer-readable instructions, data structures, program modules, or other data. The mass storage 226 stores a basic input/output system ("BIOS") 224 for controlling low-level operations of the client device 200. The mass storage also stores an operating system 206 for controlling the operation of the client device 200. It should be appreciated that this component may include a general-purpose operating system such as a version of UNIX or LINUX ^™ , or a dedicated client communication operating system such as Microsoft Corporation's Windows Mobile ^™ , Apple Corporation's iOS ^™ , Google Corporation's Android ^™ , or an operating system. The operating system may include or interface with a Java virtual machine module that allows control of hardware components and/or operating system operations via Java applications.

The mass storage 226 also includes one or more data storage devices 208, which can be utilized by the client device 200 to store, among other things, applications 214 and/or data. For example, the data storage device 208 can also be used to store information describing various capabilities of the client device 200. The information can then be provided to another device based on any of a variety of events, including being sent as part of a header during a communication, being sent upon request, and the like. The data storage device 208 can also be used to store social network information, including address books, friend lists, nicknames, user profile information, and the like. In addition, the data storage device 208 can also store messages, web page content, or any of a variety of user-generated content. At least a portion of the information can be stored on another component of the network device 200, including, but not limited to, a processor-readable storage medium 230, a disk drive, or other computer-readable storage medium (not shown) within the client device 200.

The processor-readable storage medium 230 may include volatile, nonvolatile, removable, and non-removable media implemented by any method or technology for storing information, such as computer or processor-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include RAM, ROM, electrically erasable programmable read-only memory ("EEPROM"), flash memory or other memory technology, compact disk read-only memory ("CD-ROM"), digital versatile disk ("DVD") or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other physical medium that can be used to store the desired information and can be accessed by a computing device. The processor-readable storage medium 230 may also be referred to herein as computer-readable storage media.

Applications 214 may include computer-executable instructions that, when executed by client device 200, transmit, receive, and/or otherwise process network data. Network data may include, without limitation, messages (e.g., SMS, Multimedia Messaging Service (MMS), Instant Messaging (IM), email, and/or other messages), audio, video, and may allow for remote communication with another user of another client device. Applications 214 may include, for example, a messenger 216, a browser 218, and other applications 220. Other applications 220 may include, without limitation, calendars, search programs, email clients, IM applications, SMS applications, Voice over Internet Protocol (VOIP) applications, contact managers, task managers, transcoders, database programs, word processing programs, security applications, spreadsheet programs, games, search programs, and the like. In some embodiments, other applications 220 may collect and store user data, which may be provided to UDSS 109 of FIG. 1 .

Messenger 216 can be configured to manage messaging sessions using any of a variety of messaging communications, including, but not limited to, email, SMS, IM, MMS, Internet Relay Chat ("IRC"), Microsoft IRC ("mIRC"), Really Simple Syndication ("RSS") feeds, and the like. For example, in one embodiment, messenger 216 can be configured as an IM application, such as AOL (America Online) Instant Messenger, Yahoo! Messenger, .NET Messenger Server, ICQ ("I'm Looking for You"), and the like. In one embodiment, messenger 216 can be configured to include a mail user agent ("MUA"), such as Elm, Pine, Message Handling ("MH"), Outlook, Eudora, MacMail, Mozilla Thunderbird, and the like. In another embodiment, messenger 216 can be a client application configured to integrate and employ a variety of messaging protocols, including, but not limited to, various push and/or pull mechanisms for client device 200. In one embodiment, messenger 216 can interact with browser 218 to manage messages. As used herein, the term "message" refers to any of a variety of messaging formats or forms of communication, including but not limited to email, SMS, IM, MMS, IRC, and the like.

The browser 218 can include almost any application configured to receive and display graphics, text, multimedia, messages, etc., and can use almost any web-based language. In one embodiment, the browser application is allowed to use HDML, WML, WMLScript, JavaScript, SGML, HTML, XML, etc. to display and send messages. However, any of a variety of other web-based programming languages can be used. In one embodiment, the browser 218 can allow the user of the client device 200 to communicate with another network device, such as the UDSS 109 and/or UDAS 111 of Figure 1.

Illustrative Network Equipment

FIG3 illustrates an embodiment of a network device 300 according to an embodiment of the present invention. Network device 300 may include many more or fewer components than those shown. However, the components shown are sufficient to disclose an illustrative embodiment for practicing the present invention. Network device 300 may be configured to operate as a server, client, peer, host, or any other device. Network device 300 may, for example, represent UDSS 109, UDAS 111, and/or other network devices of FIG1 .

Network device 300 includes a central processing unit 302, a processor-readable storage medium 332, a network interface unit 330, an input/output interface 332, a hard drive 334, a video display adapter 336, and mass storage, all of which communicate with each other via bus 326. The mass storage typically includes RAM 304, ROM 322, and one or more permanent mass storage devices, such as a hard drive 334, a tape drive, an optical drive, and/or a floppy disk drive. The mass storage stores an operating system 306 for controlling the operation of network device 300. Any general-purpose operating system can be used. A basic input/output system ("BIOS") is also provided for controlling the low-level operations of network device 300. As shown in Figure 3, network device 300 also communicates with the Internet or some other communication network via network interface unit 330, which is configured to use various communication protocols including TCP/IP. Network interface unit 330 is sometimes referred to as a transceiver, transceiver device, or network interface card ("NIC").

Network device 300 also includes an input/output interface 332 for communicating with external devices, such as a keyboard or other input or output devices not shown in Figure 3. Input/output interface 332 may utilize one or more communication technologies, such as USB, infrared, Bluetooth ^™ , and the like.

The mass storage described above illustrates another type of computer-readable media, namely computer-readable storage media and/or processor-readable storage media, including processor-readable storage media 328. Processor-readable storage media 328 may include volatile, non-volatile, removable, and non-removable media implemented by any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Examples of processor-readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computing device.

As shown, data storage 308 may include databases, files, spreadsheets, folders, documents, etc., which may be configured to maintain and store user account identifiers, user profiles, email addresses, IM addresses, and/or other network addresses, etc. Data storage 308 may also include program code, data, algorithms, etc. for use by a processor, such as external processing unit 302, to execute and implement actions. In one embodiment, at least some of data storage 308 may also be stored on another component of network device 300, including, but not limited to, processor-readable storage medium 328, hard drive 334, etc.

The data storage device 308 may also store user data 310. The user data 310 may store user data collected about users of client devices, such as the client devices 102-105 of FIG. 1 . In some embodiments, the user data 310 may store unique user data, non-unique user data, aggregated user data, and/or any combination thereof. The user data 310 may include various attributes, such as a five-digit zip code, an extended nine-digit zip code, and the like.

The mass storage device can also store program code and data. One or more applications 314 can be loaded into the mass storage device and run on the operating system 306. Examples of application programs can include transcoders, schedulers, calendars, database programs, word processors, hypertext transfer protocol ("HTTP") programs, customizable user interface programs, IPSec applications, encryption programs, security programs, SMS message servers, IM message servers, email servers, account managers, etc. A messaging server 316, a website server 318, a user data aggregator server 320, and/or a user data supplier server 321 can also be included in the application 314 as application programs.

The messaging server 316 may include virtually any one or more computing components configured and arranged to forward messages from a message user agent and/or other messaging servers and deliver the messages to a local message repository, such as the data store 308, or the like. Thus, the messaging server 316 may include a message transfer manager that transmits messages using any of a variety of email protocols, including, but not limited to, the Simple Mail Transfer Protocol ("SMTP"), the Post Office Protocol ("POP"), the Internet Message Access Protocol ("IMAP"), the Network News Transfer Protocol ("NNTP"), and the like. The messaging server 316 may also be managed by one or more components of the messaging server 316. Thus, the messaging server 316 may also be configured to manage SMS messages, IM, MMS, IRC, RSS feeds, or any of a variety of other message types. In one embodiment, the messaging server 316 may allow users to initiate and/or otherwise conduct chat sessions, VOIP sessions, and the like.

The website server 318 can represent any of a variety of information and services configured to provide content (including messages) to another computing device over a network. Thus, the website server 318 can include, for example, a web server, a file transfer protocol ("FTP") server, a database server, a content server, and the like. The website server 318 can provide content, including messages, over a network using any of a variety of formats, including, but not limited to, WAP, HDML, WML, SGML, HTML, XML, compact HTML ("cHTML"), extensible HTML ("xHTML"), and the like. The website server 318 can also be configured to allow users of client devices (such as the client devices 102-105 of FIG. 1 ) to browse websites, upload user data, view and interact with advertisements, and the like.

The user data aggregator server 320 is configured to aggregate user data for provision to user data buyers for use in advertising campaigns. In one embodiment, the user data aggregator server 320 may be configured to receive collected user data from a user data supplier server 321. In some embodiments, the user data aggregator server 320 may receive queries for user data. Based on the queries, the user data aggregator server 320 may generate multiple subsets of the aggregated user data. In some embodiments, the user data aggregator server 320 may be included in a network device, such as the UDAS 111 in FIG. 1 .

The user data provider server 321 is configured to collect user data. In one embodiment, the user data provider server 321 may be configured to provide the collected user data to the user data aggregator server 320. In some embodiments, the user data aggregator server 320 may collect and/or provide unique user data and/or non-unique user data. In one embodiment, the user data aggregator server 320 may aggregate the collected user data. In some embodiments, the user data provider server 321 may be included in a network device, such as the UDSS 109 of FIG. 1 .

Overall operation

The operation of certain aspects of the present invention will now be described with respect to Figures 4-6. Figure 4 illustrates a logic flow diagram generally illustrating one embodiment of a process for resolving queries for user data and providing an overview of aggregated user data to a user data buyer. In some embodiments, process 400 of Figure 4 can be implemented by and/or executed on a single network device (such as network device 300 of Figure 3). In other embodiments, process 400 of Figure 4, or portions of process 400, can be implemented by and/or executed on multiple network devices, such as network device 300 of Figure 3.

After the start block, process 400 begins at block 402, which will be described in more detail below in conjunction with FIG5. Briefly, however, at block 402, user data about a plurality of users may be collected, aggregated, and indexed so that the user data can be searched. In some embodiments, the user data may be collected by one or more user data providers, such as UDSS 109 of FIG1 , and provided to a user data aggregator, such as UDAS 111 of FIG1 . In other embodiments, a user data aggregator (such as UDAS 111 of FIG1 ) may itself collect at least a portion of the user data.

Process 400 then continues to block 404, which will be described in more detail below in conjunction with FIG. 6 . Briefly, however, at block 404, a query against the indexed user data is parsed, and its results are provided in multiple subsets of the aggregated user data. In some embodiments, the query may be received from a user data purchaser. In other embodiments, the query may be provided by a user data aggregator. In at least one embodiment, the user data aggregator may provide pre-parsed results for the query to the user data purchaser. Process 400 continues at block 406, where the aggregated user data may be provided to the user data purchaser. In some embodiments, the aggregated user data may be provided to the user data purchaser in exchange for payment for the aggregated user data. In at least one of the various embodiments, the aggregated user data may include multiple aggregated subsets of non-unique user data. In at least one of the various embodiments, each aggregated subset of non-unique user data may include an identifier uniquely identifying the subset. In one embodiment, the aggregated user data may be sold, licensed, leased, and/or otherwise provided to the user data purchaser. In some embodiments, the aggregated user data may be provided to the user data purchaser under predefined restrictions. Such predefined restrictions may include, but are not limited to, using the aggregated user data for a predetermined amount of time, for a specific purpose (e.g., a specific targeted advertising campaign), etc. In one embodiment, each predefined restriction may be associated with a different payment amount from the user data buyer.

In some embodiments, each aggregated subset of non-unique user data may include general information about the users corresponding to the subset without uniquely identifying each individual user. In one non-exhaustive and non-limiting example, the subset of non-unique user data may indicate that there are 14 female users and 17 male users; seven users are lawyers and members of social media site 1; six users like fishing, 11 users like American football; one user is a teacher; and eight users use public transportation. In such an example, the subset of non-unique user data may not identify which users are both lawyers and like American football, whether the teacher uses public transportation, etc.

In other embodiments, each aggregated subset of non-unique user data may include a weight or other factor indicating the number of users associated with the subset that satisfy or are relevant to a query. For example, a query may be for female users who are lawyers in zip code 98101, aggregated by extended nine-digit zip code. Each aggregated subset of non-unique user data may correspond to a different extended nine-digit zip code within zip code 98101, and each subset may include a weight indicating the number of female users who are lawyers in that extended zip code.

In one embodiment, the weights may be values indicating the number of users within the aggregated subset that satisfy the query. In another embodiment, each weight may correspond to a range of users. For example, a weight of 0 may indicate that fewer than two users satisfy the query, a weight of 1 may indicate that two to five users satisfy the query, and so on. However, the present invention is not limited thereto, and other weights may be employed alone or in combination with other weights, scalars, formulas, and the like.

In any case, process 400 then continues to block 408, where the aggregated user data may be employed by the user data buyer for use in an advertising campaign. Such advertising may include, but is not limited to, targeted banner campaigns, text campaigns, sponsored search, video campaigns, direct mail, telemarketing, and the like. However, the present invention is not strictly limited to advertising; rather, the aggregated user data may be utilized for other purposes, such as, but not limited to, website application optimization, application personalization, general research, analytics, and the like. In one embodiment, multiple subsets of non-unique user data may be provided to the user data buyer for use in online advertising campaigns.

In one embodiment, the user data buyer may provide advertisements to users associated with one or more of a plurality of aggregated subsets of non-unique user data. The user data buyer may provide advertisements to users associated with the aggregated subsets based on the weights of the aggregated subsets. For example, the user data buyer may provide advertisements to users associated with an aggregated subset of non-unique user data that includes weights above a minimum threshold, such as 3 (assuming in this example that the weight range is from 0-5). However, the present invention is not limited thereto, and the user data buyer may provide advertisements to users based on other criteria, such as, but not limited to, other attributes associated with the aggregated user data, and the like. Next, after block 408, processing 400 returns to the calling process to implement other actions.

FIG5 illustrates a logic flow diagram generally illustrating one embodiment of a process for collecting and storing user data. In some embodiments, process 500 of FIG5 can be implemented by and/or executed on a single network device (e.g., network device 300 of FIG3 ). In other embodiments, process 500 of FIG5 , or portions thereof, can be implemented by and/or executed on multiple network devices (e.g., network device 300 of FIG3 ). In one embodiment, process 500 can be implemented by and/or executed on a user data provider and/or user data aggregator, such as UDSS 109 and/or UDAS 111 of FIG1 , respectively.

After the start block, process 500 begins at block 501 where user data may be received. The received user data may include user data about a plurality of users. In some embodiments, the user data may be provided directly by the user, such as user profile data, etc. In other embodiments, the user data may be received indirectly from the user, such as through the user's interaction with a website, etc. In some embodiments, a user may opt in and have user data collected about the user. In other embodiments, a user may opt out and not have user data collected about the user.

In some embodiments, the received user data may include unique user data, non-unique user data, and/or any combination thereof. In one embodiment, the unique user data may individually identify each user associated with the unique user data. In another embodiment, the non-unique user data may identify the user associated with the non-unique user data without identifying each individual user. In at least one of the various embodiments, the user data may be received from one or more user data providers, such as UDSS 109 of FIG. 1 .

Processing 500 continues at decision block 502, where a determination may be made as to whether the received user data is unique user data. In some embodiments, the user data may be unique if the user data identifies each individual user. In one embodiment, the unique user data may include a personal identifier for each individual user, such as a user's name, social security number, email address, device identifier, and the like. In another embodiment, the unique user data may not include a personal identifier, but may include multiple attributes that may be utilized to individually identify each user. For example, the unique user data may identify: User 1 is a male, 29 years old, and an accountant in zip code 98101; User 2 is a male, 34 years old, and a doctor in zip code 98101; User 3 is a female, 33 years old, and a doctor in zip code 98101; and so on. In this example, the user data may be unique because each individual user is individually identified by multiple attributes.

In other embodiments, if the user data corresponds to a group of users, the user data may be non-unique. In one embodiment, the non-unique user data may identify a group of users and general attributes about the group of users, but cannot uniquely identify each individual user. For example, the non-unique user data may identify 20 users with the extended zip codes 98101-1005. The non-unique user data may also include attributes about the group of users. For example, among the 20 users: six users are male, 14 users are female; two users are between 20-30 years old, and 18 users are between 30-40 years old; seven users are accountants, five users are doctors, and eight users are teachers. In this example, due to the lack of information that identifies each individual user (such as the age, gender, and occupation of each individual user), the user data may be non-unique user data.

If the user data is unique, process flow continues to block 504 ; otherwise, process flow continues to block 506 .

At block 504, unique user data may be aggregated. In one embodiment, unique user data may be aggregated into non-unique user data. In some embodiments, aggregation of unique user data may be optional. In at least one of the various embodiments, unique user data may be aggregated at one or more predetermined granularities. In some embodiments, the one or more predetermined granularities may be determined based on requirements of user data buyers, ease of resolving queries for user data, predetermined by a user data aggregator, and the like.

In some embodiments, unique user data may be aggregated by zip code, extended nine-digit zip code, one or more attributes, and/or any combination thereof. Continuing with the previous unique user data example, in one embodiment, unique user data may be aggregated by extended nine-digit zip code 98101-1005. In another embodiment, unique user data may be aggregated by age and gender. However, the present invention is not limited thereto, and other attributes associated with unique user data may be utilized to aggregate unique user data, such as, but not limited to, websites visited, items purchased, ads viewed, applications utilized, social media memberships, user's device information (e.g., device ID (e.g., region code), device capabilities, carrier, etc.), and the like.

In some embodiments, unique user data may be aggregated at multiple different granularities. In one embodiment, unique user data may be aggregated by zip code or by one or more attributes alone. In another embodiment, unique user data may be aggregated by a different set of attributes. Process flow then continues to block 508.

At decision block 502, if the received user data is non-unique user data, the flow of process 500 continues to block 506. At block 506, the non-unique user data may be aggregated. In at least one of the various embodiments, the non-unique user data may be aggregated in a manner similar to the aggregation of unique user data described at block 504. In one embodiment, the non-unique user data may be aggregated by zip code, extended nine-digit zip code, one or more common attributes, and/or any combination thereof. For example, one set of non-unique user data may include 20 female users between the ages of 20 and 30, seven of whom are doctors, nine of whom are teachers, and four of whom are accountants. Continuing with this example, another set of non-unique user data may include 10 female users between the ages of 20 and 30, eight of whom play golf and two of whom play softball. In this example, the two sets of non-unique user data may be aggregated into one set based on the common attributes of gender (female users) and age (users between the ages of 20 and 30).

In some embodiments, non-unique user data can be aggregated at multiple different granularities. In one embodiment, non-unique user data can be aggregated by zip code and separately aggregated by one or more attributes. In another embodiment, non-unique user data can be aggregated by a different set of attributes.

In any case, process 500 continues at block 508 where the aggregated user data is stored. In some embodiments, the aggregated non-unique user data and the aggregated unique user data may be combined, indexed, and stored together in a common database. In one embodiment, the aggregated user data may be grouped and stored by zip code, extended zip code, one or more common attributes, and/or any combination thereof. In other embodiments, the aggregated non-unique user data and the aggregated unique user data may be maintained and stored separately. In one embodiment, unique user data may not be aggregated and may be stored by individual user.

As previously mentioned, in at least one of the various embodiments, process 500 may be implemented by a user data provider to collect user data. In such an embodiment, the collected user data (i.e., aggregated non-unique user data, aggregated unique user data, and/or any combination thereof) may be provided to and stored at the user data aggregator for use in resolving queries.

FIG6 illustrates a logic flow diagram generally illustrating one embodiment of a process for resolving a query for user data by aggregating the user data based on the query to generate multiple subsets of non-unique user data. In some embodiments, process 600 of FIG6 can be implemented by and/or executed on a single network device, such as network device 300 of FIG3. In other embodiments, process 600 of FIG6, or portions thereof, can be implemented by and/or executed on multiple network devices, such as network device 300 of FIG3.

After the start block, process 600 begins at block 601 where a query for user data may be received. In one embodiment, the query may be received from a user data buyer. In another embodiment, the query may be determined by a user data aggregator. In some embodiments, the query may indicate the type of user data to be aggregated. In other embodiments, the query may be utilized to generate multiple aggregated subsets of non-unique user data. In at least one of the various embodiments, the query may include a zip code, an extended nine-digit zip code, one or more attributes, and/or any combination thereof. In some embodiments, a graphical user interface may be displayed to the user data buyer to allow the user data buyer to provide the query to the user data aggregator for subsequent searches on the aggregated user data.

In at least one of the various embodiments, a user data buyer may provide a query if the user data buyer pays for the aggregated user data. In some embodiments, the user data buyer may pre-purchase the aggregated user data before providing the query. In one embodiment, the user data buyer may pay per query, based on the size of the aggregated user data queried, based on the type of aggregated user data, based on a specific use of the aggregated user data, and so on.

In any case, processing 600 continues at decision block 602, where it can be determined whether the query includes one or more attributes for aggregating user data. In some embodiments, the attributes may include general attributes, such as, but not limited to, sports, travel interests, gender, age, and the like. In other embodiments, the attributes may include specific attributes, such as, but not limited to, male users, users who like American football, and the like. In one embodiment, a query may include general attributes and specific attributes. For example, a query may include five attributes, such as, but not limited to, male users, users who are members of social media site 1, users who use application AAAA, users who use application BBBB, and users who like American football. If user data can be aggregated by attributes, the processing flow continues to block 618; otherwise, the processing flow continues to decision block 604.

At block 618, user data may be aggregated by one or more attributes. Aggregating the user data may generate one or more subsets of non-unique user data. In one embodiment, if a query includes specific attributes, a single set of aggregated non-unique user data may be generated based on the query. Using the previous example, a single set of aggregated non-unique user data may be generated from the following attributes: male users, users who are members of social media site 1, users who use application AAAA, users who use application BBBB, and users who like American football. The resulting aggregated user data may indicate that, among the users who meet the query attributes, 20 users play hockey, 31 users are teachers, 45 users are members of social media site 2, and so on.

In other embodiments, if a query includes at least one general attribute, multiple aggregated subsets of non-unique user data may be generated based on the query. For example, if the query includes the general attribute "sports," the user data may be aggregated subsets such as, but not limited to, hockey, American football, soccer, etc. In one embodiment, each aggregated subset may include additional attributes about the users associated with that subset. For example, an aggregated subset corresponding to hockey may indicate that there are 15 male users, 14 female users, 5 doctors, and so on.

Processing continues at decision block 604, where a determination can be made as to whether the query includes a postal code. In one embodiment, the postal code can be a five-digit postal code or other location-based identifier. In some embodiments, the query can include a general request for postal codes and/or a specific request for one or more specific postal codes. If the query includes a postal code, processing flow continues at block 606; otherwise, processing flow continues at decision block 608.

At block 606, the user data may be aggregated by zip code. In some embodiments, if the query includes a specific zip code, a single set of aggregated non-unique user data may be generated based on the query. In other embodiments, if the query includes a general request for a zip code or multiple specific zip codes, multiple aggregated subsets of non-unique user data may be generated based on the query.

In some embodiments, user data may be aggregated into a set of aggregated user data based on one or more attributes, and then partitioned into subsets of non-unique user data based on zip code. In other embodiments, user data may be aggregated into a set of aggregated user data based on zip code, and then partitioned into subsets of non-unique user data based on one or more attributes.

Processing continues at decision block 608, where a determination can be made as to whether the query includes an extended ZIP code. In one embodiment, the query can include a general request for user data aggregated by extended ZIP code. In such an embodiment, multiple subsets of non-unique user data can be generated, each subset including aggregated user data corresponding to one or more extended ZIP codes. If the query includes a request for an extended ZIP code, processing flow continues at block 610; otherwise, processing flow continues at block 612.

At block 610, user data may be aggregated by extended ZIP code. In at least one of the various embodiments, aggregating user data by extended ZIP code may refer to grouping all user data associated with a particular extended ZIP code into a group without (i.e., independently) identifying individual users. In some embodiments, the extended ZIP code may be a five-digit ZIP code plus an additional four digits, also referred to as ZIP+4. In one embodiment, the additional four digits may identify a subset of addresses within the five-digit ZIP code. However, the present invention is not limited to ZIP+4, and other subdivision identifiers based on extended ZIP codes or locations, now known or later developed, may also be employed.

In some other embodiments, user data can be aggregated into a set of user data based on one or more attributes and/or zip code, and then subdivided into subsets of non-unique user data based on extended zip code. As previously described, in one embodiment, each subset of non-unique user data can include a weight indicating the number of users that satisfy the query. In some other embodiments, the extended zip code can be a non-unique identifier corresponding to a group of users associated with the corresponding subset of aggregated user data.

For example, a query may be for male users who are lawyers in zip code 98101, clustered by extended zip code. The user data may be clustered into a single group based on male users in zip code 98101 who are lawyers. The single clustered group may be subdivided into subsets of non-unique user data based on extended zip code, where each subset includes a weight based on the number of users that meet the query. As a result, 98101-1005 may have a weight of 12, 98101-1010 may have a weight of 0, 98101-1015 may have a weight of 25, and so on. In any case, the process flow may then continue to decision block 612.

Process 600 continues at decision block 612 where it is determined whether each aggregated subset of non-unique user data corresponds to at least a certain number of users that exceeds a threshold number of users. In some embodiments, the weight of an aggregated subset may be different from the number of users associated with the aggregated subset. For example, 49 users may be associated with an aggregated subset corresponding to the zip code extension 98101-1051, but the aggregated subset may have a weight of 5. In this example, a weight of 5 may indicate that, out of the 49 users, 5 users satisfy the received query (e.g., male users who like American football).

In some embodiments, the threshold number of users can be a predefined minimum threshold. In one embodiment, the predefined minimum threshold can be based on a privacy standard, such as 10 users in one non-limiting example. In some embodiments, the privacy standard can refer to the minimum number of users associated with a set of aggregated non-unique user data required to maintain the anonymity of each individual user. Such privacy standards can be defined by state and/or government laws and/or regulations, private companies and/or institutions, and the like.

In other embodiments, the threshold number of users may be based on an amount paid by a user data purchaser. In some embodiments, such a threshold may be referred to as a user-granularity purchase price. In one embodiment, a user data purchaser may purchase, rent, lease, and/or otherwise pay an amount corresponding to the number of users associated with the aggregated user data. In some embodiments, the threshold may be a range of users, such as, but not limited to, more than 20 users, between 20 and 100 users, and so forth.

In some embodiments, the threshold may correspond to the number of users associated with the aggregated user data as a whole. In other embodiments, the threshold may correspond to the number of users associated with each aggregated subset of non-unique user data. For example, a first price may be fixed for aggregated subsets corresponding to more than 10 users, a second price may be fixed for aggregated subsets corresponding to more than 20 users, a third price may be fixed for aggregated subsets corresponding to more than 100 users, and so on.

If each aggregated subset of non-unique user data corresponds to at least a certain number of users exceeding a threshold number of users, then process flow continues to block 614; otherwise, process flow continues to block 616. In one embodiment, if one of the aggregated subsets of non-unique user data corresponds to at least a certain number of users exceeding the threshold, then process flow may continue to block 614 for the subset of the aggregated subsets that corresponds to at least a certain number of users exceeding the threshold. Although not shown, the threshold value may be increased or decreased based on the requested granularity, i.e., the maximum number of anonymized users that may correspond to each subset of aggregated user data. However, a minimum threshold number of anonymized users is maintained to protect the privacy and anonymity of the users associated with each subset of aggregated user data.

At block 616, the user data buyer may be prompted to enter a new query. In some embodiments, the user data buyer may provide one or more new and/or additional attributes, another zip code, an extended nine-digit zip code, and/or any combination thereof. In one embodiment, if the initial query was determined by the user data aggregator, the user data aggregator may determine the new query. Process 600 then loops to decision block 602.

At decision block 612, if each aggregated subset of non-unique user data corresponds to at least a certain number of users exceeding a selectable threshold number of users, process flow continues to block 614. At block 614, the aggregated user data may be provided to a user data buyer. In some embodiments, block 614 may employ the embodiment of block 406 of FIG. 4 to provide the aggregated user data to a user data buyer. After block 614, process 600 returns to the calling process to perform other actions.

FIG7 illustrates a logic flow diagram generally illustrating an alternative embodiment of a process for collecting and storing user data. In some embodiments, process 700 of FIG7 may be implemented by and/or executed on a single network device, such as network device 300 of FIG3. In other embodiments, process 700 of FIG7 or portions of process 700 may be implemented by and/or executed on multiple network devices, such as network device 300 of FIG3.

After the start block, process 700 begins at block 701 where user data may be received. In one embodiment, block 701 may employ the embodiment of block 501 of FIG. 5 to receive user data.

Process 700 continues to decision block 702, where a determination may be made as to whether the received user data includes a unique identifier ("ID") corresponding to the user data. The unique ID may be generated by a user data aggregator, such as UDAS 111 of FIG. 1 , and provided to a user data provider, such as UDSS 109 of FIG. 1 . In some embodiments, UDSS 109 of FIG. 1 may include the unique ID when providing the user data to UDAS 111 of FIG. 1 . In at least one of the various embodiments, unique user data, non-unique user data, aggregated unique user data, aggregated non-unique user data, and/or any combination thereof may be associated with one or more unique IDs (e.g., user data from an extended nine-digit zip code 98101-1001 may be associated with a first unique ID and may also be associated with a second unique ID corresponding to zip code 98101).

In some embodiments, user data may include a unique ID based on a zip code, an extended nine-digit zip code, and/or one or more attributes. For example, user data corresponding to a male user of Application One from zip code 98101 may be associated with a first unique ID, and user data corresponding to a female user of Application One from zip code 03301 may be associated with a second unique ID. In another example, user data corresponding to a user of Application One may be associated with a third unique ID.

If the received user data includes a unique ID, process flow continues to block 712 ; otherwise, process flow continues to decision block 704 .

At decision block 704, a determination is made as to whether the received user data is unique user data. In at least one of the various embodiments, block 704 may employ the embodiment of block 502 of FIG. 5 to determine whether the received user data is unique user data. If the received user data is unique user data, the process continues at block 707; otherwise, the process continues at block 706.

At block 707 , unique user data may be aggregated. In at least one of the various embodiments, block 707 may employ the embodiment of block 504 of FIG5 to aggregate unique user data. Process flow then continues to block 708 .

At decision block 704, if it is determined that the received user data is not unique user data, then the process flow continues to block 706 where the non-unique user data may be aggregated. In at least one of the various embodiments, block 706 may employ the embodiment of block 506 of FIG. 5 to aggregate the non-unique user data.

Process 700 continues at block 708, where a new unique ID is generated for the aggregated user data. In at least one of the various embodiments, the new unique ID may be generated based on a zip code, an extended nine-digit zip code, a unique combination of one or more attributes, and/or any combination thereof. In some embodiments, multiple new unique IDs may be generated for the aggregated user data, where each new unique ID is based on a different combination of attributes, zip code, and/or extended nine-digit zip code.

Continuing to block 710, the new unique ID may be provided to the user data provider. In some embodiments, the new unique ID may be provided to the user data provider, such as UDSS 109, via email or the like.

Continuing at block 712, the user data can be stored under the unique ID. In one embodiment, block 712 can employ the embodiment of block 508 of FIG. 5 to store the user data. In some embodiments, the unique ID can be utilized to match user data from one user data provider to user data from another user data provider. For example, a first user data provider and a second user data provider can provide user data corresponding to a user in zip code 98101 under the same unique ID. After block 712, processing returns to the calling process to perform other actions.

FIG8 illustrates one embodiment of a use case, showing a system diagram of a system that can be utilized to collect user data from user data suppliers and provide aggregated user data to user data buyers. System 800 may include user data suppliers 801, user data suppliers 802, user data aggregators 803, and user data buyers 804. User data suppliers 801 and 802 may be user data suppliers such as UDSS 109 of FIG1 . User data aggregators 803 may be user data aggregators such as UDAS 111 of FIG1 .

The user data aggregator 803 may collect user data from the user data supplier 801 and the user data supplier 802 and provide the aggregated user data to the user data buyer 804 .

User data provider 801 may provide user data aggregator 803 with the following example of user data regarding users utilizing “Application One”: there are 100 male users from zip code 98101, 70 of whom like fishing and 60 of whom like American football. User data provider 802 may provide user data aggregator 803 with the following example of user data regarding users utilizing “Application Two”: there are 40 male users from zip code 98101, 25 of whom are teachers.

User data aggregator 803 can collect and store user data from user data providers 801 and 802. User data aggregator 803 can receive queries for user data from user data buyers 804. In one non-limiting example, the query can be for male users from ZIP code 98101, aggregated by nine-digit ZIP extension. User data aggregator 803 can use the query to aggregate the user data received from user data providers 801 and 802 into multiple aggregated subsets of non-unique user data, for example, by using process 600 of FIG. 6 . For example, subset 1, corresponding to ZIP extensions 98101-1005, can indicate that seven male users like fishing, six male users like American football, and two male users are teachers. Subset 2, corresponding to ZIP extensions 98101-1010, can indicate that two male users like soccer, three male users like American football, and so on.

The user data aggregator 803 may provide multiple aggregated subsets of non-unique user data to the user data buyer 804 if each aggregated subset corresponds to at least a certain number of users exceeding a predefined minimum threshold (eg, 10 users).

User data buyer 804 can use the aggregated user data to provide advertisements to users. For example, user data buyer 804 can provide fishing advertisements to users associated with subset 1 but not subset 2. In another example, user data buyer 804 can provide advertisements (e.g., advertisements related to fishing, soccer, American football, and/or teachers) to male users from zip code 98101 who utilize "App Three."

Profile noise anonymity

The operation of certain aspects of the present invention will now be described with respect to Figures 9-12. Figure 9 shows a logic flow diagram generally illustrating one embodiment of an overview process for determining direct and/or recommended attributes and including them in a user profile. In some embodiments, process 900 of Figure 9 can be implemented by and/or performed on a single network device, such as network device 300 of Figure 3. In other embodiments, process 900 of Figure 9 or portions of process 900 can be implemented by and/or performed on multiple network devices, such as network device 300 of Figure 3. In some embodiments, process 900 can be implemented for each of a plurality of users when providing data corresponding to a user (who in some embodiments may be referred to as a target user).

After the start block, process 900 begins at block 902, where data corresponding to a user may be provided. In some embodiments, the user data may be provided by the user, such as using a mobile device and/or other network device. In at least one embodiment, the network device may be known, such that the user data may be provided from a network device corresponding to the user profile. In some other embodiments, the user data may be provided by a third-party entity that collects and/or provides user data, such as a user data provider.

Process 900 continues at block 904 where at least one direct attribute corresponding to the user data may be determined. For example, if the user searches for Seattle Seahawks football tickets, one or more direct attributes may be determined including, but not limited to, that the user likes football, that the user lives in Seattle, that the user purchases sports tickets online, and so forth.

Direct attributes can be determined from the provided user data based on many different analytical tools and/or algorithms, including but not limited to classification tools, categorization tools, analysis tools, etc., or any combination thereof. In some embodiments, direct attributes can be determined by using these tools/algorithms to determine the type of user data, keywords in the user data, etc.

In at least one embodiment, one or more keywords within and/or associated with the user data may be identified. In at least one embodiment, the keywords may be used as direct attributes. For example, if a user searches for flowers, the keyword "flowers" may be identified and used as a direct attribute. In another embodiment, the keywords may be used to select one or more direct attributes from a list of attributes. The list of attributes may be static and/or dynamic. In one embodiment, the list of attributes may be predetermined by the operator and/or based on a simple set of attributes. In another embodiment, the list of attributes may change dynamically over time based on user data provided by multiple users.

In any case, processing 900 continues to block 906, where at least one recommended attribute can be determined. In some embodiments, the recommended attribute can be related to and/or associated with a direct attribute, which will be described in more detail below in conjunction with Figures 10 and 12. But in short, in one embodiment, the recommended attribute can be determined based on a mapping between multiple attributes corresponding to multiple users, which is achieved by using the direct attribute (as determined at block 904) to select the mapped recommended attribute. In another embodiment, the recommended attribute can be determined based on attributes of other users, and the characteristics of the other users can be similar to the user of the provided data. In other embodiments, the recommended attribute can be a random attribute. In at least one such embodiment, the generated random attribute can be used to determine the at least one recommended attribute.

Process 900 then continues to block 908, where the at least one direct attribute and the at least one recommended attribute may be included in the user's profile. In at least one embodiment, the direct attributes and the recommended attributes may be stored in the profile so that they are indistinguishable in the profile as to whether they are provided or recommended for the user. In some embodiments, the attributes may be stored in the profile without any labels, tags, descriptors, and/or other identifiers that indicate where and/or how the attributes are obtained (i.e., whether they are provided or recommended). Therefore, a person viewing the profile may not be able to infer which attributes are direct attributes and which attributes are recommended attributes. For example, after a user searches for Seattle Seahawks American football tickets, the user's profile may include the following attributes: user likes American football, user likes Seattle Seahawks, lives in Seattle, user likes Seattle Mariners baseball team, user has purchased barbecue grills, and user purchases sports memorabilia. However, the profile may exclude an indication of which attributes are direct attributes and which attributes are recommended attributes.

In some embodiments, at least a portion of the profile of one or more users may be provided to a user data buyer, as described in more detail above with respect to FIG. 4 . In short, however, a user data buyer may provide a query for relevant user attributes. Multiple users may be determined based on the query. In at least one embodiment, the multiple users may be determined based on a comparison of the query with attributes in the user profiles, employing the embodiments described above, and so forth. The results of the query may be provided to the user data buyer. In some embodiments, the results may include at least a portion of the profile of each of the multiple users determined based on the query. In at least one embodiment, the portion of the profile of each of the multiple users (i.e., the results) may be used in an online advertising campaign.

In any case, after block 908, process 900 may return to the calling process to perform other actions. In some other embodiments, process 900 may loop (not shown) back to block 902 to provide additional data corresponding to the user (and determine and include additional direct attributes and/or recommended attributes in the user's profile).

FIG10 shows a logic flow diagram generally illustrating one embodiment of a process for determining recommended attributes based on a mapping between attributes. In some embodiments, process 1000 of FIG10 can be implemented by and/or executed on a single network device, such as network device 300 of FIG3. In other embodiments, process 1000 of FIG10 or portions of process 1000 can be implemented by and/or executed on multiple network devices, such as network device 300 of FIG3.

After the start block, process 1000 begins at block 1002, which is described in more detail below in conjunction with FIG. 11 . Briefly, however, at block 1002, a mapping between multiple attributes may be generated. In at least one embodiment, the mapping may occur between multiple attributes corresponding to multiple users with a predetermined degree of separation. In some embodiments, a table or other suitable data structure may be utilized to map the attributes to each other. An embodiment of a use case diagram for mapping between multiple attributes is described in more detail below in conjunction with FIG. 13 .

In some embodiments, the mapping may be a general mapping corresponding to all users. In other embodiments, different subsets (i.e., groups) of users may be associated with different mappings. For example, users in New York City may be associated with one mapping, while users in Seattle (Washington) may be associated with a different mapping. In some embodiments, the use of different mappings may allow more relevant recommended attributes to be determined for a user compared to a general mapping applied to all users. For example, a user in New York City may be more likely to buy basketball tickets if they buy American football tickets than a user in Seattle, because Seattle does not have a basketball team. However, the embodiments are not limited thereto, and in fact any appropriate number of user mappings and/or groupings may be used.

In any case, process 1000 continues at block 1004 where data corresponding to the user may be provided. In at least one embodiment, block 1004 may employ the embodiment of block 902 of FIG. 9 to provide user data.

Process 1000 then continues to block 1006 where at least one direct attribute corresponding to the user data may be determined. In at least one embodiment, block 1006 may employ the embodiment of block 904 of FIG. 9 to determine at least one direct attribute.

Process 1000 then continues at block 1008, where at least one recommended attribute may be determined using the mapping of attributes (as generated at block 1002). In at least one embodiment, the at least one recommended attribute may correspond to and/or map to the at least one direct attribute determined at block 1006. For example, if the attribute "flower" maps to the attribute "chocolate" and the direct attribute determined for the user is "flower," then the recommended attribute for the user may be "chocolate."

Process 1000 continues to block 1010 where the at least one direct attribute and the at least one recommended attribute may be included in the user's profile. In at least one embodiment, block 1010 may employ the embodiment of block 908 of FIG. 9 to include attributes in the user's profile.

Process 1000 continues at decision block 1012 where a determination can be made as to whether the mapping can be updated. In some embodiments, this determination can be based on a selection (e.g., made by an operator) to dynamically change attribute mappings. In at least one embodiment, the mapping can be updated to include mappings between recommended attributes and other attributes in the user profile, and/or mappings between direct attributes and other attributes in the user profile.

For example, suppose the system identifies the direct attribute "chocolate" and the recommended attribute "rent a limousine." Furthermore, suppose the user's profile includes the attribute "flowers." In this example, the mapping can be updated to include an association between the attributes "chocolate" and "flowers," as well as an association between the attributes "rent a limousine" and "flowers."

If the attribute map can be updated, process 1000 may loop to block 1002 ; otherwise, process 1000 may loop to block 1004 .

FIG11 illustrates a logic flow diagram generally illustrating one embodiment of a process for generating a mapping between multiple attributes. In some embodiments, process 1100 of FIG11 may be implemented by and/or executed on a single network device, such as network device 300 of FIG3. In other embodiments, process 1100 of FIG11 or portions of process 1100 may be implemented by and/or executed on multiple network devices, such as network device 300 of FIG3.

After a start block, process 1100 begins at block 1102, where a sample set of users may be determined. Each user in the sample set may have a corresponding profile, which may include multiple attributes. In at least one embodiment, the sample set of users may be a random subset of all users in the system. In another embodiment, the sample set of users may be a predetermined set of users. In some other embodiments, the sample set of users may be a set of users whose profiles each include a minimum number of identical attributes.

Process 1100 continues to block 1104 where a user can be selected from the sample set of users. In some embodiments, the user can be selected randomly, in a predetermined order, or the like.

Process 1100 then continues to block 1106 where a first attribute of the selected user may be selected. In some embodiments, the first attribute may be selected randomly, in a predetermined order (e.g., alphabetically, by attribute identifier, etc.), or the like.

Process 1100 then continues to block 1108, where a second attribute of the selected user may be selected. In some embodiments, the second attribute may be selected randomly, in a predetermined order (e.g., alphabetically, by attribute identifier, etc.), etc. In other embodiments, the second attribute may be selected based on a scheme that maps each attribute in a user profile to each other attribute in the user profile.

In at least one of the various embodiments, the second attribute can be selected based on the category of the first attribute and the category of the second attribute. For example, if the first attribute is categorized as "sports", an attribute of the selected user that is also categorized as "sports" can be selected as the second attribute. In some embodiments, each attribute can be grouped into one or more attribute categories (and/or subcategories). In a non-limiting, non-exhaustive example, attributes can be categorized as sports, health and beauty, travel, etc. In at least one embodiment, by adopting attribute categories (and/or subcategories), the system can increase the mapping between related attributes while reducing the mapping of irrelevant attributes. In at least one embodiment, each attribute can be associated with one or more categories.

Continuing to block 1110, the second attribute can be mapped to the first attribute. In at least one of various embodiments, mapping the second attribute to the first attribute can include, for example, associating the two attributes in an attribute mapping table or other appropriate data structure. In some embodiments (not shown in Figure 11), more than two attributes can be mapped together.

In any case, process 1100 continues to decision block 1112, where a determination can be made as to whether another second attribute should be mapped to the first attribute. In some embodiments, this determination can be based on the number of attributes associated with the selected user's profile. In at least one embodiment, the selection of second attributes can continue until the first attribute has been mapped to every other attribute in the selected user's profile. If another second attribute can be mapped to the first attribute, process 1100 can loop back to block 1108 to select another second attribute; otherwise, flow of process 1100 can continue to decision block 1114.

At decision block 1114, a determination can be made as to whether another first attribute should be selected. In some embodiments, this determination can be based on the number of attributes associated with the selected user's profile. In at least one embodiment, the selection of first attributes can continue until every attribute in the selected user's profile is mapped to every other attribute in the selected user's profile. If another first attribute can be selected, process 1114 can loop back to block 1106 to select another first attribute; otherwise, process 1100 can continue to decision block 1116.

In decision block 1116, a determination may be made as to whether another user should be selected for attribute mapping. In at least one embodiment, if another user with unmapped attributes exists in the sample set of users, then another user may be selected. If another user can be selected, process 1100 may loop back to block 1104; otherwise, process 1100 may return to the calling process to perform other actions.

Although FIG11 describes an iterative process for mapping attributes for each individual user, embodiments are not limited thereto. For example, in some other embodiments, if two or more user profiles include the same attributes, the attributes may be mapped together. For example, if two user profiles from a sample set of users include both "baseball" and "American football," "baseball" may be mapped to "American football."

FIG12 illustrates a logic flow diagram generally illustrating one embodiment of a process for determining recommended attributes for a user based on attributes of other similar users. In some embodiments, process 1200 of FIG12 may be implemented by and/or executed on a single network device, such as network device 300 of FIG3. In other embodiments, process 1200 of FIG12 or portions thereof may be implemented by and/or executed on multiple network devices, such as network device 300 of FIG3.

After the start block, process 1200 begins at block 1202 where data corresponding to a target user may be provided. In at least one embodiment, block 1202 may employ the embodiment of block 902 of FIG. 9 to provide user data.

Process 1200 continues to block 1204 where at least one direct attribute corresponding to the user data may be determined. In at least one embodiment, block 1204 may employ the embodiment of block 904 of FIG. 9 to determine the at least one direct attribute.

Process 1200 then continues at block 1206, where at least one other user similar to the target user may be determined. In some embodiments, the other users determined to be similar to the target user may be those users whose profiles are most similar to the target user's profile. In at least one embodiment, a profile of each of the plurality of other users (where each profile includes at least one attribute) may be compared to the target user's profile. In some embodiments, a comparison algorithm (or other scoring metric) may be employed to determine a score for each of the plurality of other users based on the corresponding profile and the target user's profile.

Based on the score of each of the multiple other users, a subset of the multiple other users can be determined. In some embodiments, the size of the subset of other users (i.e., the number of users) can be a predetermined number of users, such as 10 users. However, the size of the subset of other users can be modified based on determining the possible relevance of the recommended attributes to the target user. In some embodiments, a smaller subset of other users (e.g., five users) can allow recommended attributes that are more relevant to the target user compared to a larger subset of other users (e.g., 20 users). However, the embodiment is not limited to this. For example, in other embodiments, the subset of other users can be determined based on the scores of other users that are above a certain threshold. In some embodiments, the threshold can be predetermined, modifiable, and the like.

In any case, process 1200 then continues to block 1208 where at least one recommended attribute may be determined based on the attributes of other similar users. In at least one embodiment, the at least one recommended attribute may be an attribute in the profiles of a subset of the other users.

Process 1200 continues at decision block 1210, where a determination can be made as to whether the recommended attribute is in the target user's profile. In at least one embodiment, this determination can be based on a comparison of the at least one recommended attribute with attributes currently in the target user's profile. In some embodiments, some recommended attributes can be in the target user's profile, and other recommended attributes may not be in the target user's profile. If the recommended attribute is in the target user's profile, flow of process 1200 can continue to block 1214; otherwise, flow of process 1200 can continue to block 1212. In at least one embodiment, block 1212 can be employed for each recommended attribute that is not in the target user's profile.

At block 1212, the at least one recommended attribute may be included in the target user's profile. In at least one embodiment, block 1212 may employ the embodiment of block 908 of FIG. 9 to store the recommended attribute in the target user's profile so that it is indistinguishable from other attributes with respect to whether the attribute is provided or recommended for the user.

Process 1200 continues to block 1214, where the at least one direct attribute may be included in the target user's profile. In at least one embodiment, block 1214 may employ the embodiment of block 908 of FIG. 9 to store the direct attribute in the target user's profile, thereby making it indistinguishable from other attributes with respect to whether the attribute is provided or recommended for the user.

After block 1214, process 1200 can return to the calling process to perform other actions.

It should be understood that each square block of the flowchart diagram and the square block combination in the flowchart diagram can be implemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, so that the instructions executed on the processor produce a device for implementing the action specified in one or more flowchart square blocks. The computer program instructions can be executed by the processor so that a series of operating steps are implemented by the processor to produce a computer-implemented process, so that the instructions executed on the processor provide steps for implementing the action specified in one or more flowchart square blocks. The computer program instructions can also be implemented in parallel at least some of the operating steps shown in the square block of the flowchart. In addition, some of these steps can also be implemented on more than one processor, such as the situation that may occur in a multi-processor computer system. In addition, without departing from the scope or spirit of the present invention, one or more square blocks or square block combinations in the flowchart diagram can also be implemented simultaneously with other square blocks or square block combinations, or even implemented according to a sequence different from that shown.

Thus, the blocks of the flowchart illustration support a combination of means for implementing the specified actions, a combination of steps for implementing the specified actions, and program instruction means for implementing the specified actions. It should also be understood that each block of the flowchart illustration and the combination of blocks in the flowchart illustration can be implemented by a dedicated hardware-based system that implements the specified actions or steps, or by a combination of dedicated hardware and computer instructions. The foregoing examples should not be interpreted as limiting and/or exhaustive, but rather as illustrative uses to illustrate at least one implementation of the various embodiments of the present invention.

Example usage of mapped attributes

Figure 13 shows an embodiment of a use case, wherein a mapping between multiple attributes corresponding to multiple users is shown. As shown, multiple users (e.g., users 1302-1305) can each have a corresponding profile, such as profile 1310. Profile 1310 can include one or more attributes corresponding to the corresponding user. Profile 1310 can store attributes so that the attributes are indistinguishable as to whether they correspond to the user's direct attributes or the user's recommended attributes. As shown, profile 1310 corresponding to user 1302 can include the attributes "American football," "living in Seattle," and "traveling to New York."

Table 1308 may be one embodiment of a mapping between multiple attributes corresponding to multiple users. Attributes 1312 and 1314 may include each attribute included in the profiles of users 1302-1305. Within each cell in table 1308, an "X" may indicate that the corresponding attribute 1312 and the corresponding attribute 1314 are mapped (i.e., associated) together.

In at least one embodiment, if two attributes are included in the same profile, they can be mapped to each other. For example, profile 1310 corresponding to user 1302 includes the attributes "American football" and "lives in Seattle." Therefore, table 1308 can include a mapping from "American football" to "lives in Seattle" (labeled 1316) and from "lives in Seattle" to "American football" (labeled 1318). In other embodiments (not shown), if two attributes are included in more than one profile, they can be mapped to each other.

In some embodiments, table 1308 can be used to determine at least one recommended attribute based on the direct attribute (at block 1008 of FIG. 10 ). For example, to determine at least one recommended attribute using table 1308, attribute 1312 can be a direct attribute and attribute 1314 can be a recommended attribute. For example, assume that user 1305 searches for baseball memorabilia. The system can determine "baseball" as a direct attribute corresponding to user 1305 (at block 1006 of FIG. 10 ). The column associated with "baseball" (among attributes 1312) can be used to determine the corresponding mapped attribute. As shown, "baseball" is mapped to "American football," which can be used as the at least one recommended attribute. Accordingly, "American football" and "baseball" can be added (not shown) to the profile of user 1305.

The above specification, examples and data provide a complete description of the structure, manufacture and use of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims (16)

1. A computer-implemented method, comprising: Collect user data associated with multiple user devices, the user data being collected from one or more data sources, and the user data representing one or more interactions between the user devices and a website; Each of a first user profile and a second user profile is generated based at least in part on the collected user data, the first user profile corresponding to at least one first direct attribute of a first characteristic indicating a first interaction between a first user device and a first website, and the second user profile corresponding to at least one second direct attribute of a second characteristic indicating a second interaction between a second user device and a second website. An association is determined between the at least one first direct attribute and the at least one second direct attribute, the association being determined based on a comparison between the first characteristic of the first interaction and the second characteristic of the second interaction; In response to determining that the association exists, the at least one second direct attribute is automatically determined to be a recommended attribute for the first user profile; A mapping table is maintained at the server location in a non-transitory computer-readable medium at the computing device location. The mapping table includes multiple entries, at least one of which represents an association between at least one first direct attribute and a recommended attribute of a first user profile. Each of one or more other entries corresponds to an association between a direct attribute of a user profile and a recommended attribute determined from a direct attribute of another user profile. The mapping table is populated using at least collected user data. Receive a query for a user profile from the user data requester, the query including at least one target attribute for querying the target user; The collected user data is processed in response to the query in the following ways: Use the at least one target attribute to query the collected user data; Generate a dataset as query results, the dataset comprising one or more subsets of the dataset, each subset of the dataset comprising one or more user profiles associated with the at least one target attribute, and a particular subset of the dataset comprising the first user profile; For each subset of the dataset, a weight is calculated using the number of user profiles included in the subset, the weight representing the number of user profiles included in the subset, and the weight can be used by the user data requester to determine the content to be delivered to the user. The determination that the first user profile includes unique user data that uniquely identifies a user associated with the first user profile causes the server to prevent the transmission of the dataset in response to the query; In response to determining that the first user profile includes unique user data, a mapping table is accessed to select one or more recommended attributes to mask the unique user data; The mapping table is used to determine the association between the recommended attribute and the at least one first direct attribute; The first user profile is automatically modified by adding the recommended attributes to it. The modified first user profile corresponds to each of the at least one first direct attribute and the recommended attributes. Modifying the first user profile provides anonymity for the first user device by adding noise to the first user profile, and the noise masks the unique user data. In response to the query, the dataset is sent to the user data requester. The dataset includes the modified first user profile, which includes each of the at least one first direct attribute and the recommended attribute. Each of the at least one first direct attribute and the recommended attribute is stored within the first user profile without any identifier indicating whether an individual attribute is a direct attribute or a recommended attribute. The at least one first direct attribute and the recommended attribute are indistinguishable in the modified first user profile as being provided for or recommended for the first user device. The modified first user profile provides anonymity to the user by including attributes of other users in the first user profile. Receiving the dataset enables the user data requester to select content based on weights associated with the specific subset and send the selected content to the first user device associated with the first user profile. 2. The computer-implemented method according to claim 1, wherein determining the recommendation attribute further includes: The recommended attribute corresponding to the at least one first direct attribute is determined by employing a mapping between multiple attributes of multiple users having a determined degree of separation from the first user device. 3. The computer-implemented method according to claim 1, wherein determining the recommendation attribute further includes: The subset of said plurality of user devices is determined by rating at least each of the plurality of user devices based at least on a profile associated with each of the subset of said plurality of user devices. 4. The computer-implemented method according to claim 1, wherein determining the recommendation attribute further includes: The recommended attributes are determined using a random attribute generator. 5. The computer-implemented method according to claim 1, further comprising: Provides queries targeting relevant user attributes; Multiple users are identified based on the query; and Provide query results that include at least a portion of the profile of each of the plurality of users. 6. The computer-implemented method according to claim 5, wherein providing the result further includes: At least a portion of the profile of each of the plurality of users is used for online advertising campaigns. 7. A method for providing relevant user data via a network device in response to a query, comprising: The network device described above is used to collect unique and non-unique user data about multiple users from multiple sources; The network device is used to aggregate the collected user data and index the aggregated user data; In response to the query, multiple relevant subsets of aggregated unique and non-unique user data corresponding to relevant portions of the plurality of users are determined, wherein the number of users in each portion is greater than a threshold to provide anonymity for each user in that portion, and wherein the threshold is increased or decreased based on the requested granularity; and The results provide multiple subsets of determined non-unique user data corresponding to the portions of the multiple users. 8. The method of claim 7, wherein providing the result further comprises using the non-unique user data for use in online advertising campaigns. 9. The method of claim 7, wherein the aggregation operation further comprises aggregating the collected user data based on at least one of a postal code, an extended nine-digit postal code, and an attribute of the user data. 10. The method of claim 7, wherein the query is provided from at least one of the user data purchaser and the aggregator device for the collected user data. 11. The method of claim 7, wherein each of the plurality of subsets includes a weight of the relevance of each subset of non-unique user data to the query. 12. The method of claim 7, further comprising determining a minimum subset of the plurality of users, providing anonymity for each individual user within that subset. 13. The method of claim 7, further comprising: Based on the results, the increase in purchaser payments selectively reduces the size of individual portions of the user data subsets among the plurality of users; and The reduction in payments made by buyers based on the results selectively increases the size of individual portions of the user data corresponding to the subsets of user data among the plurality of users. 14. The method of claim 7, further comprising providing a unique anonymous identifier for each user data source, wherein the source reuses the identifier to subsequently provide unique user data for a unique user over time. 15. A system for managing data via a network, comprising: At least one network device, including: A memory device that operates to store at least instructions; and The operation is to execute the instructions to implement the method according to any one of claims 1-14. 16. A processor-readable non-transitory storage medium comprising instructions for managing data over a network, wherein the method according to any one of claims 1-14 is implemented by the processor executing the instructions.