Social Account is the module that is responsible for the integration with external networks, or external software mechanisms, for the purpose of collecting personal identification of friends and peers that can be used for creating peers group.

The idea behind this module is that - communities are already out there. So there is no need to build another one for the purpose of sharing CG Widgets. Instead since communities and circles of friends are all around it will be more convenient and provide greater advantage to use those existing communities for the purpose of preparing available contacts for adding into peer groups.

CG is therefore capable of connecting with external networks for getting personal identities. We describe these networks as Personal Identification Networks – PIDN, as depicted schematically below.

CG connects through API provided by PIDN networks and brings collections of personal identities related with user’s own account on those connected users.

For example:

Connecting with Google or Yahoo accounts of a user and bringing list of contact emails

Connecting with social network such as Facebook and LinkedIn and bringing list of friends

Connecting with CMS (e.g. Wordpress) or CMF (w.g. Drupal) based websites and getting interrelated account users as per current user account 

Once connecting with a PIDN a list of contacts and friends is loaded. This list is subject to restrictions that will be described later. Permitted contact identities can be added to peers group for sharing some Widget with.

PIDN Ad Hoc grouping

One important note is that PIDN Is not limited to integration with existing networks where user’s account and contacts can be founds. While external networks are usually used for creating peer groups from among known circles of friends and contacts, these networks have less usage in the case of Ad Hoc peers groups. In the case of Ad Hoc groups the group contains people that share a very specific situation that is being defined as a context for sharing information. In those cases PIDN module functions for detecting members and joining them into some Ad Hoc group. For example, in the case of an application that wants to allow sharing of information with all passengers at a specific train line, PIDN module has an implementation that helps to define passengers on the train as belonging to an ad hoc group of passengers on this specific train. Another example, assuming that Content Glass application wants to provide sharing of voice notes for vehicle drivers in the context of radio programs. In this case PIDN module contains an implementation that allows ad hoc grouping of drivers to currently listen to the same radio program and this information will serve the application possibly in combination with information gathered from handhled device connected to vehicle information system, to allow fine tuning of ad grouping so that a group includes only the friends of the person (standard PIDN) that currently listens to the same radio program (ad hoc PIDN).

Custom Implementations

CG wants that any networks that is capable of providing with personal identities and account related contacts, will be potentially available for users for the purpose of data sharing. Accordingly CG API provide and interface (or abstract implementation) of and Integration code with PIDN.  

The interface may be implemented in order to create custom implementation for connecting with PIDN.


For CG to collect list of permitted contacts and friends from user’s own accounts, it is required for user to sign-in the relevant networks. Sign-in is handled using an API for the external networks connected with and is usually include two steps:

Setting credentials such as user/password

Authenticating access to resources

Once sign-in a list of contacts can be loaded and then can be used for adding into peers group.

Restricting Contacts

It is known especially in relation to social-networks that some people tend to create huge lists of friends which are not thoroughly part of their close circle. For example one can have 500 connections on LinkedIn but personally one is familiar with only 20 of them. Since CG by its nature presents shared content on top of other contexts, it is intend for sharing with close circle of peers that are willing to be exposed with the data. Otherwise it will become an unbearable advertising and marketing tool that will miss its initial purpose.  

CG system provides a combination of several solutions that are combined for the purpose of solving this problem.

  1. Setting Contacts scope: this is an advanced setting that allows user to choose a supported PIDN scope from where contacts will be loaded. For example setting a specific Contacts group in Google to limit the list of contact to those in the group. Contact scope be unidirectional meaning that difference scope may be defined for sharing operation and viewing of shared content, or bidirectional meaning that the same scope is applied to shared content and viewing of shared content as well.
  2. Setting Include Exclude lists: This is an advance setting that let user set a list of contacts to be included from given PIDN. Only those contacts in the include list will be available for setting as peers in the peers group settings. On the same manner user will be able to set  a list of excluded contacts, in order to prevent from certain contacts to be available for setting in peers group. Exclude and Include lists are may be unidirectional meaning that different lists may be set for sharing operation and shared content  or  bidirectional meaning that the same list can be applied to shared content and sharing operation as well.

Caching of contacts and personal identifier

In order to prevent repeated need to sign-in and bring contacts data the information is saved in cache once loaded. The information can be refreshed either by requesting to refresh or after Log off, and sign-in again. 

This way the burden of sign-in again and again is saved from user and the UX is of smooth work without many interruptions with regarding to PIDN. 

Non deterministic regarding Glass

We assume that the event of connecting with PIDN is not a preliminary condition for Glass to work. Glass may work without any PIDN to be connected. PIDN network is assumed to be either connected or not connected once Glass is created and started.

Accordingly at the moment of Glass creation:

  1. Shared information in regarding with personal-identifier of some PIDN may be shown or not depending the user is connected or not with the PIDN.

User can add to peers groups only those contacts of currently connected users.

Also, new connection may start during Glass operation time so that:

  1. Shared data may need to be fetched based on connected network event. When a connection is ready, go and get a related shared data.
  2. The lists available for creating peers-groups need to be updated accordingly.