COOPERATIVE CONTACT LISTS

Abstract

The present invention provides an effective means of screening calls by sharing contact data between individual users of communication devices. The contact information is augmented to include shareability data and relations data. The additional data can be used to configure the shared data in a way that private contacts, for example, can be restricted from sharing, while public contacts are shared.

Claims

1. A method of sharing contact information comprising: adding to each of a plurality of contact lists information indicating, for each entry in each contact list, information indicating a level of shareability of the entry with non-owners of the contact list based on relations of the owner of the contact list with the non-owners, and adding information indicating a relation of the entry with the owner of the contact list; in response to a request for access to each entry in a contact list by a non-owner of the contact list, granting or restricting access to the contact list based on a relation of the owner to the non-owner requesting access and based on an indicated level of shareability of each entry.

2. The method of claim 1, wherein the information indicating a level of shareability includes information indicating that a contact is a family member, a friend, a public entity or a private entity.

3. The method of claim 2, wherein information indicating a relation includes information indicating that a contact is a family member, a friend or a public entity.

4. The method of claim 1, further comprising blocking, screening or passing a call based on a determination of whether an origination phone number was found in a list of shared contacts.

5. An apparatus for sharing contact information comprising: means for adding to each of a plurality of contact lists information indicating, for each entry in each contact list, information indicating a level of shareability of the entry with non-owners of the contact list based on relations of the owner of the contact list with the non-owners, and means for adding information indicating a relation of the entry with the owner of the contact list; and in response to a request for access to each entry in a contact list by a non-owner of the contact list, means for granting or restricting access to the contact list based on a relation of the owner to the non-owner requesting access and based on an indicated level of shareability of each entry.

6. The apparatus of claim 4, wherein the information indicating a level of shareability includes information indicating that a contact is a family member, a friend, a public entity or a private entity.

7. The apparatus of claim 5, wherein information indicating a relation includes information indicating that a contact is a family member, a friend or a public entity.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 is a graphical representation of a data structure according to a preferred embodiment of the present invention; and

[0014] FIG. 2 is a flow chart demonstrating how calls are treated when shared contacts are implemented with additional data is included;

DETAILED DESCRIPTION OF THE INVENTION

[0015] In order to prevent unwanted robocalls from arriving at a called party, and to avoid screening or blocking wanted calls to a called party, additional properties are added to each contact within a user's contact data. For example, presently contact data includes name, phone number or numbers, address, job title and employer name. These are more or less generic data sets that do not normally come into play when deciding whether a call is wanted or unwanted. The present invention adds to the contact data information that controls to whom and what data can be shared. In a simple example, if a person A is in the contact data of person B, and a person C is in the contact data of person A but not in the contact data of person B, should person C call person B, that call will be considered “wanted” and thus not a robocall, simply because person C is a trusted contact of person A, who is in person B's contacts. This demonstrates the general idea behind sharing contacts.

[0016] With that in mind, it may be that person B will not want all of his or her contacts shared. For example, if person A receives a call from person C, who happens to be a hardware store, if the number of the person C hardware store is designated by person B to be public, it will be shared with person B; when numbers are shared, they will not be blocked. If on the other hand, person C is a private contact that person B does not want to share, the contact data can indicate that the contact is a “private” contact and thus the number will not be shared. In that way, if person C were to call person A, it would identify as an unknown number, given person A the option of screening the call. It could be set in data permissions that any number not in contacts is automatically screened, or blocked, or subject to additional verifications before the call goes through.

[0017] The additional properties added to each contact are those selected to preserve privacy while at the same allowing wanted calls and screening unwanted calls. Contact visibility will depend on the properties. The properties come in at least two different categories or layers of scrutiny. The first data addition is to define shareability of the contact, with a focus on the following designations: private, family, friends, public. As seen in FIG. 1, data 102 represents the basic contact data such as name and number. Contact data 104 represents what data is added to the basic data that defines the contact in a way that determines shareability 106. As noted, these data points include family 108, friends, 110, public 112, and private 114. These properties are named as stated, but could equally be represented numerically, such as number 1 is family, number 2 for friends, and so on. In setting up the data structure, a user can use either names or numbers to grant permissions.

[0018] As seen in FIG. 1, relations 116 are another additional data set to help determine shareability of contacts. The contact lists will be linked based on logic. For example, if a person A has a person B listed as a contact and both persons have contact lists, they will be linked to each other. For any user in the future, access can be granted to all contacts based on the following logic:

Family members—have access to all contacts that are shared/marked as family, friends and pubic.
Friends—have access to all contacts that are shared/marked as friends and public.
Public—have access to all contacts that are shared/marked as public.

