Sharing Personalized Entities among Personal Digital Assistant Users

Abstract

Embodiments of the present disclosure relate to sharing personalized entities between personal digital assistant users. An architecture enables users to specify acceptance to receive social cards from other users in a social network using a personal digital assistant. A mapping component maintains a mapping and acceptance level of all users who have accepted to participate in card sharing. A whitelist of users can be created, which lists users to whom social cards can be sent from an endpoint. Users can dynamically create local groups on a local endpoint at runtime, where local groups enable sharing personalized content with multiple users simultaneously. Shared cards are selected by the sending user and can become available on the recipient's PDA's home canvas along with other cards. Based on the user's engagement history, these cards can be sorted among other cards, social or non-social PDA cards. Merging, push notifications, and filtering are also provided.

Description

[0001] This application is a divisional application of the invention patent application with an international filing date of February 28, 2017, which entered the Chinese national phase on September 6, 2018, with Chinese national application number 201780015757.X and invention name “Sharing personalized entities between personal digital assistant users”. Technical Field

[0002] The present invention relates to the field of computers, and more particularly to sharing personalized entities among personal digital assistant users. Background Art

[0003] The social interaction capabilities of social networks are a primary motivation for users to join such social networks. Social interaction, which can include sharing of content, is an important aspect of user social interaction. However, existing solutions do not provide a single solution that enables users to share personalized information across all content types and from all possible sources. Summary of the Invention

[0004] The following is a simplified overview to provide a basic understanding of some of the novel implementations described herein. This overview is not an extensive overview and is not intended to identify key / critical elements or delineate its scope. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that will be presented later.

[0005] The disclosed architecture enables a new channel for social networking of personalized entities (content) created and consumed by endpoint personal digital assistants (PDAs). The architecture is a one-stop solution for enabling sharing (sending and receiving) of all types of content from all possible sources between users. Shared entities are personalized, and therefore, the entities a user shares (sends) with other shared users (receives) are entities for (and personalized to) the sharing user.

[0006] The architecture enables a user of a PDA to subscribe to receive one or more personalized entities from other users' contact lists as social cards, and then share the social cards with another user (or users) who choose to enable acceptance of social cards from the sharing user.