[0019] If the person A in person B's contact list is marked as “family”, it means that person A is a family member and has family level access to the contacts in person B's list. That would allow the retrieval of all contacts marked as family, friends and public access levels.

[0020] If the person A in person B's contact list is marked as a “friend,” person A is a family member and has the friend's level of access. That would allow the retrieval of all contacts marked as friends and public.

[0021] If person A is not specially marked as either friend or family, only public contacts from person B's contact list will be provided.

[0022] Contacts marked as private will not be shareable whatsoever.

[0023] Contact retrieval works the follow ways. If person A asks for a contact, the list of all contacts that are found in the shared contact lists based on the restrictions described above should be provided. IT can be done in addition to public data that may or may not be provided as well.

[0024] Considering that someone could have thousands of contacts, the search for contacts could be extreme net wide. That should allow additional potential configurations, such as limiting search to family, or family and friends only.

[0025] Additional properties can be added to the original contact list, where those additional properties specify not to retrieve contacts from the list that belongs to a particular contact. For example, the contact is a company that has shareable contact lists and it could be a very large data file.

[0026] While data entries are typically manual, artificial intelligence (AI) can be used with or without other algorithms to order and/or limit the size of the retrieved list of contacts.

[0027] A description of how a user makes a call now follows, with reference to FIG. 2. When someone makes a call, the current strategy for robocall mitigation looks for the contacts in your personal contacts data and, in some cases, public records (white/yellow pages) and adds them to the list. When adding the sharable contacts, the lookup would be altered to add findings from the proper contact lists based on the relations between the caller and the third party's list. The contacts, with phone numbers, will be provided with the ability to call any of them.

[0028] When someone is looking for an address, the current strategy is to look for the contacts in personal contact book and, in some cases, public records (white/yellow pages) and add them to the list. With shareable contacts, the lookup would be altered to add findings from the proper contact lists based on the relations between requestor and the third party's list. The contacts, with addresses will be provided with the ability to select any of them.

[0029] To retrieve other information, contact lists can contain other information, such as, birthday and anniversary dates. Such information can be shared based on the same rules described above.

[0030] Contact sharing can be used to block unwanted calls. While there are many different strategies to block calls today, it is important to maintain privacy and avoid being overly scrutinous, to the point of blocking wanted calls. One strategy is to block all calls that are not from people designated “personal” in the contacts data. The problem that such a screen creates is that limiting incoming calls to personal contacts will block calls from doctors or car dealerships or libraries or some other third party including emergency services. While the advent of STIR/SHAKEN a caller phone number would become very reliable as an identifier of the caller, it would still be up for consideration as to whether the call is wanted or not.

[0031] The strategy to block calls from numbers that are not identified as personal can be extended to block calls that are not in the contact list of any of the contacts, based on the privacy restrictions described above. Thus, in setting conditions to not only allow just “personal” contacts but also “friends” will let more calls through, but those will be low risk of being unwanted.

[0032] The present invention is configurable to add additional ways of designating calls. A contact may be designated in a way to block or not block the call, or share or not share the contact. A “white list” can be created of numbers that are not to be blocked, while a grey list is for calls to go into voice mail, and a black list can be made of numbers to be blocked.

[0033] The addition of contact activity can be used to improve the requested results. For example, the activity of particular contact on a list, such as how many calls were made to a contact number and/or when, and how many calls were received from the contact, and time when the calls were made and their duration, all such information can be used to determine if such a number is unwanted and therefore to be blocked.

[0034] The actual information can be added to the contact list or retrieved from the Call Detail Records (CDR) available to the particular carrier involved in completing the call.

[0035] Artificial intelligence (AI) can be used to improve search and retrieval and result presentation for any of the above scenarios. Screening history can be generated and analyzed, with the analysis being used to determine if a call that passed screening before needs to be screened again, or for some period of time, or for some number of times the number calls.

[0036] FIG. 2 in flow chart form describes how in one aspect of the invention calls can be made. At 202, a user makes a call or attempts to get an address. At 204, the called number is searched in personal contacts and public records, and added to a list of contacts. At 206 shareable contacts are added to the list of contacts, based on relations setting, e.g., a private contact is not added if the person who designated the number private does not wish it to be shared. At 208, other data or information can be shared depending on the relations list. And finally, at 210 shareable contacts are used to block calls based on the relations list. In essence, once a user makes additional data entries according to relations and properties, the additional data can be used to block calls, allow calls, and to share other data as needed. The shareability of the contact can be determined by the person whose data is to be shared, thereby allowing only what the user wants to share, to be shared. Any shared information about a caller can be used to block or permit that caller to complete a call.

[0037] Although specific embodiments of the present invention have been described, it will be understood by those of skill in the art that there are other embodiments that are equivalent to the described embodiments. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrated embodiments, but only by the scope of the appended claims.