[0007] The architecture can be implemented as a system including a remote (separate component or service on a network accessible by multiple different endpoints) subscription component configured to enable subscription (registration) of endpoints to participate in sharing of instances of Personalized Related Entities (PEs) (also known as social cards). Endpoints can be any type of device, such as desktop computing devices, mobile devices (e.g., cellular phones), tablet computers, laptop computers, etc. Sharing of Personalized Related Entities can be done via a PDA (e.g., a PDA such as Microsoft Corporation's Cortana) of the corresponding endpoint. TM etc. intelligent interactive PDA) to execute.

[0008] That is, in an example where a second endpoint subscribes to receive personalized related entities from a first endpoint, the second endpoint includes a second PDA via which the disclosed architecture for social card acceptance is participated in via a remote subscription component. In this example, a second (or receiving or accepting) user of the second endpoint subscribes to receive / accept personalized related entities (P-E1) from a first user of the first endpoint or multiple other users of other corresponding endpoints.

[0009] Within the contemplation of the disclosed architecture, subscriptions may include various levels that enable subscribing users to select different levels of subscription. For example, subscription levels may include send-only, receive-only, or send and receive. Furthermore, subscriptions may be defined, for example, based on sending to / receiving from specific users and user groups. Thus, while subscriptions are described herein as opting in to receiving social cards, it should be understood that subscriptions may be configured to include one or more of these additional subscription levels.

[0010] For example, an endpoint subscription can be performed to indicate that the endpoint is contracted to receive one or more entities from any user or only from one or more specific users. Once the subscription of a subscribing endpoint is complete, other users defined in the (receiving) contacts who share entities with the subscribing endpoint can send personalized entities to the subscribing endpoint.

[0011] It will be appreciated that accepting sharing of entities from other users (endpoints) or sharing entities with other users has the effect of socially boosting inferred information about the user (e.g., likes, dislikes, preferences, etc.). When a sharing user has sent an entity to a receiving user, based on how the receiving user interacts with the entity, the PDA may learn new personal preferences about the receiving user and may be configured to automatically send similar entities to the receiving user in the future.

[0012] A mapping component (a component or service on a network) may be provided that communicates with a remote subscription component and is configured to enable creation and maintenance of a mapping as part of the subscription process, defining (mapping) acceptance between endpoints shared by the subscribing entities, and securely storing (acceptance) the mapping. The mapping component may also store acceptance levels, such as to accept from all other users, only from a contact list, only from family (e.g., inner circle), and the like. The mapping component may be configured to enable access by the subscription component to check the (social) status of an endpoint (or endpoint user) via the mapping. The status requested or identified may be whether the endpoint (user) is online, available, subscription accepting, temporarily not accepting the entity, and the like.

[0013] Each endpoint may include a local subscription interface that communicates with a remote subscription component to handle notifications, endpoint status information, endpoint subscriptions, mappings, etc. The local subscription interface may be a module that is part of the client device PDA, or a module that is separate from the PDA but is used to perform at least the functions of the PDA and the disclosed architecture described above.

[0014] The remote subscription component may be configured to enable delivery of notifications to the second endpoint (via the second endpoint's local subscription interface) that are shared by the first endpoint and that personalize the relevant entity (P-E1) waiting to be received by the first endpoint or have been received by the first endpoint.

[0015] The remote subscription component may be configured to enable merging of duplicate instances of personalization related entities. Thus, identical or similar (by some measurable parameter) PEs sent from the first endpoint and other sending endpoints are eliminated so that only a single PE (P-E1) is received by the second endpoint.

[0016] The subscription component may be configured to enable filtering of personalized related entities based on current user interests, and further configured to synchronize user-created local groups between endpoints based on a one-to-many endpoint mapping relationship.

[0017] The mapping component can be configured to generate a whitelist for a shared endpoint (first endpoint). The whitelist identifies endpoints that are suitable for receiving personalized related entities from the shared endpoint (first endpoint). The whitelist can be generated for the first endpoint by the mapping component, or a first user of the first endpoint can generate the whitelist at the first endpoint. In this first scenario, the first user can request a list of all mapped users (receiving users) of the first user. The list can then be downloaded to the first endpoint for the first user to make any required edits to remove one or more users. In this latter case, the whitelist is therefore never present at the mapping component, but is created and resides on the first endpoint.

[0018] The subscription component can be configured to enable a sorted group of valid endpoints from which personalized related entities are received, as defined in the mapping component. The sorted groups can have different sharing designations. For example, when identifying users who are allowed to share their PEs, these users can be distinguished by groups such as "inner circle" users and "outer circle" users. Thus, as is commonly understood, inner circle sharing users can be those users who are considered to have more influence on the receiving user relative to outer circle users who have less influence on the receiving user. Personalized related entities can be visually represented as cards visible in the personal digital assistant's card canvas, and the cards can be sorted according to the user's card engagement history. The engagement history can be analyzed to understand, for example, how often the receiving user will interact with (e.g., view, view within a specific time period, respond, etc.) a PE from a given user or user group.

[0019] The disclosed architecture can be implemented as a method of: discovering entities related to a first user; generating personalized related entities for the first user from the discovered related entities; and sharing the personalized related entities with a second user of a social network via a personal digital assistant of the first user and a personal digital assistant of the second user.

[0020] The disclosed architecture can be implemented as an alternative method, which: discovers entities related to a first user; generates personalized entities for the first user from the discovered related entities; creates an acceptance mapping between the first user and a second user; sends a notification of sharing the personalized entity to a personal digital assistant of the second user; and shares the personalized entity with the second user via the personal digital assistant based on the second user's acceptance of receiving the personalized related entity of the first user on a social network.

[0021] To accomplish the foregoing and related ends, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects are indicative of various ways in which the principles disclosed herein may be practiced, and all aspects and equivalents thereof are intended to be within the scope of the claimed subject matter. Additional advantages and novel features will become apparent from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 A system in accordance with the disclosed architecture is shown.

[0023] Figure 2 A detailed alternative system for enabling a social platform for sharing of personalized entities among personal digital assistant users is shown.

[0024] Figure 3 An exemplary user-accepted generic pseudo mapping generated and stored by a mapping component is shown.

[0025] Figure 4An exemplary whitelist of whitelist entries and whitelist functionality according to the disclosed architecture is shown.

[0026] Figure 5 A method according to the disclosed architecture is shown.

[0027] Figure 6 An alternative approach according to the disclosed architecture is shown.

[0028] Figure 7 A block diagram of a computing system that performs card sharing via a personal digital assistant in accordance with the disclosed architecture is shown. DETAILED DESCRIPTION

[0029] The disclosed architecture helps users share personalized proactive cards with each other using a personal digital assistant (PDA). The PDA discovers or is used to discover the user's most relevant content (entities), proactively taking into account the user's likes and dislikes, and the user shares this personalized content with family and friends in the user's social circle. The disclosed architecture is a one-stop solution for sharing all types of content from all possible sources between users. The content itself can be personalized, and therefore, the content shared by a sharing user with another (receiving) user is specific to the sharing user. In the sharing user's view, the shared content is the sharing user's view of some common content category.

[0030] The disclosed architecture at least solves the problem of people contacting a dynamically generated group of people and sharing content that is not available to the group of people or that the user has never personalized for the group of people. For example, user X is about to take a flight and the flight is currently delayed. A PDA (e.g., such as Microsoft's Cortana) can TM The user then uses a smart interactive PDA (e.g., a PDA) to find this information and present this information to the user along with other relevant information on the user's personalized (PDA) canvas. Subsequently, the user wants to update this information to the user's spouse.

[0031] Current popular ways of solving this problem include calling a spouse, or sending a text message (e.g., SMS (Short Message Service), MMS (Multimedia Messaging Service), WhatsApp message, etc.) In other words, using existing systems, the user must repeat everything that is presented to the user on the PDA "card" through the communication channel.

[0032] The disclosed architecture addresses this existing obstacle by enabling easy sharing of personalized content, which becomes personalized content that is then sent to recipient users with whom the content is desired to be shared.

[0033] In general, the disclosed architecture enables users to specify (subscribe) to receive personalized, relevant entities implemented as social cards, for example, from the user's contact list. This can be further extended with the concept of a user's social circles, where the user can choose to receive cards only from "inner" circle friends, or from both inner and outer circle friends. In this example, inner circle friends can include spouse and children. Outer circle friends can include users who are less interested in the user's flight. It should be understood that shared user categories can be more than just inner and outer circles. For example, a user category can be a group of employees, a group of family members, a group of users interested in a common topic, and so on, thus allowing for many types of users and user groups.

[0034] Accepting users who subscribe to the exposed schema can also employ additional features such as blocking users or content categories. A storage (mapping) component maintains a map of all users who have accepted (registered, subscribed) to the exposed schema. The map of all users becomes a universal map that is securely protected from unauthorized access (e.g., public) and can be queried. A whitelist of users can be created, listing users to whom social cards can be sent from an endpoint. The whitelist can be generated from the mapping component based on all users who have consented to receive content from other users.

[0035] Users can dynamically create local groups at runtime on their local endpoints, enabling the simultaneous sharing of personalized content with multiple users. These groups can be synchronized across all user devices. Shared cards become available on the recipient's PDA's home screen alongside other cards. Based on user engagement history, these cards can be ranked among other social or non-social PDA cards.

[0036] Multiple users willing to share the same or similar social cards with a user can cause a single user to be flooded with unwanted cards. Merging prevents the recipient (receiving user) canvas from being flooded with the same or similar social cards from multiple other sharing users. Notifications of shared cards can be pushed to the recipient user endpoint. Additionally, card filtering can be provided based on the current interests of the shared user. The disclosed architecture can optionally or be configured to filter shared content, or in some cases, enable the shared user to see the interests of the sharing user.

[0037] As used herein, an entity can be defined as having distinct, independent existence, such as a person, movie, restaurant, event, book, song, album, or place of interest. Each entity can have a name and a set of other attributes that describe it.

[0038] The disclosed architecture demonstrates technical advantages rooted in computer technology for overcoming problems typically encountered in the field of computer systems and networks. More specifically, the architecture enables improved user efficiency in delivering (sending / receiving) personalized content (information) to other users. Because social cards are automatically created and delivered, data entry errors are reduced, as the sharing user typically does not need to re-enter information before transmitting it to the receiving user.

[0039] Reference is now made to the accompanying drawings, in which like reference numerals are used to refer to like elements throughout. In the following description, for illustrative purposes, numerous specific details are set forth to provide a thorough understanding thereof. However, it will be apparent that the novel implementations can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate their description. It is intended to cover all modifications, equivalents, and alternatives that fall within the spirit and scope of the claimed subject matter.

[0040] Figure 1 A system 100 according to the disclosed architecture is shown. System 100 may include a remote (e.g., network-based, centralized access) subscription component 102 configured to enable endpoints 104 to subscribe (register) to receive instances of personalized relevant entities (PEs), also known as social cards. Endpoints 104 may be any type of device, such as a desktop computing device, a mobile device (e.g., a cell phone), a tablet computer, a laptop computer, etc. Receiving instances of personalized relevant entities may be performed via the corresponding endpoint's PDA. Specifically, a first endpoint 106 includes a first PDA 108, which participates in the disclosed architecture for social card sharing via remote subscription component 102. In this example, a first (or sharing) user of first endpoint 106 selects to share personalized relevant entity (PE1) 110 with a second user of second endpoint 112. Second endpoint 112 subscribes (via remote subscription component 102) to receive PE1 110 from first endpoint 106.

[0041] Endpoint subscription to the disclosed architecture can be accomplished via a local subscription interface (LSI) for each endpoint. The local subscription interface can be configured to communicate with the remote subscription component 102 to handle notifications, endpoint status information, endpoint subscriptions, mappings, and the like. The local subscription interface can be a module that is part of the client device PDA, or a module that is separate from the PDA but operates to perform at least the functions of the PDA and the disclosed architecture as described above. Accordingly, the first endpoint 106 also includes an LSI 109 that supports interfacing with the remote subscription component 102 directly and / or through the PDA 108.

[0042] A mapping component 114 is provided and configured to enable creation and maintenance of (acceptance) mappings 116, mappings between endpoints 104 shared by subscribing entities, and securely storing (acceptance) mappings 116. The mapping component 114 is configured to enable remote subscribing components 102 to access the mappings 116, or to request mapping contracts for a particular user or group of users from the mapping component 114 to check the status of an endpoint (or endpoint user).

[0043] Although not shown here, it should be understood that the endpoint LSI can be configured to communicate directly with the mapping component 114 to obtain mapping information. Once the endpoint is subscribed via the remote subscription component 102, the remote subscription component 102 can obtain a security key for a given LSI or PDA, which can then be used for direct communication / access between the LSI / PDA and the mapping component 114 to access the mapping 116 specific to the given access endpoint.

[0044] When the user is a receiving user, the receiving endpoint only needs to utilize the mapping component 114 (e.g., as part of or during the receiving process) by checking the acceptance map to ensure that the receiving user has agreed (or subscribed) to receive content from the sender (sharing user or sharing endpoint). This can be done solely by the mapping component 114 or via the remote subscription component 102, which accesses the mapping component 114 to analyze the acceptance map 116.

[0045] Alternatively, it should be understood that a copy of the acceptance map 116 can be downloaded from the mapping component 114 to the subscribed endpoint, such that the remote subscription component 102 accesses the endpoint's local copy of the acceptance map to determine whether the receiving user has an acceptance contract with the shared user. When updates are made to the mapping component 114, the local copy of the map can be updated (e.g., pushed to the endpoint).

[0046] The remote subscription component 102 is configured to enable the delivery of notifications to an endpoint (e.g., the second endpoint 112) that a share is accepted and that a personalized related entity (P-E1 110) is awaiting sharing. For example, the notification can be in the form of a simple text message, an audio tone, or a social card that includes an entity graph and is included in a card list like any other card created from the entity graph.

[0047] The remote subscription component 102 is configured to enable merging of duplicate instances of personalized related entities. Thus, if an entity / entity graph is shared by multiple users (e.g., wife, friend, son, etc.), these are merged so that the user only sees the entity graph with metadata describing all the people who shared the data. Thus, the need for multiple users to share data from the first endpoint 106 and other endpoints (endpoints) is eliminated. N) 118, so that only a single PE (P-E1 110) is received by the second endpoint 112. The remote subscription component 102 can be configured to enable filtering of personalized, relevant entities based on the current user's interests. This can be considered "loose" filtering in the sense that it allows new entities to be received even if the user is not interested because someone in the user's social circle has already shared them. This filtering can be considered more of a negative filtering, where entities that the user is known to dislike or do not want to see are filtered out.

[0048] The remote subscription component 102 is configured to synchronize user-created local groups between endpoints based on a one-to-many endpoint mapping relationship.

[0049] The mapping component 114 is configured to generate a whitelist 120 for a shared endpoint (e.g., the first endpoint 106). The whitelist 120 identifies endpoints that are suitable for receiving personalized related entities from the shared endpoint (the first endpoint 106). The whitelist 120 can be generated for the first endpoint 106 by the mapping component 114, or a first user of the first endpoint 106 can generate the whitelist 120 at the first endpoint 106.

[0050] In this first scenario, a user can request a list of all mapped (accepting or receiving) users that were agreed to be received from the first user. This list can then be downloaded to the first endpoint 106 for the first user to make any required edits to remove one or more users. In this latter case, the whitelist 120 is therefore never present at the mapping component 114, but is created and resides on the endpoint 106; however, the whitelist 120 can be verified against the mapping 116 to ensure the identities of only those users that were agreed to be received from the first user.

[0051] The remote subscription component 102 can be configured to enable a sorted group of acceptable endpoints from which to receive personalized related entities. The sorted groups can have different sharing designations (e.g., inner circle, outer circle, etc.). The personalized related entities can be visually represented as cards visible in the card canvas of the personal digital assistant, and the cards are sorted according to the user's card engagement history.

[0052] Figure 2A detailed alternative system 200 is shown that enables a social platform for sharing personalized entities between users of a personal digital assistant. System 200 includes a subscription component 202 (e.g., a backend system, similar to remote subscription component 102 of system 100), a mapping component 204 (e.g., similar to mapping component 114 of system 100), and endpoints 104 (e.g., first endpoint 1041 and first endpoint 1042) that connect to subscription component 202 to benefit from sharing of personalized entities via endpoints 104. The endpoints can be any type of device that can use a personal digital assistant, such as a computing device, a mobile device (e.g., a cellular phone), a tablet computer, etc.

[0053] Entities (or content) can be shared between personal digital assistants of endpoints as "cards." A card can be defined as a digital virtual representation (as an independent graphical object, e.g., resizable) that can appear as a physical card (e.g., a rectangular card) that simply confines information (e.g., various types of media, such as text, images, colors, fonts, videos, etc.) in a polygonal format.

[0054] The disclosed architecture can be used for all PDA types and any framework that chooses to integrate this functionality. The privacy component can be employed in those frameworks that can choose to integrate increased privacy of entities (content).

[0055] The subscription component 202 enables users such as User 1 and User 2, as well as many other users, to obtain the benefits of a shared personalized entity. Subscription (registration) may require the creation of a user profile suitable for identifying users who choose to benefit from sharing the personalized entity (e.g., as a card). Subscription may require the creation of a username and password, user preferences, selection of users with whom the subscribing user wants to share content, categories of users (e.g., inner circle users and outer circle users), and other categories of information about the subscribing user, such as hobbies, interests, favorite pastimes, frequently visited websites, frequently accessed and viewed content, etc.

[0056] Subscription component 202 can be a backend service (e.g., a standalone hardware system running subscription software and other supporting software) to which a user with an endpoint running a PDA can access the disclosed architecture. A subscribing (or registered) user (e.g., User 1) can seek to share (send) a card with (to) an unregistered user (e.g., User 2). In this case, the unregistered user (User 2) will receive a notification from subscription component 202 that a registered user (User 1) is attempting to share a card with the unregistered user (User 2).

[0057] In a first implementation, all cards and checks (of personalized (related) entities) occur in and through subscription component 202. In an alternative implementation, subscription component 202 employs secure communication techniques, such as assigning encryption keys to communications occurring between users, such as User 1 and User 2. In this case, card sharing can occur directly between the endpoints of User 1 and User 2 using compatible decryption techniques in the endpoints.

[0058] In the example of the first implementation, user 1 chooses to send (share) a card to user 2. From the perspective of endpoint 1 of user 1, endpoint 1 can respond to user 1's action of sharing the card with user 2. Endpoint 1's response can be to access subscription component 202 with a request to obtain user 2's social status. Subscription component 202 processes the request and, in response to the request, accesses mapping component 204 to request user 2's social status.

[0059] If User 2 has not subscribed to card sharing, Mapping Component 204 will not have a mapping defining the sharing relationship between User 1 and User 2. Therefore, the social status returned from Mapping Component 204 to Subscribing Component 202 somehow indicates that User 2 does not accept the shared card, as there is no current mapping between User 1 and User 2. Non-accepting states include registered users who actively indicate non-acceptance of social cards, as well as unregistered users who are not present in System 200 at all. In both cases, User 2 will be defined as not accepting social cards. In either case, Subscribing Component 202 will then return contact status information to Endpoint 1, in response to which User 1 is notified of the non-accepting state and will not share the card.

[0060] It is possible that the system 200 is provided with the ability to queue cards for a user (e.g., user 2) and other users for later sharing. For example, although the status of the registered user (e.g., user 2) is currently set to not accepting, it can be inferred that the shared user (user 2) has changed the status from not accepting to accepting based on the previous shared user acceptance history. In this case, the mapping component 204 updates the mapping between user 1 and user 2 and the queued card is then shared with user 2.

[0061] By queuing each card, a notification can be sent to the shared user for each newly queued card that a particular sharing user (User 1) has shared a card. In this way, shared user 2 can selectively choose which card to view at any point in time. In an alternative implementation, the entire card queue can be stacked offset in the viewing canvas (not directly on top of the underlying cards, but slightly offset from the underlying cards). Hovering the pointing device pointer over any card in the stack can provide a brief pop-up box that is a brief description of the entire card entity (or content).

[0062] Endpoint 1 may be configured to periodically request status from any number of users, continuously request status from any number of users, or only request status on demand from User 1 who has chosen to share a social card with one or more users, etc.

[0063] Alternatively or in combination therewith, subscription component 204 can be configured to automatically push contact (user) status data to endpoints in response to a trigger of specific criteria, such as an update (change) to the user mapping in mapping component 204. For example, if user 2 is in user 1's contact list, but user 2, while registered, has temporarily disabled accepting or changed to not accepting status, such a change can be detected as a trigger for pushing user 2's status to user 1's whitelist 206 (similar to whitelist 206 of whitelist 120). Any registered user can obtain and be given a whitelist of contacts (other endpoints).

[0064] The social contacts of any registered user can be stored as a whitelist 206 of users to whom cards can be sent from an endpoint (e.g., endpoint 1). The whitelist can be generated from the mapping component 204 based on all users who have agreed to receive content from others or from a specific user. In other words, the whitelist 206 can be only the users that user 1 has selected to send social cards, or the entire set of registered users in the system that are currently configured and mapped to receive social cards. In one whitelist implementation, the whitelist 206 of the user device can be polled from the mapping component 204 via the subscription component 202, and a subset of users can be created from the full contact list of the mapping component 202. The subset of users can be only those users mapped to user 1 and / or groups defined by user 1 (e.g., inner circle and outer circle).

[0065] Continuing with the first implementation, but from the perspective of user 2, regardless of whether already registered, endpoint 2 of user 2 can receive notification from subscription component 202 that user 1 wants to share a social card (of personalized entity information). User 2 can choose to perform the steps required to receive the shared card, such as registering (subscribing) via subscription component 202 and supporting the transmission of the acceptance from subscription component 202 to mapping component 204, so that user 2 is mapped to user 1 when accepting the social card from user 1, and the mapping relationship is stored in mapping component 204 for access by subscription component 202 for status request.

[0066] Once User 2's acceptance (e.g., Accept 2) is stored in the mapping component 204, User 1's whitelist 206 can be updated to include User 2 as a shared user. Thus, in one embodiment, the whitelist 206 includes only those users who have chosen to accept the social card. In an alternative embodiment, the whitelist 206 includes users with an Accepted status, as well as users who have registered but have disabled Acceptance (Not Accepted). As previously described, a given user's whitelist 206 can include only users with whom User 1 has chosen to share (multiple) social cards, and exclude other users not associated with the mapping to User 1. Thus, the whitelist 206 can be small in size, more efficiently stored on small devices such as cell phones, tablet computers, and more quickly processed.

[0067] Continuing with the first implementation, once User 2 accepts the residency in the mapping component 204, the status check of Endpoint 1 reveals that User 2 has accepted the sharing from User 1. The personalized card (personalized entity (information)) is received at Endpoint 1 from the subscription component 202, and then Endpoint 1 of User 1 shares the personalized card to User 2 through the subscription component 202.

[0068] A sharing user (e.g., User 1) can create a personalized entity card as part of interfacing with the subscription component 202, which provides the ability to generate social cards. A social card can include any amount of information ranging from basic user information (e.g., name, address, demographic information, etc.) to a rich set of information about the user (e.g., name and address, hobbies, interests, entities of interest, content the user frequently or wants to share, websites visited, etc.).

[0069] In other words, by creating a one-to-one mapping between two users of the contact list or a one-to-many mapping of a single user to multiple users of the contact list, User 2 (the shared user) accepts to receive social cards ("personalized entities," "personalized related entities," and "personalized entity information") from the contact list of mapping 208 in mapping component 204. Such mapping 208 for a single user can be recorded on a whitelist of the single user (e.g., whitelist 210 of User 2).

[0070] The mapping component 204 may also include the ability to enable grouping of shared users for a single sharing user. As shown herein, this capability can be further extended to the concept of a user's "inner circle" (most trusted or preferred users) and "outer circle" (less trusted or less preferred users), where the user can choose to receive social cards only from inner circle users. This capability can be further extended to more than two groups of users categorized by various criteria, such as geographic location, heritage, work, family, country, etc. Thus, for example, User 1 can choose to send a social card to the Family Group. Once selected, the Family Group is processed to send a notification to each member of the Family Group that User 1 is requesting to share a social card. Additional features of the subscription component 202 may include, for example, blocking users or content categories.

[0071] A mapping component 204 (also referred to as a social vault) maintains a mapping of identifiers of all users who have accepted the capabilities of the disclosed PDA sharing architecture. In one implementation, the relevant identifier may be a messaging identifier (e.g., an email ID) mapped to an ANID (anonymous ID). Other mappings may be employed to support the disclosed architecture. Thus, the mapping component 204 generates a universal map (e.g., a graph) of all users, which is protected and can be queried by the subscription component 202.

[0072] A user (e.g., User 1) can dynamically create user groups on a local endpoint (e.g., Endpoint 1) at runtime so that the user can share personalized entities with multiple users at once. These local groups for a given user can be synchronized to all devices of the given user using the subscription component 202.

[0073] The shared social card becomes available as a PDA social card on the recipient's (the user being shared with) primary canvas (via the viewing surface or interface of the application in which the social card is being viewed) along with other cards (e.g., non-shared cards of the PDA application, but cards that are typically used as part of the PDA application, whether or not sharing is enabled). In one implementation, the shared card can be sorted and presented with other non-shared cards. For example, the social card sorting can be based on user engagement history.

[0074] The system 200 enables merging. Multiple users may be willing to share the same or similar social cards to a user (many-to-one scenario), and therefore, merging at the subscription component 202 is provided so that the shared user canvas is not flooded with the same or similar social cards (e.g., shared by user 3, user 4, user 8, and three other users).

[0075] Notifications related to the processing of a social card (personal entity) (e.g., notifying the shared (or recipient) user of the intent to share a social card) can be provided. Notifications can be pushed to user endpoints. For example, on a computer running Windows TM In operating system (OS) endpoints, toast notifications (temporary OS-based visual element pop-ups) can be used to support notifying the endpoint user of the receipt of one or more social cards. This improves the user experience for users who do not have the active canvas open or are not highly engaged with the canvas. In an alternative notification implementation, tile notifications can be used.

[0076] The subscription component 202 may also employ card filtering. Based on the user's current interests, the subscription component 202 may select or be configured to respond to one or more signals to filter the shared social card information. For example, in some cases, the user experience of sharing a PDA personalized entity may be filtered by interest. The subscription component 202 may be configured to enable / disable interest filtering to receive / share shared entities of common interest or shared entities that the sharing user believes may be of interest to the shared user.

[0077] The disclosed architecture may optionally include a privacy component that enables users to choose or opt out of exposing personal information. The privacy component enables authorization and secure processing of user information, such as tracking information and personal information that may be obtained, maintained, and / or accessible. Users may be provided with notification of the collection of personal information and the opportunity to opt in or out of the collection process. Consent may take several forms. Opt-in consent may force the user to take an affirmative action before data is collected. Alternatively, opt-out consent may force the user to take an affirmative action to prevent data from being collected before it is collected.

[0078] It should be understood that in the disclosed architecture, certain components may be rearranged, combined, omitted, and additional components may be included. Furthermore, in some implementations, all or some components reside on the client, while in other implementations, some components may reside on the server or be provided by local or remote services. For example, the mapping component 114 (or 204) may reside on the same platform as the remote subscription component 102 (or 202).

[0079] Figure 3An exemplary generic pseudo-map 116 of user acceptances generated and stored by the mapping component 114 is shown. In practice, at least identifiers can be employed to identify objects or programs associated with a sharing user (the user sending the social card) and a shared user (the user accepting the receipt of the social card). These mappings 116 are similar to the mappings 208 generated and stored by the mapping component 204. The mappings 116 illustrate one-to-one (accept), one-to-many (accept), and many-to-one (accept) mappings supported by the disclosed architecture, where one subscribing user chooses to accept from only one other sharing user (one-to-one), one subscribing user chooses to accept from multiple other sharing users (one-to-many), and multiple subscribing users choose to accept from the same sharing user (many-to-one). It should be understood that the disclosed architecture generally handles many-to-many mappings, as any receiving user can choose to receive social cards from any number of other users, and those other users can also choose to receive social cards from multiple other users, which may include the receiving user.

[0080] There are eight depicted mappings 300 throughout mapping 116. Map #1 illustrates a one-to-one mapping where user 5 subscribes to receive or accept personalized entities from endpoint 6 of user 3. Maps #2-7 illustrate one-to-many mappings (relationships) where the receiving or accepting user (user 1) chooses to receive entities from the same user (user 2) but from different endpoints of user 2 and from separate instances of different users (user 4 and user 8). As shown, the receiving user (user 1) can choose to accept social cards from user 2 from three of the four user 2 endpoints (endpoint 2, endpoint 3, endpoint 5) and choose not to accept social cards from one of user 2's endpoints (endpoint 4). User 2 can choose to re-enable social card acceptance at endpoint 4 at any time.

[0081] This capability illustrates that the mapping component 114 can support many-to-one communication to endpoints, rather than relying on a single user endpoint to handle the distribution or receipt of social cards to / from other endpoints of the same user. Mappings #2 and #8 illustrate many-to-one mappings, where User 1 and User 4 can choose to accept a social card from User 2. Note that each mapping can include acceptance level information that identifies a specific mapping to a specific acceptance level, such as accept from everyone, accept only from family, accept only from a contact list, and so on.

[0082] Figure 4An exemplary whitelist 206 of whitelist entries 400 and whitelist functionality according to the disclosed architecture is shown. When user 1 requests a mapping to select all users from whom to accept social cards from user 1, a user whitelist 206 can be generated for user 1. In response, mapping component 114 generates a whitelist from the entire mapping list 116 and sends whitelist 206 to user 1's endpoint 1. User 1 can choose to further edit whitelist 206 to remove or modify entries. Based on this whitelist 206, user 1 can create a local user group from which to accept entities. For example, if whitelist 206 includes close family members, user 1 can use a local PDA program or some other suitable application to create a user group in whitelist 206 from which social cards can be received. The PDA program will then process the acceptance of social cards from user 1 based on the local group identified when user 1 accepts the card from the entire group. This capability is depicted in whitelist mapping 400 with list item LG5 (Local Group-5) and list item LG3.

[0083] Local Group 5 (LG5) indicates that User 1 has grouped User 2 and User 2's endpoint, User 4, and User 8, from whom User 1 will receive social cards. Similarly, Local Group 1 (LG1) defines a group that includes User 4 and User 8, from whom User 1 will receive social cards. The disclosed architecture can also support local grouping of groups. Thus, Local Group 3 (LG3) defines a set of multiple groups, LG1 and LG5, from which User 1 will receive social cards.

[0084] When processing a local group, the local PDA program can process (decompose) the whitelist items into instructions understandable by the mapping component 114 so that the remote subscription component 102 can then perform sharing, accepting, notifying, merging, and filtering as described herein. For example, processing of LG1 results in user 1 receiving social cards from user 4 and user 8.

[0085] Included herein is a set of flow charts representing exemplary methods for performing novel aspects of the disclosed architecture. Although one or more methods, for example, shown in the form of a flowchart or flow diagram, are shown and described herein as a series of actions for purposes of simplicity of description, it should be understood and appreciated that the method is not limited by the order of the actions, as some actions may occur in a different order than shown and described herein and / or occur simultaneously with other actions. For example, one skilled in the art will appreciate and appreciate that the method may alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, novel implementations may not require all of the actions described in the method.

[0086] Figure 5A method according to the disclosed architecture is shown. At 500, entities related to a first user are discovered. At 502, personalized related entities for the first user are generated from the discovered related entities. At 504, upon acceptance of the first user's personalized related entities by a second user on a social network, the personalized related entities are shared with a second user via a personal digital assistant of the first user and a personal digital assistant of the second user.

[0087] The method may also include enabling a subscription for the second user to receive personalized related entities from the first user. The method may also include creating an acceptance mapping between the first user and the second user. The method may also include storing an acceptance mapping including the acceptance mapping in a secure storage device, the acceptance mapping being queryable in the secure storage device.

[0088] The method may further include filtering the shared personalized related entities based on interest or lack of interest.The method may further include pushing notifications of the shared personalized related entities.

[0089] Figure 6 An alternative method according to the disclosed architecture is shown. At 600, entities related to a first user are discovered. At 602, personalized entities for the first user are generated from the discovered related entities. At 604, an acceptance mapping is created between the first user and a second user. At 606, a notification of the shared personalized entity is sent to the second user's personal digital assistant. At 608, the personalized entity is shared with a second user of a social network via the personal digital assistant. Sharing is achieved because the second user has subscribed to receive personalized entities from the first user.

[0090] The method may also include merging multiple instances of the personalization entity received from multiple users to mitigate canvas flooding of multiple instances of the personalization entity at the second user's endpoint.The method may also include enabling status checking of the second user on the social network.

[0091] The method may also include creating a group of users at the local endpoint and at runtime that the personalized entity can share simultaneously. The method may also include synchronizing the user-created local groups between endpoints based on endpoint acceptance mappings (e.g., one-to-many, many-to-one, one-to-one). The method may also include generating a whitelist for the endpoint, wherein the whitelist identifies endpoints that are suitable for receiving the personalized entity.

[0092] As used in this application, the term "component" is intended to refer to a computer-related entity, whether hardware, a combination of software and tangible hardware, software, or executing software. For example, a component can be, but is not limited to, a tangible component, such as one or more microprocessors, chip memory, mass storage devices (e.g., optical drives, solid-state drives, magnetic storage media drives, etc.), computers, and portable computing and computing-capable devices (e.g., cellular phones, tablet computers, smart phones, etc.). Software components include processes running on a microprocessor, objects (software entities that use methods to maintain variable and action states), executable files, data structures (stored in volatile or non-volatile storage media), modules (parts of a program), execution threads (the smallest sequence of instructions that can be managed independently), and / or programs.

[0093] As an illustration, both the application and the server running on the server can be components. One or more components can reside in a process and / or execution thread, and a component can be localized on a computer and / or distributed between two or more computers. The word "exemplary" can be used herein to represent being used as an example, instance or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be interpreted as being preferred or advantageous over other aspects or designs.

[0094] Now refer to Figure 7 , a block diagram of a computing system 700 for performing card sharing via a personal digital assistant according to the disclosed architecture is shown. Alternatively or additionally, the functions described herein can be performed at least in part by one or more hardware logic components. For example, and not limitation, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chips (SOCs), complex programmable logic devices (CPLDs), etc., where analog, digital, and / or combined signals and other functions can be implemented in the substrate.

[0095] To provide additional context for its various aspects, Figure 7 The following description is intended to provide a brief, general description of a suitable computing system 700 in which the various aspects may be implemented. Although the above description is in the general context of computer-executable instructions that may be executed on one or more computers, those skilled in the art will recognize that the novel implementations may also be implemented in combination with other program modules and / or as a combination of hardware and software.

[0096] The computing system 700 for implementing various aspects includes a computer 702 having microprocessing unit(s) 704 (also referred to as microprocessor(s) and processor(s), a computer-readable storage medium (wherein a medium is any physical device or material on which data can be stored and retrieved electronically and / or optically), such as a system memory 706 (one or more computer-readable storage media also include magnetic disks, optical disks, solid-state drives, external memory systems, and flash memory), and a system bus 708. The microprocessing unit(s) 704 can be any of a variety of commercially available microprocessors, such as single processors, multiprocessors, single-core units, and multi-core units of processing and / or storage circuitry. In addition, those skilled in the art will appreciate that the novel systems and methods can be practiced using other computer system configurations, including minicomputers, mainframe computers, and personal computers (e.g., desktops, notebooks, tablet PCs, etc.), handheld computing devices, microprocessor-based or programmable consumer electronics, etc., each of which can be operably coupled to one or more associated devices.

[0097] Computer 702 may be one of several computers employed in a data center and / or computing resources (hardware and / or software) to support cloud computing services for portable and / or mobile computing systems (such as wireless communication devices, cellular phones, and other mobile-enabled devices. For example, cloud computing services include, but are not limited to, infrastructure as a service, platform as a service, software as a service, storage as a service, desktop as a service, data as a service, security as a service, and API (application programming interface) as a service.

[0098] The system memory 706 may include computer-readable storage (physical storage) media such as volatile (VOL) memory 710 (e.g., random access memory (RAM)) and non-volatile memory (NON-VOL) 712 (e.g., ROM, EPROM, EEPROM, etc.). A basic input / output system (BIOS) may be stored in the non-volatile memory 712 and includes basic routines that support the transfer of data and signals between components within the computer 702, such as during startup. The volatile memory 710 may also include high-speed RAM, such as static RAM for caching data.

[0099] The system bus 708 provides an interface for system components including, but not limited to, system memory 706 to the microprocessing unit(s) 704. The system bus 708 may be any of several types of bus structures that may further interconnect to a memory bus (with or without a memory controller) and a peripheral bus (e.g., PCI, PCIe, AGP, LPC, etc.) using any of a variety of commercially available bus architectures.

[0100] The computer 702 also includes machine-readable storage subsystem(s) 714 and storage interface(s) 716 for interfacing the storage subsystem(s) 714 with the system bus 708 and other desired computer components and circuits. For example, the storage subsystem(s) 714 (physical storage media) may include one or more of a hard disk drive (HDD), a magnetic floppy disk drive (FDD), a solid-state drive (SSD), a flash drive, and / or an optical storage drive (e.g., a CD-ROM drive, a DVD drive). The storage interface(s) 716 may include interface technologies such as EIDE, ATA, SATA, and IEEE 1394.

[0101] One or more programs and data may be stored in the memory subsystem 706 , the machine-readable and removable memory subsystem 718 (e.g., flash drive form factor technology), and / or the storage subsystem(s) 714 (e.g., optical, magnetic, solid-state), including an operating system 720 , one or more applications 722 , other program modules 724 , and program data 726 .

[0102] For example, operating system 720, one or more applications 722, other program modules 724, and / or program data 726 may include Figure 1 Items and components of system 100, Figure 2 Items and components of alternative systems 200, Figure 3 Mapping 116, Figure 4 Whitelist 206, and by Figure 5 and Figure 6 A flowchart representation of the method.

[0103] Typically, a program includes routines, methods, data structures, other software components, etc. that perform specific tasks, functions, or implement specific abstract data types. For example, all or part of the operating system 720, applications 722, modules 724, and / or data 726 may also be cached in memory, such as volatile memory 710 and / or non-volatile memory. It should be understood that the disclosed architecture can be implemented with various commercially available operating systems or combinations of operating systems (e.g., as virtual machines).

[0104] The storage subsystem(s) 714 and the memory subsystems (706 and 718) serve as computer-readable media for volatile and non-volatile storage of data, data structures, computer-executable instructions, and the like. Such instructions, when executed by a computer or other machine, may cause the computer or other machine to perform one or more actions of a method. Computer-executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or (s) special-purpose microprocessor device to perform a function or group of functions. Computer-executable instructions may be, for example, binary files, intermediate format instructions, such as assembly language, or even source code. The instructions to perform an action may be stored on one medium, or may be stored across multiple mediums such that the instructions are collectively present on one or more computer-readable storage media, regardless of whether all instructions are on the same medium.

[0105] One or more computer-readable storage media, excluding the propagated signals themselves, can be accessed by the computer 702 and include removable and / or non-removable volatile and non-volatile internal and / or external media. Various types of storage media accommodate the storage of data in any suitable digital format for the computer 702. Those skilled in the art will appreciate that other types of computer-readable media, such as compact disk drives, solid-state drives, magnetic tapes, flash memory cards, flash drives, cartridges, etc., can be employed to store computer-executable instructions for performing the novel methods (actions) of the disclosed architecture.

[0106] The user can interact with the computer 702, programs, and data using external user input devices 728, such as a keyboard and mouse, and through voice commands supported by voice recognition. Other external user input devices 728 may include a microphone, an IR (infrared) remote control, a joystick, a game controller, a camera recognition system, a stylus, a touch screen, a gesture system (e.g., eye movements, body gestures such as those associated with hand(s), finger(s), arm(s), head, etc.), etc. For example, the user can interact with the computer 702, programs, and data using onboard user input devices 730, such as a touchpad, a microphone, a keyboard, etc., where the computer 702 is a portable computer.

[0107] These and other input devices are connected to the microprocessor unit(s) 704 via the system bus 708 through input / output (I / O) device interface(s) 732, but may be connected by other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, short-range wireless (e.g., Bluetooth), and other personal area network (PAN) technologies. The I / O device interface(s) 732 also supports the use of output peripherals 734, such as printers, audio devices, camera devices, and the like, such as a sound card and / or onboard audio processing capabilities.

[0108] One or more graphics interfaces 736 (also commonly referred to as graphics processing units (GPUs)) provide graphics and video signals between the computer 702 and external display(s) 738 (e.g., LCD, plasma) and / or onboard display 740 (e.g., for a portable computer). The graphics interface(s) 736 may also be manufactured as part of the computer system board.

[0109] The computer 702 can operate in a network environment (e.g., IP-based) using logical connections to one or more networks and / or other computers via a wired / wireless communications subsystem 742. Other computers may include workstations, servers, routers, personal computers, microprocessor-based entertainment devices, peer devices, or other public network nodes, and typically include many or all of the elements described with respect to the computer 702. Logical connections may include wired / wireless connections to local area networks (LANs), wide area networks (WANs), hotspots, and the like. LAN and WAN network environments are common in offices and companies and support enterprise-wide computer networks, such as intranets, all of which can be connected to global communication networks such as the Internet.

[0110] When used in a network environment, the computer 702 is connected to the network via a wired / wireless communication subsystem 742 (e.g., a network interface adapter, an onboard transceiver subsystem, etc.) to communicate with a wired / wireless network, a wired / wireless printer, a wired / wireless input device 744, etc. The computer 702 may include a modem or other means for establishing communications over the network. In a network environment, programs and data relative to the computer 702 may be stored in remote memory / storage devices, such as those associated with a distributed system. It should be understood that the network connections shown are exemplary and that other means of establishing a communications link between the computers may be used.

[0111] The computer 702 is operable to communicate using radio technologies such as the IEEE 802.xx family of standards with wired / wireless devices or entities, such as wireless devices operatively configured for wireless communication (e.g., IEEE 802.11 over-the-air modulation technology) with, for example, printers, scanners, desktop and / or portable computers, personal digital assistants (PDAs), communication satellites, any device or location associated with a wirelessly detectable tag (e.g., kiosks, newsstands, restrooms), and telephones. This includes at least Wi-Fi for hotspots. TM (for certifying interoperability of wireless computer network equipment), WiMax, and Bluetooth TMWireless technology. Therefore, communication can be a predefined structure like a conventional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technologies known as IEEE 802.11x (a, b, g, etc.) to provide secure, reliable, and fast wireless connections. You can use Wi-Fi networks to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 related technologies and functions).

[0112] The disclosed architecture can be implemented as a system comprising: a device for discovering entities related to a first user; a device for generating personalized related entities of the first user from the discovered related entities; and a device for sharing the personalized related entities with a second user via a personal digital assistant of the first user and a personal digital assistant of the second user based on the second user's acceptance of receiving the personalized related entities of the first user on a social network.

[0113] The disclosed architecture can be implemented as an alternative system comprising: a device for discovering entities related to a first user; a device for generating personalized entities of the first user from the discovered related entities; a device for creating an acceptance mapping between the first user and a second user; a device for sending a notification of the shared personalized entity to a personal digital assistant of the second user; and a device for sharing the personalized entity with the second user via the personal digital assistant based on the second user's acceptance of receiving the personalized related entity of the first user on a social network.

[0114] The foregoing description includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and / or methodologies, but one of ordinary skill in the art will recognize that many additional combinations and permutations are possible. Therefore, the novel architecture is intended to embrace all such changes, modifications, and variations that fall within the spirit and scope of the appended claims. Furthermore, if the term "includes" is used in the detailed description or claims, such term is intended to be inclusive in a manner similar to the term "comprising," as interpreted when used as a transitional term in a claim.

Claims

1. A system comprising: one or more processing units; as well as A memory storing instructions that, when executed by the one or more processing units, cause the system to perform operations comprising: receiving, from a first computing device associated with a first user, a first instance of personalized content to be shared with a second user associated with a second computing device; accessing a mapping for receiving acceptance of personalized content between the first user and the second user; determining, based on the mapping, that the second user has not accepted receiving personalized content from the first user; queuing the first instance of personalized content; determining a change in status for the second user; and Based on the change in status for the second user, the first instance of personalized content from the queue is shared and made available on an interface of the second computing device associated with the second user.

2. The system of claim 1 , wherein determining the change in status for the second user comprises: It is determined that the second user has accepted to receive personalized content from the first user. 3 . The system of claim 1 , wherein the instructions, when executed, further cause the system to provide a notification to the second computing device, and wherein the notification indicates that the first user attempted to share the first instance of personalized content.

4. The system of claim 1 , wherein the instructions, when executed, further cause the system to: receiving a second instance of personalized content, the second instance of personalized content to be shared with the second user; and The second instance of the personalized content is queued with the first instance of the personalized content.

5. The system of claim 4, wherein the instructions, when executed, further cause the system to: Based on the change in status for the second user, a notification is delivered to the second computing device, wherein the notification displays at least the first instance of personalized content and the second instance of personalized content in an offset stack. 6 . The system of claim 5 , wherein the first instance of personalized content and the second instance of personalized content are selectable from the offset stack in any order.

7. The system of claim 1 , wherein delivering the first instance of personalized content by the first computing device comprises: The first instance of personalized content is visually represented as a card visible in a card canvas at the second computing device.

8. A method comprising: receiving a first instance of personalized content from a first computing device associated with a first user, the first instance of personalized content to be shared with a second user associated with a second computing device; receiving a second instance of personalized content from a third computing device associated with a third user, the second instance of personalized content to be shared with the second user; accessing a mapping for receiving acceptances of personalized content between the first user, the second user, and the third user; determining, based on the mapping, that the second user accepts receiving personalized content from the first user and the third user; determining that the first instance of personalized content and the second instance of personalized content are similar; as well as One of the first instance of personalized content or the second instance of personalized content is provided to the second user.

9. The method according to claim 8, further comprising: Based on one or more measurable parameters, it is determined that the first instance of personalized content and the second instance of personalized content are similar.

10. The method according to claim 8, further comprising: A notification is provided to the second computing device, wherein the notification indicates that the first user and the third user shared an instance of personalized content. 11 . The method of claim 10 , wherein the notification further indicates that the second user accepts to receive personalized content from the first user and the third user.

12. The method according to claim 8, further comprising: Based on a one-to-many computing device mapping relationship, a local group created by a user is synchronized between at least the first computing device and the second computing device.

13. The method according to claim 8, further comprising: A whitelist is generated, wherein the whitelist identifies one or more computing devices suitable for receiving the first instance of personalized content from the first computing device.

14. The method according to claim 8, further comprising: receiving, from the first computing device, a third instance of personalized content to be shared with the second user; applying a filter based on the second user's preferences; as well as Based on the filter, the third instance of personalized content is prevented from being delivered to the second user. The method of claim 14 , wherein the filter is based on current user interests of the second user. 16 . The method of claim 8 , wherein one of the first instance of personalized content or the second instance of personalized content is visually provided as a card visible in a card canvas at the second computing device.

17. A computer-readable storage medium storing instructions that, when executed by a processing unit, cause the processing unit to perform operations comprising: receiving a first instance of personalized content from a first computing device associated with a first user, the first instance of personalized content to be shared with a second user associated with a second computing device; receiving a second instance of personalized content from a third computing device associated with a third user, the second instance of personalized content to be shared with the second user; accessing a mapping for receiving acceptances of personalized content between the first user, the second user, and the third user; determining, based on the mapping, that the second user accepts receiving personalized content from at least the first user and the third user; determining a current interest of the second user; as well as Based on the current interests of the second user, one of the first instance of personalized content or the second instance of personalized content is provided to the second user.

18. The computer-readable storage medium of claim 17, wherein the instructions, when executed, further cause the processing unit to: provide a notification to the second computing device, wherein the notification indicates that the second user has accepted to receive personalized content from at least the first user or the third user.

19. The computer-readable storage medium of claim 17, wherein the instructions, when executed, further cause the processing unit to: provide a notification to the second computing device, wherein the notification indicates that the first user and the third user shared an instance of personalized content.

20. The computer-readable storage medium of claim 17, wherein the current interest of the second user is based on input from the second user.

21. A system comprising: a remote subscription component configured to enable one or more subscriptions of a plurality of endpoint devices to participate in receipt of instances of personalized content, the one or more subscriptions received via one or more personal digital assistants corresponding to the plurality of endpoint devices; a mapping component configured to map the one or more subscriptions between the plurality of endpoint devices, the plurality of endpoint devices subscribing and securely storing the mapped acceptances, the mapping component configured to store acceptance levels received from all other users of the plurality of endpoint devices and enable access by the remote subscription component to check status of the plurality of endpoint devices, wherein the acceptance levels indicate a source from which an instance of personalized content was received; the remote subscription component being configured to enable creation and maintenance of a mapping, downloading a copy of the mapped subscription from the mapping component such that when updates are made to the mapping component, updates to the mapped accepted copy are pushed to the plurality of endpoint devices; a local subscription interface of each endpoint device of the plurality of endpoint devices, configured to communicate with the remote subscription component to process push notifications, endpoint status information, and endpoint subscriptions; as well as at least one hardware processor configured to execute computer-executable instructions in memory, the computer-executable instructions being executed to enable the remote subscription component and the mapping component, in: the remote subscription component receiving, from a first computing device associated with a first user among the plurality of endpoint devices, a first instance of personalized content to be shared with a second user associated with a second computing device among the plurality of endpoint devices; The remote subscription component accesses the mapping component to obtain a mapping for receiving acceptance of personalized content between the first user and the second user; Based on the mapping, the remote subscription component determines that the second user has not accepted to receive personalized content from the first user; The remote subscription component queues the first instance of personalized content; The remote subscription component accesses the mapping component to determine a change in state for the second user; and Based on the change in status for the second user, the remote subscription component shares the first instance of personalized content from a queue and makes the first instance of personalized content available on an interface of the second computing device associated with the second user.

22. The system of claim 21, wherein the subscription component is configured to enable delivery of a notification to the plurality of endpoint devices that sharing is accepted and personalized content is waiting to be shared.

23. The system of claim 21, wherein the subscription component is configured to enable merging of repeated instances of the personalized content.

24. The system of claim 21, wherein the subscription component is configured to enable filtering of the personalized content based on current user interests.

25. The system of claim 21, wherein the subscription component is configured to synchronize user-created local groups among the plurality of endpoint devices based on a one-to-many endpoint mapping relationship.

26. The system of claim 21, wherein the mapping component is configured to generate a whitelist for a shared endpoint device, the whitelist identifying endpoints suitable for receiving the personalized content from the shared endpoint device.

27. The system of claim 21, wherein the mapping component is configured to enable ordered groups of acceptable plurality of endpoint devices from which to receive the personalized content, the ordered groups having different sharing designations.

28. The system of claim 21, wherein the personalized content is visually identified as cards visible in a card canvas of the personal digital assistant, the cards being ordered according to a user's card engagement history.

29. A method comprising the following actions: discovering content relevant to the first user; generating personalized content for the first user from the discovered related content; receiving a first instance of personalized content from a first computing device associated with the first user, the first instance of personalized content to be shared with a second user associated with a second computing device; accessing a mapping for receiving acceptance of personalized content between the first user and the second user; determining, based on the mapping, that the second user has not accepted receiving personalized content from the first user; queuing the first instance of personalized content; determining a change in status for the second user; sharing the personalized content with the second user of a social network via the first user's personal digital assistant and the second user's personal digital assistant based on an acceptance level by the second user of receiving the personalized content of the first user, wherein the acceptance level indicates a source of an instance of receiving personalized content; downloading a copy of the mapped subscription, wherein when an update is made, the update to the copy of the mapped subscription is pushed to the plurality of endpoint devices; as well as Handles push notifications, endpoint status information, and endpoint subscriptions.

30. The method of claim 29, further comprising: A subscription by the second user is enabled to receive the personalized content from the first user.

31. The method of claim 29, further comprising: An accept mapping is created between the first user and the second user.

32. The method of claim 31 , further comprising: An acceptance map is stored in a secure storage device, the acceptance map including the one acceptance map, the acceptance map being queryable in the secure storage device.

33. The method of claim 29, further comprising: The shared personalized content is filtered based on interest or lack of interest.

34. The method of claim 29, further comprising: Push notification of the shared personalized content.

35. A method comprising the following actions: discovering content relevant to the first user; generating personalized content for the first user from the discovered related content; receiving a first instance of personalized content from a first computing device associated with the first user, the first instance of personalized content to be shared with a second user associated with a second computing device; creating an acceptance mapping between the first user and a second user, wherein acceptance levels are received from the first user and the second user, and the acceptance levels indicate a source from which an instance of personalized content is received; accessing a mapping for receiving acceptance of personalized content between the first user and the second user; determining, based on the mapping, that the second user has not accepted receiving personalized content from the first user; queuing the first instance of personalized content; determining a change in status for the second user; sending a notification of the shared personalized content to the personal digital assistant of the second user; sharing the personalized content with the second user of the social network via the personal digital assistant based on the level of acceptance by the second user of receiving the personalized content of the first user; downloading a copy of the mapped subscription, wherein when an update is made, the update to the copy of the mapped subscription is pushed to the plurality of endpoint devices; as well as Handles push notifications, endpoint status information, and endpoint subscriptions.

36. The method of claim 35, further comprising: Multiple instances of the personalized content received from multiple users are merged to mitigate canvas flooding of the multiple instances of the personalized content at the endpoint device of the second user.

37. The method of claim 35, further comprising: Enabling status checking of the second user on the social network.

38. The method of claim 35, further comprising: A user group is created where the personalized content is shared by users simultaneously at the local endpoint and at runtime.

39. The method of claim 35, further comprising: Based on the endpoint acceptance mapping relationship, the local groups created by the user are synchronized among the multiple endpoint devices.

40. The method of claim 35, further comprising: A whitelist is generated for endpoints, the whitelist identifying the plurality of endpoint devices suitable for receiving the personalized content.

Images