WO2015125070A1 - Content-glass - multidimensional state oriented sharing - Google Patents

Abstract

A method of multi-dimensional state oriented sharing over the Internet comprising sharing data relating to an object according to sharing context defined by the object state.

Description

CONTENT-GLASS - MULTIDIMENSIONAL STATE ORIENTED

SHARING

TECHNOLOGY FIELD

The present invention is in the field of content sharing and manipulation and provides a new paradigm of content sharing: Multidimensional State Oriented Sharing, referred to as Content Glass (CG).

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS This patent application claims priority from and is related to U.S. Provisional Patent Application Serial Number 61/943,381 , filed 23 February 2014 and U.S. Provisional Patent Application Serial Number 62/053,814, filed 23 September 2014, these U.S. Provisional Patent Applications incorporated by reference in their entirety herein.

BACKGROUND

Sharing on the Internet is a well know phenomenon. Forums, short messaging apps, Web2.0 Social networks, link and media sharing are all examples of sharing applications derived by various sharing paradigms. Here are some of the questions arising when analyzing sharing paradigms:

• Where does the sharing event occur? Is it happening in a specific website or app or is it happening elsewhere? Are shared content and the sharing act centralized or is sharing happening and being distributed all around? Does sharing occur on a virtual dimension only or can sharing take place in direct relation with objects and thing in our material life? • What type of information is being shared? Is sharing limited to certain media such as text or images or does it allow wide range of information to be shared by wide range of approaches? Does it allow applications to be shared? Does it allow physical and physiological measurements to be shared?

• Is sharing 'positive' only i.e. exposing a content that is added to the field? Is negative sharing also possible by any paradigm i.e. can absence of content be shared?

• What is the core essence of the human act behind the sharing behavior? Is this act focused on the content? Maybe on creating a buzz, maybe on referring to some interest or maybe this is the "self" that is reflected by the sharing act?

• How are users recognized and identified? Is there a centralized account for recognizing users as being sharing entities? Is it a close system for limited accounts or an open system in which users can be referred to by custom accounts?

• How is information distributed among users? Can online collaboration be shared or is it limited to offline sharing? Can meta-data be shared and translated on the fly into sharing functionality or content?

· What are the relationships between the shared content and its underlying context? Are there any relationships at all? Is the sharing context a website, app or maybe any arbitrary object?

• What is the exposure scope of shared data? Is it public, maybe limited to a closed group? Maybe private only? Is exposure of shared data modulated by other states and conditions?

• Is the sharing act only an event of referring some "idea" to some "object" or can a sharing event also function as an object in itself?

Content Glass platform presents an innovative approach regarding to all these questions. With Content Glass the status of sharing is shifted from the level of social application to the level of building-block. A building block that enable the injection of state oriented content sharing into a wide range of applications in a wide range of categories. With Content Glass sharing is stretched far beyond the social-network purpose toward a broad practice of state oriented content manipulation.

SUMMARY According to a first aspect of the present invention there is provided a method of multi-dimensional state oriented sharing over the Internet comprising sharing data relating to an object according to sharing context defined by the object state.

The object may be selected from the group consisting of physical and virtual objects.

The object state may be selected from the group consisting of: codes, paths, URIs, physical and physiological factors, locations, time, verbal words or phrases, marks, signs, conditions, functions, states and events that define a specific state or condition of the object. The object state may comprise mandatory fields and optional fields.

Sharing may comprise creating and sharing widgets of various types.

The method may further comprise a transparent layer of software (Glass) that allows widgets to be layered on top of or in relation with external context.

A glass may comprise a glass type representing the sharing context type and a glass ID representing the sharing context state.

The glass type may be a representation of the context selected from the group consisting of: website, object and place.

The widget types may be selected from the group consisting of: basic widgets, connector widgets, tagging and stamping widgets, context customization widgets, service port widgets, resource proxy widgets and virtual widgets.

The widget may be shared offline or online with a group of peers.

The group of peers may be selected from external networks. The group of peers may be selected by a user.

The group of peers may be created ad hoc by an application from peers that share the same state of the object.

Online sharing may comprise peers in the group communicating over a P2P network.

The method may further comprise defining relations between widgets in a linkage graph.

The linkage graph may be viewed on-demand.

The relations comprise linkage of one of application properties, glass type, semantic of glass identifier, widget content, tags, association or proximity and grouping relationships.

The method may further comprise defining interactions between widgets on the same linkage graph.

The interactions may be selected from the group consisting of: data copy, data merge, data override, operational link, widgets swap, tagging, semantic grouping and shared action.

The method may further comprise defining rules by which a trigger related with given state of an object invokes an action on a given widget.

The trigger may be selected from the group consisting of: scheduler, software state and widget state.

The action may be selected from the group consisting of: visual changes to the widget, changes in widget content, widget operation and running code.

The method may further comprise storing said widgets both locally and remotely. The local storage may comprise one of: DOM memory, 'pending' local store, 'modified' local store, 'deleted' local store, 'context' local store, 'personal' local store and 'utility' local store. The method may further comprise synchronizing between said local and remote stores.

The method may further comprise storing said widgets in a personal remote storage means owned by the user. According to another aspect of the present invention there is provided a state- oriented sharing application for implementing a method of multi-dimensional state oriented interactive sharing of content in marked places set on top of internet assets, comprising: setting by the owner of an internet asset at least one marker widget on at least one specific location on the internet asset; selectively displaying the at least one marker widget on top of the internet asset; placing a content widget by a content owner in said at least one marker widget; and displaying the content widget on top of the internet asset in the set place.

The internet asset may be selected from the group consisting of: website, web application and mobile application.

Selectively displaying may comprise displaying by request.

The marker widget may comprise at least one state identifier and wherein said content widget is displayed selectively according to said state identifier.

The state identifier may comprise at least one of place and time. Placing a content widget may comprise placing the content widget for a limited time.

According to another aspect of the present invention there is provided a state- oriented sharing application for implementing a community based method of providing multi-dimensional state oriented interactive expert assistance to visitors of a website or online application, independent of the underlying website or application, comprising: placing at least one expert widget on the website or application view by one or more expert users to create or join an experts-network; defining said experts as a peers group; displaying an experts-toolbar widget on top of said website or application view; and conducting an on-line session using collaboration widgets. Conducting an on-line session may comprise: sending by the user queries to the experts-network; and distributing said queries among experts of said website. conducting an on-line session may comprise: selecting by a user an expert from said experts toolbar widget, adding the user into the peers-group of the experts-widget related with the selected expert; and using collaboration widgets and dashboard to exchange information.

The collaboration widgets may be selected from the group consisting of: chat widgets, co-browsing widgets and co-reading widgets. According to another aspect of the present invention there is provided a state- oriented sharing application for implementing a method of sharing information between a desktop resource on a remote device and user's device,

comprising: providing a resource-proxy widget on the user's device for:

connecting with the remote desktop; connecting with a remote instance of a resource-proxy widget that mediates the interaction with the desktop resource; checking the availability of the desktop resource on the remote device;

establishing connection with the desktop resource; and establishing a data stream between the user's device and the desktop resource.

The desktop resource may comprise a file. The desktop resource may comprise a peripheral device.

Establishing a data stream may comprise reading from the file via a P2P data channel.

Establishing a data stream may comprise writing to the file via a P2P data channel. The resource-proxy widget may hold only meta-data that refers to the resource on its original desktop.

Connecting with the remote desktop may comprise using one of broadcasting technology and sharing desktop UID and address via shared DB. The method may further comprise setting said desktop resources in the form of a mini-portal.

The mini-portal may comprise a user created layout with content found in files set on the desktop. The mini-portal may be created using a portal-widget.

According to another aspect of the present invention there is provided a state- oriented sharing application for implementing a method of creating and sharing a personal interactive portal on a user computer's desktop, solely from resources hosted on the desktop. Creating a personal interactive portal may comprise: defining a new portal; designing a layout for arranging content; and selecting desktop resources to present in the layout.

The resources may comprise files.

According to another aspect of the present invention there is provided a method of sharing widgets in the context of search engine results, comprising: defining search terms used for the search as state identifiers; and defining widgets to be shared according to said identified states.

The method may further comprise grouping two or more results into a virtual widget. The virtual widget may be stored in relation with the same state identifiers.

The search engine may be a widgets search engine and the search results may be widgets.

Using said virtual widget may comprise comparing a URL saved with the virtual widget with URLs in the search results. BRIEF DESCRIPTION OF THE DRAWINGS

For better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental

understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In the accompanying drawings: Fig. 1A is a schematic representation of prior-art profile oriented sharing;

Fig. 1 B is a schematic representation of prior-art content oriented sharing;

Fig. 1 C is a schematic representation of prior-art link oriented sharing;

Fig. 1 D is a schematic representation of prior art short messages sharing;

Fig. 2 is a schematic representation of state oriented sharing; Fig. 3 is a schematic block diagram showing personal and shared CG content;

Fig. 4 is a schematic block diagram showing a general overview of CG API usage in multiple environments;

Fig. 5 is a schematic block diagram showing the main modules of the CG API;

Fig. 6 is a schematic block diagram showing glass interrelating between context identifier and widgets;

Fig. 7 is a schematic diagram of the Social Account module of the CG API;

Figs. 8 and 9 are schematic diagrams of the P2P module of the CG API; Fig. 10 is a schematic diagram of the Content Linkage module of the CG API;

Fig. 1 1 is a schematic diagram of the views module of the CG API;

Fig. 12 is a schematic diagram of the Device Adapters module of the CG API;

Fig. 13 is a schematic diagram of the Themes module of the CG API; Fig. 14 is a flowchart showing the creation process of a glass instance;

Fig. 15 is a schematic block diagram showing the interface for managing widgets;

Fig. 16 is a schematic block diagram showing the interface for managing views; Fig. 17 is a schematic block diagram showing the widget rendering control operations;

Fig. 18 is a schematic block diagram showing the glass lifecycle events;

Fig. 19 is a schematic representation of creating custom glass

implementations; Fig. 20 is a flowchart showing the process of glass and widget creation;

Fig. 21 is a flowchart showing the process of searching widgets related with given glass type and glass Id;

Fig. 22 describes schematically the idea of compound state;

Figs. 23A and 23B describe schematically glass state layers; Fig. 24 is a schematic block diagram showing different glass patterns;

Fig. 25 is a schematic block diagram showing a website-glass relating widgets with web page URL identifier;

Fig. 26 is a schematic block diagram showing a website-glass relating widgets with website domain identifier; Fig. 27 is a schematic block diagram showing a website-glass relating widgets with top level domain identifier;

Fig. 28 is a schematic block diagram showing an application-glass relating widgets with some given application identifier; Fig. 29 is a schematic block diagram showing a location-glass relating widgets with some location identifier;

Fig. 30 is a schematic block diagram showing an object-glass relating widgets with some object identifier;

Figs. 31 A and 31 B are schematic flowcharts showing use of identifier assigned to an Image as Glass Id;

Figs. 31 C and 31 D are schematic flowcharts showing use of a code to store and fetch widgets;

Figs. 31 E and 31 F are schematic flowcharts showing use of text to identify the object; Figs. 31 G and 31 H are schematic flowcharts showing use of some physical condition detected to fetch related widgets;

Fig. 32 is a schematic block diagram showing a place-glass relating widgets with some place identifier;

Fig. 33 is a schematic block diagram showing a device-glass relating widgets with some object identifier;

Fig. 34 is a schematic block diagram showing core widget operations;

Fig. 35 is a schematic representation of creating custom widget

implementations;

Figs. 36 through 38 are schematic block diagrams showing different memory regions and interrelations between them;

Fig. 39 is a flowchart showing the CG storage module operation during sync; Fig. 40 is a block diagram showing ordinary SaaS vs. computational SaaS (CSaaS);

Fig. 41 is a block diagram showing CG as computational SaaS;

Fig. 42 is a block diagram showing ServicePort Widget as CSaaS adapter; Fig. 42A is an example of personal consolidation service using ServicePort; widget

Fig. 43 is a schematic representation of the semantic grouping of widgets; Fig. 44 is a schematic block diagram of the Triggers & Actions module; Figs. 45-51 show schematically the markers glass technology; Figs. 52-56 show schematically the expert glass technology;

Figs. 57 - 69 describe schematically the desktop glass technology; and Figs. 70 - 75 describe schematically the glass for search technology;

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention provides a new paradigm for content sharing: State Oriented Sharing, referred to as Content Glass (CG).

CG comprises technology and methodology.

State Oriented is the sharing paradigm described by CG system.

Sharing on the Internet as it is known to us may be described by different paradigms based on the central concept in the sociological perspective: 1 . Profile Oriented Sharing (Fig. 1 A): this is the sharing as we know it from social-networks such as Facebook, Twitter and even Linkedln (that may be thought sometimes as content oriented but is not). The core in the act of sharing is the personal profile as a virtual reflection of the "I" (my photos, my thinking, my job, my short messages, my business connections). Modern discussion boards and chat based applications may be included in this category too. The personal idea is what is important.

2. Content Oriented Sharing (Fig. 1 B): this is the sharing as we know it from Forum and Blog websites. The core of the sharing act is highlighting or putting in focus the posted content. Sharing is around content and is managed in the form of discussion or commenting.

3. Link Oriented Sharing (Fig. 1 C): this is the sharing as we find it in what is called social-media sites, in which users post some link with a short description and possibly an image. The core in the sharing act in this case is either "showing interest" in a subject or "pointing to interest" in a subject. Link oriented sharing is flourishing among internet marketers as a method of creating back links to e-Commerce websites.

4. Short Messages sharing (Fig. 1 D): this type of sharing exists in

applications that let a community of users and/or groups exchange short messages (text or content) between them. The essence of messages-sharing is to "amplify" user's everyday experience and ordinary events. It works like an amplifier of thoughts and feelings; "making a noise", generating a short term excitement or buzz or gossip around some issue.

Content Glass presents a new paradigm of Sharing: State Oriented Sharing, as schematically depicted in Fig. 2. There are a number of characteristics to this type of sharing:

1. Contextual sharing: Sharing act is related with an identified state of "object" in the world. This state of an object functions as the sharing context. Shared material is attached with object state. State is made of a combination of object identifier (URL, bar-code, text, QR-Code, number etc.) and one or more dimensions related with state application or user dimensions that can be used separately or in combination (location, time, ambient temperature etc.). Object in this context does not refer only to some physical object. Website is an object, Place is an object, Radio program identified by Radio Data System (RDS) signal is an object, Chair is an object, application is an object, Book is an object, a Chapter in a book is an object, even a Word may be considered as the object on which someone is sharing. Anything whose state can be identified is an object.

In the case of Content Glass the essence of the sharing act is relating the shared content with an identified state of an object or thing - hence State Oriented Sharing. The act of sharing is not anymore "talking about something" but is becoming "talking on top of

something". And out there content, things, interest and person are merged.

Multidimensional: The sharing context can be determined by a combination of multiple dimensions that compose together a state related with an "object" and/or application and/or user. For example: location, time, user gestures on screen and more.

Layered: Shared content is presented on layers. Multiple layers may be combined to show shared content associated with different sharing context states. Sharing is not limited to static or fixed content. Dynamic content can be shared too. For example, an Application and its resulting product can be shared.

Not website oriented: CG is not website oriented sharing. The sharing may apply to any object where Glass Mechanism can be used to create the relation between object identifier and shared content.

Decentralized: CG is decentralized and is all around. No single app, or single website where sharing occurs. CG API encourages developers to share anything valuable and anywhere possible.

"Green": CG is Green to virtual environment by means of a

technology that is intended to share data only in the relevant scope of audience. CG sharing is built for relevancy. Data is usually shared by close relevance circles.

Accountless: CG does not require dedicated content glass account to be created as precondition for usage. Instead, CG uses an existing user's accounts from internet communities and social networks

(referred to by the general term: Social Accounts). The accounts are already there, and CG has the infrastructure to use them for the purpose of sharing. CG Account may also be created, and may also be used for sharing (can act as Social Account) however, it is optional and required only for advanced features and/or premium services.

9. Ad hoc grouping: the concept of ad hoc grouping is widely used (in addition to more traditional concept of fixed circles of friends). Ad hoc grouping is a volatile group of people that share data only in relation with manifestation of the context with which sharing is related. For example, group of people that currently listen to some radio station or current passengers in a specific train etc.

According to CG, content is shared in relation with object identifiers and this can happen all around. There is no single type of objects to which sharing refers. The referred "object" is arbitrary and becomes a subject for sharing using CG and with relation to some object Identifier. Sharing may refer to website content, GPS coordinates, object, code, word, phrase, given service etc.

CG associates Object identifiers with data that is shared by an individual or a machine (software) and is targeted toward limited and/or focused group of peers.

Glass Factor: The common trait for all CG implementations is the Glass Factor; the ability to present personal and closed-circle content in relation with state, identifier or condition of external context: web page, domain name, object, place, radio/TV program, application's view or state, device and more. The Glass is a transparent layer of software that allows content to be layered on top or in relation with external context.

Sharing is not limited to Web (i.e. network of websites and web services). With CG, sharing gets out of the Web toward the Objects and identifiers around us. In the same manner the act of sharing gets out of Web Browser boundaries and is embodied by mobile devices, wearable devices, vehicle media systems or even microcontrollers (that operate as a non human peer which takes part in the act of sharing).

Content Glass extends the discourse of sharing and this occurs on three axes: Content, Context and Scope. With reference to content - CG goes beyond the act of sharing text, images and voice toward sharing of physical and bodily measurements such as heartbeat or environmental sound as well as computer resources such as files and printers.

With reference to context - CG goes far beyond the web sphere and suggests the world of things around as an endless place where identified state of objects can be used to relate shared content with a given context. CG actually brings sharing to the things while previous sharing approaches bring things or more accurately a reflection of things to closed sharing arenas.

Finally with reference to scope - CG goes beyond the traditional circles of friends and people that share interests and suggests to look at the world as a place of endless ad-hoc situations in which sharing can take place between human participants but also between humans and machines.

State Oriented Sharing apps: Content Glass is a platform and a set of frameworks for creating state oriented sharing apps. It provides tools, reference implementation and code libraries, for different environments and using various programming languages.

CONTENT WIDGETS

A widget as known in the art is a stand-alone application that can be

embedded into third party websites by any user, on a page where they have rights of authorship, e.g. a webpage, blog, or profile on a social media site. Widgets allow users to turn personal content into dynamic web apps that can be shared on websites where the code can be installed. Throughout this description the term Widget or Content Widget refers to a single content item presented on a specific content glass layer. The exact technology of drawing the Widget may vary between glasses.

Depending on the specific context and Glass based application, widgets may have various graphical traits and functional features. For example:

1 . Editable: content on a widget may be editable and a widget may be deleted.

2. Persistence: a widget may include internal persistence management.

3. Minimize/Extend: a widget can be shown as minimized or extended. 4. Draggable: a widget may be defined as draggable on the underlying view on which it is presented.

5. Resizeable: a widget may be defined as being able to be resized.

6. Group scope: a widget may be defined to be accessible by a group of peers.

7. Online real-time stream: a widget may be defined to allow real time online interaction with parallel presences of the widget presented to other peers.

8. Linkage: a widget can be used as a reference point for finding a

linkage graph - other widgets related by semantic relations.

9. Trigger and Action: a widget may be defined to react to some trigger. 10. Open API: widgets behavior may be controlled and/or modified

programmatically by an API provided by CG system. The API is open for developers to shape their own state oriented apps based on specific application needs and requirements.

These features and more are available based on the type of glass and on application needs. Some applications may limit part of the functionality. For example, in some applications widgets are shared with users but users have no control and have no management access to widgets. Another example: some applications may enable real-time streaming between widgets and other applications may disable it. Thus, the list of available and used features is variable. General Types of Widgets:

1 . Basic: a widget that can be used to share textual, vocal or visual data.

For example text box, picture, video, document reader, profile capsule, vocal note, etc. It is call "Basic" because it does not use complex logic.

2. Connector: a widget that is used as a tool for real-time collaboration between two or more peers in relation with given resources. For example, Form-Connector widget is used to allow peers to fill form fields together without taking control over each other's device. Other examples: Share-Screen widget and Co-Browsing widget.

3. Application: a widget that includes some dynamic application logic. In the case of application widget, the shared content is not fixed or static. The shared data is application state and/ or user activities. For example Shopping-List, Expert-Widget, Floating-Form.

4. Service Port: proxy to personal interaction with service providers.

Service port widget provides an interactive port for either getting or setting personal data related with some service, as will be explained in detail below.

5. Resource Proxy: These widgets act as proxy for managing remote and shared interaction with resources such as files, printers, storage and other desktop resources. This type of widgets is used by Device Glass applications (for example Desktop-Glass framework) as will be described below.

6. Virtual Widgets: These widgets are created by Semantic Grouping operation applied on two or more widgets found on Linkage Graph or from semantic grouping of search engine results (see Glass for Search framework). Virtual Widgets represent relation between other widgets. By storing the relations between widgets or other entities (such as search result items) in the form of Virtual Widget, CG provide a mechanism for extending existing content stores. This can be applied to the store of widgets inside content glass system, but the same principle can also be applied to other content stores such as content stores used by search engines. And of course the uniqueness of this content extension is that it can be created by the "consumers" of the content who contribute their own semantics and interpretations to the content store (see 'Semantic Grouping Of Widgets' below).

General mechanism of sharing:

User generated content in CG is either personal or shared between peers. For CG content to be shared, a Widget is required to be related to some user identifier. User identifier and user contact are taken from existing accounts already owned by User, for example Email address, an ID on some social network, registrant ID on some website etc. CG has integration mechanisms with various Social Accounts (Google, Yahoo, Facebook, etc). Once a user signs-in to one or more social-accounts the ID of the user's account and related contacts of this account are fetched. Account IDs can then be related with a Widget so that when the user signs-in with a related account, he is capable of viewing the shared content globally, independent of the local storage on which the content was initially created. User can also share the Widget with contacts or friends by assigning a peers-group made of fetched contacts. The peer users can watch the Widget by being signed-in with the account that was set in the peers-group.

As depicted schematically in Fig. 3, when creating content, depending on the specific glass, the content may be stored locally 100 in the device memory until it is related with a User Identifier 1 10. Without relating the widget with a personal identifier, content is limited to local access. Once user identifier is assigned to the widget, the widget is stored on the CG remote storage 120, and thus becomes available, in relation with the same glass-id, also when using other devices 140. For example, a widget that has been created on top of www.contentglass.com is first stored locally in the browser's local storage. At this phase the widget is available locally and cannot be accessed from other browsers or other devices. To make it available remotely, the user has to sign-in via Networks Interface in one of the specified integrated Social Account Networks (Google, Facebook, Yahoo, Twitter, other custom integration that can reflect user identifier and is able to reflect interrelation between users...). Once this is done, the widget is stored on the CG remote database that will make it available to this user from other browsers and devices, as long as the user is signed-in to the relevant accounts (using Networks Interface).

To make the widget available also for other peers, those peers need to be included in the Peers Group 130 of the Widget. User can sign-in to accounts to get lists of contacts and friends that will be added to the peers group of the widget. Once a peers group is set, the widget becomes available also to the selected peers (assuming they are signed-in in the Networks Interface). Those peers are able to view and/or edit and/or use the widget (depending on permissions).

Offline VS Online sharing

CG content can be shared offline and online with a group of peers.

Offline: Offline sharing means that a widget set by Person-A at time T1 can be watched, managed and used (depending on permissions) by Person-B at time T2 where T2 > T1 .

Online: Online sharing means that a stream of data can be open between two or more peers that share a widget so that content and activities can be shared in real-time (T1 = T2).

CONTENT GLASS API (Application Program Interface) OVERVIEW

Fig. 4 is a schematic block diagram of the main components of the CG system 5000, comprising:

A server 5010 comprising a CG server API 5020, P2P connectivity 5030 and a widgets database 5040, all described in details below; and A plurality of peripheral devices, each comprising a corresponding CG client API 5050 communicating with the server API, as described in details below.

Implementation of CG is done using Content Glass API, which includes different tasks such as but not limited to:

- A logic for relating context identifiers and widgets - Rendering and managing widgets

- Widgets settings and preferences

- Defining peers groups for widgets

- Interacting with networks of personal identities for collecting potential peers

- Storage control mechanism

- Data stream mechanism

The API can be separated into two major parts: Client API and Server API. These two parts works together to achieve CG functionality. CG Client API is implemented for multiple OS platforms and technologies. For example: Web technology (JS-+HTML+CSS), Android, iOS, Wearable devices, Java, .Net, Desktop, Infotainment and other.

CG Server API is implemented using conventional server-side programming and in accordance with system performance requirements and productivity considerations.

CG API MODULES

The following description pertains to the major technical concepts shared by CG APIs 300, embodied in the following main modules, as schematically depicted in Fig. 5:

Glass module 310

Glass module is responsible for implementing glasses. The purpose of a glass is to be able to interrelate between context identifier and widgets, and provide the layer on which a widget can be drawn as interrelated with the underlying context, as schematically depicted in Fig. 6.

A Glass 200 is software that provides a layer for drawing widgets on top of, or in relation with context identifiers 210. So there are three terms that need to be understood in order to grasp the concept of Glass: Context 220:

A Context is 'something' with which we would like to interrelate with CG widget 230. In other words, we can say that context in terms of Content Glass is some object in the world used as the 'substance' for sharing information. For example, a website may be context with which we interrelate widgets. Similarly, domain name, location, physical objects, images, places, view in an application, radio program, TV station, words, phrases, sound spectrum and more are all potential contexts for relating with CG widgets. Any object in the world that may have virtual representation and an identification that can be expressed as some "code", "state", "function" or other common trait, may potentially be considered as context for CG sphere. The Context is arbitrary and CG Client API provides the means for creating new implementations of glass for sharing in relation with various contexts. CG API may come equipped with some predefined glass Implementations for general contexts. Developers can use the API for creating new implementations.

State Identifier in a context 210:

The identifier is some mark, sign, condition, state, function or event that defines a specific state or condition of a context or object in the world that may have a virtual representation. For example, given radio programs content as context, we can say that the program code received by RDS (Radio Data system), e.g. name or some binary code, is an identifier. Another example: given a website as a context, we can say that the URL of a web page is an identifier, or we can say that top level domain (the domain name without the www or other prefix) is an identifier. The use of the identifier concept allows CG to interrelate widgets with specific states of the context. In other words, the presence of a widget is given in a certain scope of a certain condition of the interrelated object.

Practical considerations during development of reference applications show that in some cases it makes more sense to represent a state of the context by separate fields that represent multiple dimensions of the context rather than composing the fields into one complex representation of state. Representing state by multiple fields and storing state data by dimension related registers makes the task of finding shared content for a given state of the context much easier.

This approach for representing the state of a context therefore includes Glass Type, Glass Id and additional optional fields that represent various dimensions of the underlying context. The additional identifiers are optional, so it is up to the application developer to decide if a state is to be represented by major parameters only (Glass Id and Type) or using the major parameters combined with one of the optional identifiers. This is a practical decision that needs to be made based on the specific behavior required by the application. While sharing context is defined by specific state of affairs, CG also provides the ability for defining a semantic state. While 'state of affairs' sharing context is based on concrete measurable values that represent a state: codes, image attributes, temperature, time and other, a 'semantic' state is based on

"meaning". For example: in the case of CG system that represents the sharing context by state-of-affairs, two pictures of Eifel tower, used for associating with sharing context can be matched by similarity in image characteristics. It means that taking two different pictures of the same Eifel tower may not match and therefore may not be used as representation for the same state, and therefore parties may not discover each other's shared content. However, In the case of CG system that uses a semantic state a picture of Eifel tower as it stands can be matched with a picture of simulating Eifel tower falling, because "Eifel tower" as a "term" or "meaning" does not depend on actual image characteristics but on our Language concept (Signifier) - Eifel Tower. Accordingly, CG system that uses a semantic representation for sharing context states is able to associate shared content with the meaning referred to objects and this is handled for example by extracting key terms from lingual descriptions users assign to sharing context objects.

Glass 200:

The Glass is the intermediate layer that allows CG widgets to interrelate with contexts. Glass is the main controller of underlying sharing activity. Since contexts may vary, glasses may have different implementations. Having these terms in mind (Context, State identifier and Glass) explains why CG is actually a state oriented content sharing technology. CG is about sharing information in relation with states of objects in the world. CG refers to Object as a context for the sharing act. The information, in the form of CG widget, is shared in relation with identified state of an object. The software layer responsible for this type of interaction between shared information and objects in the world is named Glass.

Widgets module 320

Widgets module is responsible for drawing and managing widgets. Widgets are the content items created and shared by peers. Widgets are drawn on top of a glass, always in relation with an identifier of the underlying context state. To a great extent widgets may be regarded as ad-hoc pieces of data spread in the world and attached with the objects around us. The ad-hoc nature is given by relating the information (widget) with very specific state of affairs. Storage module 330

The Storage module is responsible for Content storage and has major significance in the sharing logic. On CG user data is set both locally and remotely. This allows usage of widgets also without relating the data with a personal account. When data is stored locally it cannot be shared, and is kept personal, without network signature. On the other hand, once data (Widget) is related with one or more personal accounts, it is stored also remotely. This allows sharing of the data and watching the data on other devices of the user.

Social Account module 340

Social Account is the module that is responsible for integration with external networks, 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 already exist 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 is more convenient and provides greater advantage to use those existing

communities. CG is therefore capable of connecting with external networks for getting user identifiers. We describe these networks as Social Account Networks, as depicted schematically in Fig. 7.

CG connects through API provided by Social Account networks and brings collections of contacts related with user's own account.

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 Linkedln and bringing list of friends;

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

Once connecting with a Social Account, a list of contacts and friends is loaded. This list is subject to restrictions that will be described below.

Authorized contact identities can be added to peers group for sharing some Widget with.

Ad Hoc groups

One important note is that Social Account 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 Social Account 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, Social Account module has an implementation that helps to define passengers on the train as belonging to one specific group 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 specific radio programs. In this case Social Account module contains an implementation that allows ad hoc grouping of drivers that currently listen to the same radio program. To narrow the group of listeners the module may also combine information taken from user profile, such as user's contacts.

Custom Implementations of Social Account

CG aims that any networks that are capable of providing user identifier and related contacts, will be potentially available as a source for gathering users, for the purpose of data sharing. Accordingly, CG API provides an interface (or abstract implementation) of Social Account Integration

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 a close circle of peers that are willing to be exposed to 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 a user to select a supported scope from where contacts will be loaded. For example, setting a specific Contacts group in Google to limit the list of contacts to those in the group.

2. Setting Include-Exclude lists: This is an advanced setting that lets users set a list of contacts to be included from given social accounts. Only those contacts in the include list will be available for setting as peers in the peers group settings. Similarly, users will be able to set a list of excluded contacts, in order to prevent certain contacts from being available for setting in peers group. Caching contacts and user 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 signing-in again and again is saved from users and the UX is of smooth work without many interruptions with regards to social account.

Social Account is non deterministic regarding Glass

We assume that the event of connecting with social account is not a

preliminary condition for Glass to work. Glass may work without any social account to be connected. Social account network is assumed to be either connected or not connected once Glass is created and started. Accordingly, at the moment of Glass creation shared information related with user accounts may be shown or not. User can add to peers groups only those contacts of currently connected social accounts. Also, new connections 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.

Group module 350

Group module is responsible for management of peers group. Groups are created from collecting user contacts provided by Social Account module. In order for a user to use contacts or friends from a give network, he must first sign-in using user's account credentials. Once user is signed in, he can choose among available contacts and select the peers with whom he would like to share the content. A peers group can be defined individually per widget. A group may also be saved and be reused for other widgets. Peers-group is a list of contacts for sharing content with. Peers-groups is assigned with each Widget either explicitly or by user interface. Contacts in a peers-group are able to view and possibly edit the shared Widget, assuming they are signed-in with their user identifier set in the group. Peers-group may be defined programmatically by application or manually by user.

Here is an example, assuming a TextBox widget with a group that includes:

1 . tiram.gilad@gmail.com

2. rhizome.networks@gmail.com

3. facebook.com/gilad.tiram

There are three contacts in this group. A user who is signed-in with either of these contacts (possibly more than one) will be able to view the shared Widget (conditioned by sharing context state parameters).

In the case of Ad hoc grouping users do not manage the peers-group themselves, rather it is managed by the application Peer To Peer (P2P) module 355 (Figs. 8, 9)

P2P module is responsible for integrating with P2P network suitable to the environment in which the application is running and provides P2P data channel, video channel and voice channel.

P2P is used by CG for features that require real-time collaboration between peers. P2P allows data to be transmitted between peers so that content can dynamically change for all the participants in the P2P session.

Voice and Video Channels

Voice and Video channels are used by CG for the purpose of creating Chat widgets, and also screen captures. Chat widgets are widgets that use P2P channels for the purpose of chat. This may be short messages chat, voice chat, video chat or the combination of those.

CG system provides default Chat widget but other chat widgets can be created using the API. Data Channel

Data channel is a P2P module that can be plugged with a Widget in order to provide real-time collaboration. Many of the Widgets provided by CG use this module. This module interacts with various changes in the state and content of a Widget and distributes those changes between collaborating peers, in the form of messages. For example TextBox widget uses data channel to send to parties the text content so that parties are able to edit the text together.

Another example, P2P data channel is used by some Widgets to distribute changes in the position and size of a Widget so that position and size is coordinated automatically between peers.

P2P on different platforms

P2P technology may be implemented differently on different platforms. For example WebRTC on the new web browsers, JXTA on Java platform, SIP, wifi.p2p for Android, Open Peer for iOS and other. CG uses existing P2P technologies for implementing the required P2P functionality.

Content Linkage module 360 (Fig. 10)

When talking about Content Linkage we arrive from a perception that can be described as Glass Sphere. It means that we do not look at a single widget as standalone in the world but we perceive all the shared content as one big sphere with semantic relationships between its parts (the widgets)

Content Linkage is a semantic and operational linkage between Widgets. The module is responsible for various operations of invoking a Linkage graph search, which is an operation for finding widgets by semantic relations as well as invoking operations for settings relations between widgets found in the search.

Linkage module uses an API for searching Linkage between stored widgets which is partly client-side and partly server-side.

Content Linkage is what makes CG more than just a way for setting distinct Widgets. With Content Linkage CG becomes a sphere that extends user experience beyond the single case of sharing - a network of sharing events. Sphere of predicted relations as well as unexpected semantic relations.

Views module 365 (Fig. 1 1 )

Views module provides the framework for creating and presenting

management views for CG client. For example, Social-Account view, Glass Sphere View, Peers Group Editor view and Preferences View are all created using the Views module.

Views module is implemented using rendering technology suitable to the specific CG library running on a client. Tools module 370

Tools module provides installable tools that can be used to integrate CG system into websites or applications. Tools are implemented in compliance with the underlying CG Client technology and related devices. The following is an example of potential tools. Various tools may be created not only for web environment but also for mobile and wearables.

CG Button

CG-Button is an example of CG tool. The button can be installed in a website by embedding a short portion of JavaScript. CG also provide CMS (Content Management System) plugins that let website owners install the button automatically on their website without dealing with script copy.

The button is a small widget that when clicked opens views for signing-in with social account, setting CG preferences and of course drawing widgets on a Website context. The tool installs in the background all that is necessary for loading CG client API and presenting shared widgets. CG Browser Extension

Any modern browser has its own framework for creating extensions. CG uses the various frameworks in order to inject the CG-Button tool into a website through the browser extension mechanism.

The major difference is that once CG extension is installed, CG can be applied to any website without the website needing to make its own installation. Moreover, Website generic code can interact with CG API as if it was installed.

CG browser extension requires the user to go into the browser's extensions directory and do the installation. The installation is usually a process that takes a few seconds. Anyway, it still requires the end user to take some action. That is why website owners that do not want to be dependent on their end-users actions, and wants that CG will be available immediately to any visitor, will prefer to do their own installation.

CG Collaboration Dashboard

The collaboration dashboard is usually presented as popup (in the case of website) or dedicated view (mobile) and it provides a simple toolbox for showing on-line collaboration widgets, for example Co-browsing, Chat, Co- Reading and others. The dashboard is usually an aid for another CG application. For example Experts-Glass framework uses the dashboard for managing sessions between "expert" and end user.

CG Sharing Board for Windows

This tool uses CG installed within Windows8 app. The tool provides a board on which users can share widgets with each other in a similar way as if handled by CG-Button installed on a website, but in the context of Desktop windows app. The only major difference (except for Ul styling) is the way of representing the sharing context state using the conventional Glass state parameters.

CG Tool for MS Office

This tool uses the feature provided by Microsoft for installing custom office app, in order to use CG as collaboration and sharing tools in the context of office documents. Other than using the conventional CG widgets in the sharing context of a given office document (Word doc, Excel spreadsheet, etc.) it is also possible to implement interactions between CG and user activities on a document. For example, selecting some title in a Word document will start a chat with the author of a document (if online). It is not only about collaboration features but also about turning office apps to social apps.

Language module 375

Language module is responsible for text translations for the purpose of supporting CG Ul on multiple language platforms.

Device adapters 380 (Fig. 12)

Some of the resources used by CG API are device dependent. It means the different devices may not provide the same resource in the same way. When using a CG client library, it is important to receive device dependent resources from the Device Adapter. The adapter provides different implementations for different devices and standard interface for accessing those resources.

Themes module 385 (Fig. 13)

Themes are a way of setting the Look & Feel mask of software without changing its logic. CG client contains a mechanism for defining and switching themes so that a Widget or the entire system will get different styles which can be selected by user. In addition, it is possible for developers to create new themes and integrate those themes for use on their Website or App

integration with CG.

Utilities module 390

Utilities module contains general purpose utilities used by the various modules.

GLASS MODULE DETAILED DESCRIPTION

The Glass is a software module that allows CG widgets to interrelate with some context based on identified states of the underlying context. In terms of programming one can think of Glass module as a container for running the other modules provided by CG client API. Therefore understanding Glass module life cycle is important for understanding the general workflow of Glass based applications. Glass Lifecvcle (Fig. 14)

Glass lifecycle has five major steps:

1 . Create: creating the Glass and the internal resources required for

sharing data, interacting with data storage and interacting with the device. At this phase, sharing activities such as loading shared widgets or creating new widgets does not yet occur.

2. Start: to start a Glass some "sharing content state" needs to be set. In practice, starting a Glass occurs when application sets one or more CG layers with appropriate state fields and sets the layers into the Glass mechanism. The Glass mechanism then uses layers information for loading shared data as well as managing new widgets created by user. After calling the start function of a Glass, sharing activities can start. New widgets can be created and associated with one of the loaded layers, and shared data from other users can be presented.

3. State update and restart: In some applications state does not change dynamically. For example, if CG is active on a webpage, the state layer for representing the current page URL is fixed (as long as user is in the same page). In other applications however, state values may change dynamically, possibly by some user interaction with the app, and the Glass needs to be restarted so that shared information will now be adjusted according to the new state. For example, it sharing content state is represented by a barcode, then when user scans another barcode the state is said to be changed and Glass is required to restart - the Glass will then load shared information related with the new scanned code.

4. Stop: stopping a Glass is a phase that allows glass to be restarted with an updated or similar state. Application may decide to stop the Glass and then start the glass again in order to stop sharing activity for a given period.

5. Destroy: this phase includes cleanups of Glass resources. After

destroy Glass can only be used if created again from the beginning. Manage Widgets

As a container and manager of other modules, the Glass provides the top level interface for managing Widgets, as depicted schematically in Fig. 15. This includes functions for creating 800, deleting 810, saving 820 and fetching 830 widgets.

Manage Views

The Glass provides the top level interface for starting and loading

management views. For example, the operation of loading the social accounts view for signing-in to various networks is initiated by Glass module, that in turn calls the Views module for implementing the actual request, as depicted schematically in Fig. 16. This includes functions for showing 900 and hiding 910 widgets, and getting a view 920 or a plurality (library) of views 930, for example in order to set some property for all views.

Render Widgets

Glass module 310 is responsible for drawing Widgets in the scope of sharing context. The Glass has access to storage where all the existing widgets are stored and access to the Widgets module 320, for creating new widgets, and these capabilities are combined for the purpose of rendering new and existing widgets on top of or in relation with the underlying Context for which the Glass is implemented.

As depicted schematically in Fig. 17, Glass mechanism includes a function for rendering a single widget 1010 and a function that iterates over widgets that need to be rendered and calls the single rendering function for each widget, thus rendering all widgets 1000. In addition widgets can be cleared 1020. Lifecvcle Events Binding

Glass module 310 provides an interface for registering Event Listeners that may get notifications of the various lifecycle 1 100 events of glass and/or widgets as depicted schematically in Fig. 18. This way both external software and internal modules may be notified regarding various events. For example, software may be interested to be notified when social account network has been connected 1 160 or disconnected 1 170, or when a new widget has been created 1 120, or when rendering of widgets has completed 1 130, etc. Creating Custom Implementations for Glass (Fig. 19)

Since Glasses may interrelate with different Contexts, Glasses may have different implementations. All implementations share the same concepts but may interrelate with different contexts, and may be implemented with different programming languages (PL). To support this requirement the API provides an Abstract Class/Prototype of Glass.

The Mechanism of relating content and Glass context

As depicted schematically in the flowchart of Fig. 20, the Glass concept always assumes that certain Context at a certain state is identifiable 1200. For example a URL (state) of Website (context) is given. Or a Condition (state) of Application (Context) is given.

For sharing to occur a Glass needs to be set with state. State is composed of the following fields 1210:

Glass Type: a parameter that represents the type of the Context. Glass Id: a parameter that represents the state of the Context.

Optional fields: zero or more fields representing multiple dimensions that refer to either state of underlying context, application state or user state.

The Glass provides a mechanism for loading, storing and rendering widgets related with currently set context state 1220. And since Glass was assigned with Glass Type, Glass Id and optional dimension fields, it is possible to relate any managed Widget with sharing context state represented by the Glass.

The relation between widget and sharing context state is handled by storing the widget in relation with state fields. When saving a Widget the records in database or storage node (depending on storage type) are set with Glass Type and Glass Id parameters and possibly with reference to optional dimensions data fields. Accordingly, when fetching a widget in order to be presented on some Glass, it is loaded from records or nodes marked with Glass Type and Glass Id 1230. This way Glass knows which widgets need to be fetched from storage for a given context state. A conceptual table in a relational database for storing widgets data is shown below (state fields are marked with ^*):

The next conceptual DB table holds reference to the table above for adding the Location dimension into state of context where a widget can be created. As can be seen, this table keeps reference to above table with the field item_id so both tables join in declaring a state that includes not only Glass Id and Glass Type but also Location details:

Elapsed real-time flag integer elapsed_realtime

Reference to item_id in the varchar ltem_id

widgets content table above

According to embodiments of the current invention the state fields do not have to be part of the widget content. This design consideration helps to simplify various management operations that may be performed on a Widget during its lifecycle; for example, migration of widgets across contexts or swapping widgets between two contexts (Content linkage operation).

The mechanism of fetching context related Widgets

Fig. 21 is a general flow for searching Widgets related with a given state 1300.

In a given Context state - Start Condition 1320, a Glass is created and started 1330 with the given Glass Type, Glass Id and possibly optional dimension fields and then the related Widgets are fetched from either local or remote storage.

For example, given CG application for sharing comments in relation with articles in a printed newspaper. We first create the Glass, then ask the user to enter the article title. Title text together with application type provide a sharing context state based on Glass-Id and Glass-Type respectively.

The Glass then calls the Storage module 1360 in order to fetch 1350 all Widgets related with the given Glass Id and Type.

Multidimensional Sharing Context

In CG, object State is defined by the combination of Glass Type, Glass Id and additional optional fields that represent various dimensions of either

underlying context, application state or user state. In CG terminology object state is also referred to as the "sharing context". Widgets are shared in relation with sharing context. When constructing a State Oriented Application, developer needs to decide how the state will be defined in the specific application. The decision determines the required logic for setting a Glass for representing the specific sharing context. For example, if a state is about to be represented by some Glass type and a code, it may be enough for the application to provide some code scanner. The scanned code will then be set into Glass ID field and the Glass Type will be set based on app category and this will construct the state for sharing new widgets or loading widgets shared for the state.

In another example, another application may decide that Location dimension needs to be included, so that it is not enough to get some scanned code but it is also required to define a state that involves some location of the user. In such applications a location data will be taken from GPS system or maybe by letting the user point on a map. The three fields: Glass Id, Glass Type and Location will then be used to construct the state of sharing context.

Fig. 22 describes schematically the idea of compound state as the Content Glass mechanism for setting the state by which shared content is related with, in order to be presented to peers. As can be seen, the state is composed of Glass Id and Glass Type plus additional dimensions.

Glass Id: General identifier of the context state. Some code, string, term or expression that defines a unique state of a context a sharing is related with.

Glass type: General identifier of the context type (category, topic, subject, glass pattern etc). Numerical representation of glass type.

Application Id: Unique Id assigned to application that can be used to separate content of different applications.

Other identifiers are optional and may be combined together with the mandatory fields in order to create the final representation of context state - State Id. Using multiple dimensions to represent the sharing context state constructs Content Glass as multidimensional contextual sharing

methodology.

The following is a list of factors used to construct state of sharing context. Glass Id

Glass Id is implemented as free text that represents a state of a context that is to be related with the shared content as a condition for exposing the content among sharing participants. The Glass Id is a required field. Examples: - Web URL, Domain name or TLD (Top Level Domain)

- Word, Sentence, Title of an article etc.

Codes: Bar-code, QR Code, Numerical codes etc.

- Visual representation: Indexed picture

- Physiological: blood pressure, heartbeat rate, eyes point of view

- Physical: noise, sound, temperature etc.

Glass type

Glass Type is implemented as a multilevel numerical representation of the glass type or glass pattern. The Glass Type is a required field. The basic list below allows fine tuning of types based on life events and categories. This multilevel system helps Content Linkage search in order to provide search results based on given categories.

Below there are examples of main glass type patterns:

1 . Website

2. Object

3. Place

4. ...

The next levels represent fine tuning types based on application's category and sub category. Each category and sub category may have a numerical representation and the glass type is a combination of general category and zero or more sub categories, such as:

[Main type: 2 digits], [category 3 digits - sub category 3 digits ],[ another category - another sub category, another subcategory]....

Example of categories and sub categories: 1 . Social

1 .1 . Networking

1 .2. community

2. Commercial

2.1 . Clothing

2.2. Software

3. Transportation

3.1 . Airport

3.2. Train

4. Website scope

4.1 . Page

4.2. Domain

4.3. Top level domain

Following are some examples of possible combined Glass Types: - [02] : using only the main type Object '

- [01][002] : 'Website' + 'commercial'

- [03][003-001] : 'Place' + 'transportation' + 'airport'

- [01][004-001][001-001][002-001,002] : Website' + scope=page +first category: 'social-networking ' + second category 'commercial-clothing, software' (in this example there are two categories and in the second category we apply for both sub categories)

Location

The location identifier is optional. The identifier holds location data so that a widget can be shared in relation with a specific location. When searching content by location it is possible to provide a "distance" factor that represents a possible distance from the actual sharing point, so that data can be shared also when not standing in the exact position as where it was originally shared or related with. For sharing a content in relation with location the user does not have to be present at the exact location. Content Glass provide a wizard that lets user determine a location on the map, and this location will become part of the context state related with shared widgets. The same concept can be applied to revealing a content that was shared in relation with location. User does not have to be located at the position. It is the application's choice to decide whether location based sharing requires the users to be in the related position or just point on the position using some map or other location aid. The two options and the combination of both options are possible.

Time

The time identifier is optional. Time identifier lets a content be shared in relation with context that involves some time of the day or some specific date or some specific timestamp. Content Glass provide a wizard by which a user who created the widget can set the sharing time event(s), or in other words, at which time or time period the widget will become available for sharing with participants. Sensor Based identifiers

These identifiers allow the representation of a context state as related to aspects that can be measured by various sensors. These sensors, all of them or part of them are supported by different devices, and content glass system provides wizards that let users relate a shared content to a state that may include one or some measured factors. For example, relating a widget to a specific ambient temperature.

The same as with location, it is up to the application developer to decide if a content is shared with a measured factor only when this factor is actually measured, or if the factor may be set manually by some aid that represents the measurable value, regardless of current measurement. The same is true for revealing shared content - it can be decided if the content will be revealed only when actual measured factor occurs, or also when a user performs some action that simulates the factor. For example, application may allow setting a shared widget in relation with air pressure suitable for the top of the Everest and set the widget to be revealed only when actual pressure matches this condition. Or an application can allow sharing a widget suitable for the pressure on the top of the Everest, and allow the widget to be revealed if a user moves some marker on a map and clicks on the Everest (or maybe when user watches a gallery of pictures and clicks on a picture of the Everest).

The list below refers to some of the possible sensors: 1 . Acceleration

2. Ambient temperature

3. Gravity

4. Gyroscopic position

5. Light

6. Magnetic fields

7. 3D orientation

8. Pressure

9. Proximity to other objects

10. Humidity

1 1 . Rotation vector

12. Device temperature

13. Other

User Gestures

Gesture identifiers are optional and refer to various gestures performed by a user that define a unique state of the context. For example, if we decide that a page in our mobile app is a context for which we want to associate a widget by content glass, we can determine that touching a specific location on the page is a gesture that defines a sharing 'dimension' which is part of the State Id to be related with shared widgets. Depending on the device any user input event that can be listened to can potentially be used to define a unique state of the context:

1 . Clicking

2. Long clicking

3. Dragging

4. Touching

5. Typing 6. Other Physical factors

These are optional identifiers that can be used when it is not practical to translate a physical condition into static code that can be set on Glass Id. Examples:

1 . Color

2. Sound spectrum Device Settings

These are optional identifiers that can be used to relate shared content with specific device settings that can be acquired from the API in use. For example, language settings can be used to limit shared widgets to appear only when the device is set to use a specific language.

User Properties

User properties dimension is a set of general parameters that can be collected relating to a current user. For example, when using a web browser it is possible to collect information about the referrer from where the user has arrived to a given website, information about the type of browser, the operating system, supported plug-ins and more. These properties can be combined in the state. For example, it is possible to set a widget to appear only when a user uses Chrome browser, or when a user has arrived from Google search engine (referrer) or when the operating system is Windows.

Reserved dimensions

Other than the defined dimensions set above, the system holds reserved fields for other undefined dimensions that can be used together with Glass Id to provide fine tuning in a multidimensional sharing environment. In certain cases application developers may find it more convenient to use separate dimensions than to compose a complex Glass Id expression. Functions that can be applied to dimensions

When sending the state identifiers to the server in order to fetch shared content, developers can pass not only the fields and value that construct the state Id but also a function to be applied to a given field.

One good example is sharing in relation with Location. In many cases it may not be practical to expect the other peers to be located at exactly the same coordinates in order to see the shared content. Instead, we may want to use some proximity factor that defines the distance from the original location where we can get a positive search result (get the shared content).

Therefore, when asking the server to load shared widgets in relation with some location we also need to ask the server to apply some function for calculating "distance from point".

The example of applying a function to a state identifier is quite clear for the location based sharing case. However, there are many other cases where applying functions to state identifier fields can be used in order to make our application more practical.

The next example of applying functions to state Id fields also clarifies the cases where it makes more sense to use multiple dimension fields rather than creating a complex Glass Id expression.

Let's assume a situation in which application state Id should be determined by three factors:

1 . The web page URL on which the user is located;

2. Some color picked by the user following an interaction with the web page;

3. A term/word related with the path of the referrer URL (the web page from which the user came into this page ), for example when the user is taken to a page from a search engine result page (SERP) the search term "q=???" can be used as a dimension of the combined state Id. If all that we need is a static combination of the three parameters then we can compose Glass Id as a single string of a given syntax: [URL]\\ [search term] \\[color RGB]

For example: Glass-Id =>

http://www.cor¾tentgiass.comj jsharirigj jRGBiO.1 12, 163]

However, what if we want some fine tuning related with the color parameter?

For example, we may want to load shared widgets not only when user selects the exact color as was originally selected by the widget owner but something close to that. For example, we may want that for the following RGB ranges [0][1 10- 1 14][160-165] will get positive match.

Here is an example of where a single Glass-Id expression becomes unpractical in terms of searching for widgets which match a given state. In this case and similar cases it becomes more practical to use four separate fields to represent the state Id:

1 . Glass-Id represents the static part [URL]||[search term]

2. Three fields of color dimensions that represent the color for R,G and B respectively.

In addition, when the client asks for shared data the request to the server will also include parameters that requires the server logic to apply a BETWEEN function on the data of color arguments. The internal search expression can therefore be (schematically):

Get content where

glass_id=http_n:_i mvw.cgnten

AND color_R = 0

AND color_G BETWEEN (1 10, 1 14)

AND color_B BETWEEN (160, 165) In this example we created a search expression by dividing the state Id representation from a single field (Glass Id) into four different fields (Glass Id, and three fields to represent color) and we used a conventional search function to achieve positive match for a given range of colors possibly selected by the user.

State identifiers VS widgets taxonomy

One should distinguish between state identifiers and the taxonomy system related with widgets. State identifiers are the dimensions by which a widget can be related with when shared. The sharing occurrence is related with a state of object that is defined by state identifiers. Therefore one may think of state identifiers as a coordinates system that defines the position of shared content in a multidimensional world.

Widgets taxonomy system on the other hand is part of the Content Linkage module of content glass that allows tags and terms to be related with widgets so that tags and terms can be used later for searching widgets by Content Linkage module. In short: state identifiers refer to state of sharing context. Widgets taxonomy is an extra information bound with widgets and it does not define the sharing state Id although it may refer to it by some means.

Glass State Layers (Figs. 23A, 23B)

In some cases we may want to present on the same context, shared information that is related with multiple states. For example, we may have a situation for webpage context on which Experts Glass is running. In this situation we may need to show shared content of ordinary widgets (not created by Expert Glass activity) and at the same time widgets which are directly related with Expert Glass activity. The two sets of widgets are related with different states of the context (different sets of visibility rules):

1 . On the one hand we have ordinary widgets which are usually shared in relation with the context state that is defined by page URL or domain (Example: Glass-ld=URL, Glass-Type=1 .1 ).

2. On the other hand we have The Expert-Widget which is part of the Experts glass mechanism that provides on-demand interaction with experts, which needs to be presented according to a different set of rules; for example, only if user has clicked a button to enter a session with the expert.

Here is another example: On websites, widgets can be shared in relation with

• Page URL

· Website domain e.g. www. contentglass. com

• Top level domain that includes all the websites of a given domain, for example www.contentgiass com and also ciev.contentqiass com.

These are actually different states of the same context (the website), which differ by glass Id. If for example a visitor is now in this page:

httgj//www,_^^ we need to present widgets that conform to three different glass Ids:

• www.contentglass.com/faq (Page)

• www.contentglass.com (Website domain)

· contentglass.com (top level domain)

The mechanism that allows multiple states to be managed separately on the one hand, and being presented together on the other hand is the CG Layers mechanism.

Defining State Layers

When a glass is created and before sharing activity can be started, it is required to set the layers that will be supported for the current context. For example, if the context is a website, it is possible to set that the following layers are supported: 'Web page', 'domain' and 'expert glass'. Or maybe only 'Webpage' and 'Domain' and 'Top level domain'. It is flexible and each app can set its own active layers.

Effect of layer when creating widget

When creating a widget and layers are set, the user gets the option to select the layer on which the widget is to be set. Accordingly, the widget will be related with fields that represent the state of the selected layer. User choice is restricted - for example, a common practice is not to allow users to relate widgets with public layers, still there are apps that do that.

Effect of layer when fetching shared widgets

The information that is sent to the server in order to search for widgets includes the set of state identifiers for each of layers. In practice, this is like searching data for a single default layer but performing the same multiple times with different state identifiers, and then aggregating the responses and returning to the client.

Fig. 23B show the process of loading shared content when layers are defined. The client sends to the service information about each of the requested layers. The server perform the same operation as for a single layer but multiple times. Each time the search uses different search settings based on the requested layers. Finally, the widgets found are sent to the client, in some cases individually and in other cases result sets are aggregated into a single list and returned to client.

User Defined Layers

User defined layers is an advanced feature. The feature enables the user to customize layers by selecting a set of state dimensions and grouping them together under a given layer name. The information is saved and

automatically applied to other peers with whom information is shared by the custom state layer. Content glass loads user's own layers upon initialization whenever user is detected.

GLASS PATTERNS DETAILED DESCRIPTION

Glass patterns is a general term we use to refer to various approaches for creating CG application in terms of app interaction with the context and in terms of user interaction with the context and in terms of settings the sharing scope and state. Glass pattern is therefore an "envelope" term to refer to type of CG app.

CG API allows the creation of custom Glass for some specific conditions. Accordingly, the following description and the schematic block diagram of Fig. 24 do not describe all Glass patterns but only some of the general patterns.

Website Glass 1400

In the case of Website Glass (1400) we set Glass Type field to numeric value that represents website scope (e.g. Page, Domain, TLD) and Glass Id is assigned with the actual unique identifier that represents page URL, domain name or top level domain name. The basic implementation of Website Glass, as depicted schematically in Figs. 25 through 27, is capable of relating widgets with three different Website identifiers that will be assigned to Glass Id property:

1 . Web page URL (Fig. 25)- e.g. http: //www.contentglass.com/support: Here the sharing context state is a single web page and the identifier used to represent the state is the URL of the page. Once a widget is created (by User-A) it is related with the specific URL of the underlying Web page; the user or other peers in the groups (User- B) can then watch the Widget by visiting the same page. Example of CG App that uses page URL as state:

Glass Type: Website page (1 .1 )

Glass ID: page URL (e.g. http://www.contentglass.com/suport)

Usage: Making a blog social by allowing users to share related notes and pictures. For example a car blog: Users use CG PictureBox Widget to share pictures of their cars and use TextBox or TextEditor widgets to share their impressions of reviews regarding some car presented on some page.

2. Website domain (Fig. 26) - e.g. http: //www.contentglass.com: Here the Context state is the domain name (and not just a single page). When a widget is created it is related with sharing context that uses the domain name of the underlying website for setting the Glass-Id state field. After setting the peers-group (by User-A) other peers (User-B) are able to see the Widget (after signing-in to one of the social accounts) when visiting the same website; each page of the website, not just a specific page.

Example of CG App that uses web Domain as state:

Glass Type: Website domain(1.2)

Glass ID: domain name (e.g. contentglass.com)

Usage: Virtual assistant service given on a Bank website. Sharing is enabled with a bank representative using custom implementation of Social Account. Users can ask questions in an offline mode by leaving a QuestionAnswer Widget on the site. Bank assistant will review the widgets and provide answers. User can go back and check for an answer, or be notified by a MonitoringWidget located elsewhere, on some other context. QuestionAnswer and MonitoringWidget use the Trigger/Action feature so that an answer provided in QuestionAnswer raises a notification on MonitoringWidget.

3. Top Level Domain (Fig. 27) -

For example contentglass.com: Here the context state refers to all the websites that use the same top level domain and the identifier is the Top Level Domain (TLD) itself. So a Widget shared on www.contentglass.com is also shared when visiting developer.contentglass.com or when visiting support.contentglass.com.

Example of CG App that uses Top Level Domain (TLD) as state:

Glass Type: Website TLD (1 .3) Glass ID: TLD name (e.g. ^*.contentglass.com))

Usage: TLD allows widgets to be shared across one or more websites having the same top level domain (TLD). For example, a company that wants to make a global announcement on all its websites to its registered users can use a custom implementation of social-account network connector for allowing registered users from all company websites to be included in a peer-group. This way system notification can be invoked by setting some Note Widget by admin, and relating it with "Any Registered User" meta group (instead of creating a group of all users). This way all users, when visiting one of the company's websites, see the widget and get notified with the announcement info.

Start Conditions of Website Glass

Glass start condition in the case of Website glass is usually page loading or refresh operations. Once an HTML page is loaded, the URL is set in the Browser DOM and this URL, either in full or in part, may be used to set the Glass Id and start the process of fetching related widgets.

Application glass 1410

Application Glass pattern (Fig. 28) refers to CG logic that is embedded within an existing Application. This can be a Web application, Desktop application, Mobile application, Vehicle infotainment application, an application running on a wearable device, or an application running on some other embedded system. The execution environment determines which CG client library is used. However, in all of these cases, the binding of application context and CG content (widgets) is handled by relating CG content with Glass Type derived from application name or type and Glass Id derived from certain application state, event, view or any other identified condition.

For a glass to be related with an application two properties need to be set:

Glass Type: will be related with Application type using a numerical index of applications. Glass Id: will be related with a well defined Application state.

Widget is interrelated with certain event, state, condition or view of an application.

Start Conditions of App Glass

In the case of Application Glass the start condition is some state of an application. For example: Event: some event was fired by an application and a listener of this event is used to set the Glass Id with identifier related with this event and start fetching related Widgets.

View: Some view was opened by the user. User action: User performed some action, for example clicked a button or link or selected some menu item.

Condition: application checks its condition and at some condition it is coded to start the process of loading shared Widget, or maybe create a new widget and let the user set some content. Examplel : Acrobat Together - Embedding CG into Acrobat reader:

This hypothetical application uses PDFConnector Widget for the purpose of P2P based shared reading that can be used as part of virtual-consulting service. This app assumes that CG API was embedded in the Acrobat reader software. CG functionality enables user to add PDFConnector widget to a given document. The widget provides the capability for two or more peers to browse the document together. The meta-data related with CG widgets set on a document is saved as part of the document data. Widget's peers-group is set with two or more peers. The user sends the document to another person who had been defined as a peer. When the document is opened by two persons the Glass is loaded and PDFConnector gets to action. The Widget acts to establish a stream of data for passing messages that carry information of document state, for example the current loaded page. When connection is established the two (or more) persons are able to read the document together (Co-Reading). CG API may be used for adding other types of widgets that bring collaboration to even higher levels. For example, it is possible to add ChatWidget that allows a chatting session between readers, or maybe a NoteWidget that allows leaving notes to one another.

Glass Type: Acrobat Reader (some numerical value)

Glass Id: unique ID of a given document Example2: Heart Beat Online - Embedding CG in healthcare SaaS:

This application uses ServiceProxy Widget to let user share his/her heartbeat data with a medical center service. Generally, SeviceProxy are types of widgets that intermediate between users and some service providers. In this case, the service provider is some medical center and its duty is to provide help to people who suffer heart illness by monitoring their heartbeat or other physical measurement. A peers group in this case defines two entities: the monitored user (the patient) and a non human peer that works automatically in the background, on some medical center server, whose purpose is real-time monitoring and logging physical measurements of the patient. If the

monitoring peer detects some dangerous situation it sends warning to the patient peer, that triggers some visible warning. At the same time it can generate alert to a medical team, so that some representative of the medical center will contact the person. The session of monitoring may not exist all the time, but when required, the patient can connect and start a session. For example, if this patient goes out for training and he wants to be monitored in order to be alarmed when the monitoring system detects a dangerous situation, the user can use a smart watch with heartbeat measurement. The smart watch will operate the Content Glass application (possibly in coordination with a smart phone), and using the ServiceProxy widget the heartbeat information from the smart watch will be transmitted in real-time to a non human listening peer. If the monitoring peer detects a situation that is defined as dangerous, it send back an Alert message, that triggers some indication of warning. Glass Type: Heart Beat Online (represented by some numerical value)

Glass Id: Patient Id

Location glass 1420

Location Glass (Fig. 29) is characterized by interrelating CG widgets with a location provided by some location technology. It means that when a widget is stored, it is related with Location properties taken from a location detection technology supported by the device on which Glass application is running. It is also possible to provide various values for the Glass-Id field in order to provide a sharing context that combines both: location and some code or value represented by Glass-Id.

Start Conditions of Location Glass

The start condition of Location Glass application is usually one of the following:

• User points to some location on a map or asks for current location info and the application uses the indicated position to set the Location properties used for sharing content.

• The application listens to location events generated by the location API of the underlying operating system and device API.

When location details were set they are used for constructing the final sharing context state that may also be compound with other dimensions or possibly with some Glass-Id code or value.

Fetching shared widgets by location

The mechanism for fetching shared widgets by location uses special database (DB) geometrical functions that provide the means for creating position based DB queries. A location is represented in the DB as a Point, and the query functions allow for performing searches based on point geometry. For example, if the user is at some distance from the original Location (where widget has been shared) he can define in the query functions to find points within a certain distance from current location point. The methodology for creating position based search either with distance factor from point or without is implemented internally by the server-side API, so all that is required from the application is to provide the location properties with optional "distance from point" value and the actual geometry will be handled.

Example1 Clue Following Game:

Location Glass is used for the purpose of "Clue Following" game together with GPS based mapping application. A peers group is separated into two logical groups. One group sets the "clues" using Note Widget attached with location, and the other group follows the clues. The clues (widgets) are invoked whenever the "searching" group is in the location (+- 100m) where a clue widget has been left.

Glass Type: location(represented by numerical value) Glass Id: Expression made by location properties and proximity factor

Example2: Parking place reminder

The parking place reminder is intends for those who tend to forget where in the city they left their car. The idea is very simple: when parking the car user creates a Note widget that is set in a sharing context with location properties. The note may include free text or voice so user can add for example the street address where the car was parked. The proximity factor (area radius) can be tuned based on need. When the person needs to return to the car he starts the application. The application listens to location events that notify current location on the move and sends requests to the server with a rate based on the proximity factor. When the person gets to the area where the car was left the note is presented with the accurate street address where the car was left.

Glass Type: location

Glass Id: Expression made by location properties and proximity factor

Objects glass 1430

Object Glass (Fig. 30) interrelates between objects in the world and CG widgets. State Identifiers can be separated into these major types:

Visual identifiers: We use an image of the object to identify the object. This may involve 3^rd party API for image indexing service (for example Moodstock: https://moodstocks.c om/how-it-works/) that assign Ids to images and provide search API where image data can be sent and an identification of the image is returned if the image was identified to match a pre indexed image. The identifier assigned to an Image is used as Glass Id. Figs.31 A and 31 B demonstrate this idea.

Scanning code: A code that can be scanned such as QR Code is used to identify an object. The code is assigned into Glass Id field. For fetching shared widgets the user, or other peer scans the code in order to put the Glass in a state suitable for loading shared widgets related with an object pointed by the code.

Numeric or textual code: A numeric code is entered by the user for setting the sharing context. Then, for searching a widget, the user enters the code and a related widget is fetched. The idea is the same as with scanned code, however the code is entered manually as a combination of digits and/or letters.

Figs. 31 C and 31 D demonstrate the idea of using a code to store and fetch widgets. Lingual: Object is identified by Term, word or phrase. The text used to identify the object may be written, or may be verbally translated to written format and then used as the code. Figs. 31 E and 31 F clarify this idea.

Physical measurement: Any physical or physiological measurement that can be formulated as and identifier of some object and can be digitized, can also be used as the Glass Id assigned to stored Widgets. When the same physical condition is detected it can be used to fetch related widgets. Figs. 31 G and 31 H clarify this idea.

General text, interpreted code or function: A state of an object can be represented by any general text or value (for example: ABC123). A state can also be represented by a function (for example: given 'x' and y refer to all records that conform to the formula: 2x=y). And finally a state can also be represented by interpreted software code that is executed by the server API in order to produce a list of records to fetch when loading shared widgets. Object Glass Start Conditions

Generally the start condition in the case of Object Glass is some event or user behavior that triggers the identification process. The result of this identification process is then used to set the Glass-Id (or possibly other field) of sharing context state. The sharing context with the set identifier can then be used to fetch related widgets from storage or create new widgets that can later be shared for the currently set sharing context. Following are a few examples of identification process by which object state is represented by some value:

Taking a picture of some object: In this case the application perceives the event of capturing an object as a trigger for finding matched Id by searching in a database of pre-indexed images. This can be handled with various 3^rd party APIs that specialize in this task. If an Id is retrieved it is set into Glass Id and fetching interrelated widgets can start.

Scanning a code: User scans some code attached with an object and this action starts the fetching process.

Verbal user input: User speak either in response to program request or spontaneously. The verbal input is translated to textual input. Then words or phrases are checked against an index of words or phrases and once match is found an Id is returned that is set in Glass Id so that searching for interrelated widgets can start. This approach may be very useful both for people with disabilities such as blind people, or when user attention should not be distracted from the visual field, such as when driving.

Textual user input: is checked against an index of words or phrases and once match is found an Id is return that is set in Glass Id. Sound sample: In this case the sound is not translated to human language but is sampled and processed with Fourier transform in order to generate profile of harmonies - sound spectrum. The spectrum is like a signature of sound and it can be used as the code. For example, a sound of a bus can be used to share information about busses. A user samples the sound of a bus with a recording device, and sends the sample to a sound processing API. The sound processing API performs sound analysis and generates a spectrum. The spectrum is formulated into textual string so it can now be used as a code. The code is attached with a Glass Id. In the detection scenario a sound of a bus is sampled, it is processed, a code is generated and this code is then used to search for Widgets that were shared in relation with a bus sound. Physical measurement event: this is more general than the example of sound sample (which is actually a type of physical measurement). Generally speaking, an event of some physical measurement can be used as the trigger for fetching related Widgets. For example, heartbeat at a given rate can be used as identifier of a state by which some shared information will be loaded. Refer to the surgery critical events sharing system described in the examples below.

Examplel - Touring places CG Sharing

This hypothetical application is for tourists either in tourism sites or museums. The tourist takes a picture of the object, e.g. Eifel tower, picture in museum etc. or says its name to the software. The software checks for recognition based on user input and send in response widgets shared by friends who visited the same site. To save a review user first performs some action that sets the sharing context - for example takes a picture or sets the object name (depending on app logic). In the case of picture, the image is sent to the indexing service that returns an ID representing the image. In the case of setting a text, either the text is used as-is as the identifier of an object or we use a service that parses the text and produces the "key term" that is then used as object identifier. Once object identifier is obtained and set into Glass- Id, sharing context is considered to be set and user can then create a widget such as TextBox, Note or any other widget, add his/her friends to peers-group and save the widget. The new widget is then related with the current sharing context.

Example2 - Barcode CG Sharing

This hypothetical application is for sharing reviews of friends on products in the supermarket. Object recognition is handled by scanning the barcode of the product. The scan generates an Id that is then used to fetch widgets with friends' reviews about the product. To save a review user scans the barcode that produces the identifier that is set into Glass-Id. User can then create a new widget (e.g. TextBox widget ) and save. The widgets is then attached with sharing context state identified by the product barcode.

Example3 - Sharing for blind people

This hypothetical application uses Braille code as the input for creating Glass Id. Braille code is used as the key for a sharing system that is accessible to blind people. The application may be implemented in several ways. Here is one example:

In the first step we need to process a portion of the Braille code - for example book title, into digital code. If we have a special tool that can translate the Braille code to text then we can use it, and the text will be our digital code. If not, we can scan the Braille code and create an image of it, then send the image to an image recognition service and get a related code in response. Once we have a digital code that represents part of the Braille code, we can create a Widget and mark the widget as related with the code. The user can create for example RecordableNote widget, record some message and then attach this widget with the code. The Widget can now be shared in response to the same code. A second user, friend of the first one that reads the same book can do the same operation of scanning book title written in Braille and the recorded note widget will be played.

Now let's assume that we use a tool that knows how to translate the Braille into text, the text is then our code - the title of the book. This allows a third user to scan the title of an ordinary text book and get the same RecordedNote Widget left by the first (blind) user. Of course, a regular smart phone may not be a device which a blind person can use to share widgets, and there is a need for a special device where user can operate CG, for example click a button and record message, and then click another button and scan some Braille code, and use voice recognition to manage peers groups etc. Yet, this example demonstrates nicely the idea of sharing in relation with objects, assuming a way does exist to represent the object with a code. In this example the Book is the object, the title of the book is used to generate the identifier of the book (the code) and if we are able to translate Braille to text, or vice versa, and if we provide the special device adapted for blinds, then we are capable of using CG to allow blinds to share with friends in relation with objects.

Example4 - Sound based sharing

In this application widgets are shared in relation with sounds. Imagine an app that gets environmental sound as its input and shows widgets related with this sound. For example, a sound of a bus or train or even the vocal signature of our friends and family members. This application processes audio sampling for generating a code based on the spectrum of the sound. The spectrum is formulated into a code and this code is then used as the Glass Id by which widgets are shared. Another example is when using sound samples spectrum analysis to calculate the noise level. In this case widgets can be shared in relation with environmental noise.

Examples - Surgery room

This example shows that CG is more than just entertainment technology. The application is for sharing useful information during surgery. The information is shared between teams of doctors that perform similar surgery and more specifically it is intend to provide professional ideas and guidelines during critical situations. The surgery type is used to set the Glass Type of sharing context. We are using multiple layers to refer to different states of bodily measurements. Each layer can present information related with a different bodily condition. The shared information (Widgets) contains vocal notes and/or textual notes of guidelines for handling specific situations (represented by state layers) or critical conditions of the patient. For example, in the case of drop in blood pressure the layer responsible for blood-pressure related information fetches some advisory guidelines for treatment. The guidelines widgets are presented to the team - for example using Smart Glasses. Due to the ability to combine multiple layers related with various conditions or various bodily measurements, it is possible for application to provide guidelines not only based on a single measurement but also based on combined

measurements or complex conditions. This application is made of two sub applications - the real-time app that is responsible for collecting measurements and loading the shared info during surgery and the recording app in which various states can be simulated and widgets are created as related with those states.

Place glass 1440

Place Glass (Fig. 32) interrelates between a place and CG content. A place can be a building, airport, train, hotel, person's home, medical center, working environment etc. Entering into a place may be identified by scanning a code (for example a code present on a train ticket), but this is not always

necessary. There are cases in which a specific application is created as related to a specific place, so that starting the app is considered as being in the "place". For convenience CG may be provided with a numeric index of places so that this index can also be used when code scanning is not available.

The most distinguishing aspect of Place Glass pattern application is the programmatic manipulation of peers-group intended to set the scope of sharing with users who are "in the place". For example, if we take the

Supermarket application that was described in conjunction with the "Object Glass" pattern, a similar application built using the Place Glass pattern, will manipulate the peers-group so that sharing can happen among different users currently visiting a specific supermarket. The indication of entering into the supermarket can be, for example, an action of scanning some code. In other words, place glass applications extends object-glass (or other glass) apps by managing a scope for sharing activity - usually by creating ad hoc peers- group of users in the place.

Start condition

In the case of Place Glass user first performs some action that signals to the application that the user is in the place. The most obvious is of course starting an app that uses that place glass pattern and refers to one place only. But, there can be some cases where the same app may define multiple places. The action for signaling the entry into place can therefore vary. Here are some examples: Starting an app, scanning some code presented in the place, entering some place identifier (a value from pre-defined index of places), scanning some ticket (e.g. train ticket, flight ticket), being identified in a given location (for example having the GPS coordinates of a mall) and more. Once place was defined by app, it is up to the application to decide if either user can start being exposed to place related shared content or user needs to perform some action first that will set an object related sharing context. For example, in the case of the supermarket app mentioned above, user is required to scan some product first in order for sharing content to set. On the other hand, in the case of translation system in a train, as will be shown by the following example, it is enough that user scans the ticket or a QR-Code at the train car in order for the application to start and share translated notifications with the user.

To summarize: there are cases for place glass pattern apps in which the code of the place can be used also as Glass-Id. In these cases after 'entering into place' sharing context is set. There are other cases however in which entering into place is only the first step for setting the sharing context and user is required to perform some additional action to refer to specific object in the place for which shared data is about to be loaded or created. The bottom line is that place glass is about sharing content with users "in place" that may or may not "refer to some additional object" and not just sharing content in relation with "object".

Index of Places

CG system may provide a complementary places index service. This service can be used by applications where user is required to enter a few characters (e.g. 5 digits) to designate place code. The service can be used as the data source for a Ul that lets user select a place. Selecting a place is equivalent to scanning some code that designates a place.

Example1 - Find me in the building

This hypothetical application solves a known problem: finding one another in a large building. For this example we will assume that some person is hospitalized and his relatives are coming to visit him in a large hospital and find it difficult to locate the hospitalized person. The application is very simple - the hospitalized person creates a simple note widget with the details of the section in the building and room number where he is staying. The note is shared with peers of the hospitalized person. When relatives come to visit, they scan (or enter manually) the hospital code. The note with the details on their hospitalized relative is invoked and they can find him easily.

Glass Type: place (numerical value)

Glass Id: QR or numeric code of hospital building Example2 - Multilingual information/translation for train or airports

This hypothetical application solve a simple need - usually the information in a train is given in a specific language which may not be understood by all passengers. This application solves this by defining a train as a Place and dynamically adding passengers into a peers-group that lets them watch translated messages generated by a robotic peer, related with the current train line. The same application can be implemented in airports as well.

To start the app user scans a ticket, for example train or flying ticket.

Scanning the ticket provides an Id with higher resolution than just general code of a place, and accordingly widgets (the shared information) can be filtered for specific persons by their specific destination. This achieves higher relevancy of the presented information. For example, if someone is flying to New York, he may not be interested in messages referring to others who fly to Sydney

Upon scanning the train/flying ticket, a user is dynamically added into place's group. In this simple case this group is intended only for the purpose of receiving translated messages of official announcements.

The application is provided with some user interface where the user can select a language. The passengers see only the messages in the selected language. In the case of automatic announcements a non human, robotic peer may be used to dispatch the announcements when required. The announcements are pre-translated into some languages, and each passenger peer sees only the announcements of a selected language and only when an announcement is relevant to the information gathered from the ticket.

In the case of human announcements, a human peer writes the

announcement, it is then translated and relevant widgets are created for a few languages. The announcement is then distributed to peers as with automatic announcements. When a user passes the exit gate the ticket is scanned and this is reported to the application that may remove the user from the peers group.

Glass Type: place (numeric value)

Glass Id: An ID Generated by scanning the ticket

Example3 - Package Location Tracking for post office service

This application has emerged from watching post office clerks. Since a neighborhood post office branch does not work as an automatic warehouse, a common problem of the clerk is to find a package requested by a customer. The problem is rooted in the fact that customers get a notice from the main post-office branch and then go to collect the package in the neighborhood PO branch. Therefore, the notice includes the package code but does not include a record of the exact shelf where the package is located. The result is that it often takes few minutes to locate one single package. In this Place Glass application we refer to the post-office workplace as the context place and we provide a solution for the problem in the following way: when the clerk puts a package on some shelf he scans the package code and the app opens a keyboard by which the clerk types the shelf number. When clicking "submit" a widget is automatically created that says something like: "package with code XYZ is located on shelf number ##". Now, the customer can open the tracking app and scan the code on the notice received. The widget with the location of the package will be presented. Accordingly, when coming to collect the package the customer can tell the clerk where the package is located - or the clerk can scan the notice paper brought by the customer and get the location. And of course we can leverage on the fact that a widget is created for tracking a package, and add more functionality- for example, if some payment is required for collecting the package, the widget may include a "pay" button. Or, if for some reason the customer is unable to collect the package in the given time, there is no need to send a second notice, or return the package since customer is able to communicate directly with the PO regarding this package.

Device glass 1450

Device glass (Fig. 33) interrelates between resources on a user's own device (PC, tablet, Smartphone, other) and CG Widgets that allow sharing the resources content. This allows a single person to share resources across devices for the purpose of viewing and sometimes managing or editing.

Device Glass uses special widgets that know how to proxy with resources, for example files or printer, so it is possible, for example, to send a document to print on my home printer even without being connected on the same network (as in the case of printer sharing). See example below.

Resources Identities can be formed as URL in the following manner: cg://[device name]/[type: file| printer |cam |..]/[resource-ld: path|printer-name | etc.] .

For example the URL: cg://user-81 d12cbcab/file/d:/temp/test.txt refers to file d:/temp/test.txt on computer name user-81 d12cbcab'

Resource Proxy Widgets

Device Glass uses special widgets that can proxy with resources set on devices. The most common resource of course is 'file' but it is not limited to that. Printer, camera, sound system, data-stream are also resources that can be proxy by device glass widgets. Proxy with resource means that a widget provides a way to read or watch resource's state and content, and possibly in some cases, also write, or change resource's state and content. Example1 - Viewing and editing remote files

In this example we use FileProxy Widget attached with a specific file on a PC to view and update the file from a tablet. The PC and the CG app that contains the FileProxy Widget should be active for the purpose of servicing the file and applying modifications. A person uses the tablet with Device glass application turned on. This allows fetching widgets defined on other devices of the same person (or other peers in group). Searching for files reveals the FileProxy widget created and acting on the PC. The widget serves the resources to the tablet via P2P connection, and assuming the tablet knows how to edit or view files of the requested type, the file is presented and can possibly be edited. Editing is performed on a mirror file set on the local device. The mirror file lives in a kind of sandbox (some temporary cache) that lets files be viewed and edited and later erased when closed. After file is updated the widget allows "Remote Update" option that when selected, the updated data is delivered back to the PC, and the active widget on the PC uses file resources to create a similar file with an updated data.

Example2 - Remote printing

Remote printing uses PrinterProxy widget to allow printing from one device, using a printer connected with another device. For example, printing from tablet using a printer connected with PC. PrinterProxy widget on the PC is attached with a printer and waits for print jobs sent over P2P. On the sending side PrintingProxy is attached with a file and when wishing to print the file data is translated into a print job that is sent to PrinterProxy on the PC.

WIDGETS MODULE 320 DETAILED DESCRIPTION

The Widgets module 320 is responsible for drawing Widgets of various types and handling the various operations available for widgets. The rendering and widget construction technology may vary from platform to platform. Core Widget Operations (Fig. 34)

Initialization

The initialization process is responsible for initiating widget resources and preparing widget view on a drawing container provided by Glass. Generally speaking, in terms of object-oriented programming, a widget is an object in application memory. Widget is created and saved in memory, or its data is loaded from memory and it is then constructed according to the loaded data. Once a widget is loaded it is usually rendered (there are also hidden widgets but we will refer to the more general case). For example, Website Glass renders widgets by constructing widget objects into the Browser's DOM and then constructing the HTML script that provides the Ul of the widget. Each widget type has its own renderWidgetContent() function so that each widget type can create its own unique Ul. In the case of Android API for example, a widget object named CGWidget is loaded into memory and each widget has an implementation for a function named getView(). The Content Glass module that functions as major controller for CG app, iterates widgets one after another and calls this function. The function returns an object of type View. The view object is then added to either Activity or Fragment objects that represent the main container for drawing Ul by Android OS. Toolbar

A widget may or may not include a toolbar. The purpose of a toolbar is to provide easy tool buttons or menu or links for the user to perform core operations such as opening the Peers Group interface and more.

Rendering

A widget includes its own rendering routine. Rendering routine is responsible for rendering the internal structure and any required graphics of a widget. Rendering routine is usually called after initialization but may also be invoked for the purpose of refreshing widget view after some change, so that new resources state will be reflected in the view. Persist state

A widget usually has a persist state that holds both state of presentation and content. By state of presentation we mean for example the state of size, position, open/minimized and possibly other settings. By state of content we mean the actual content carried by the widget, for example some text, some picture, some video, some application resources state etc.

When a widget is loaded the content is combined with the widget view and the user sees the final result - for example textbox, profile capsule, html layout etc.

Widget persistence is composed of local and remote representation of the data. The local data is the part that is stored on the local device, and the remote data is stored on a shared DB . Widget content

A widget is created for the purpose of presenting and/or sharing some content. The content may be textual or visual or any other type that can be digitized and stored in the form of binary or textual data. Widget's content is editable by nature so that User or underlying application can create or edit the initial content and then edit again if required. In some cases widgets may restrict future editing operations. The content is stored as part of the widget data sent to the storage mechanism, and is retrieved when the widget is rendered.

Open and Minimize

In the open mode widget is shown in full size. In a minimized mode widget is shown as a small icon. The location of presenting the minimized icon is determined by user preferences. As with other operations, minimized may not be supported for all contexts and/or environments.

Resize

Widgets may be resized. Having the resize trait is optional, so it may be restricted by some widgets, and allowed by others. Resizing is very practical when the resources and content presented by widgets require more space to render nicely than available by the default size set to the widgets. The new size is stored as part of the widget state and will be used next time the user loads the widget. The size state is determined by personal preference so that different peers may watch different size states based on preferences. Drag

Widget may be dragged on the screen, within the boundaries of the underlying context. For example, a widget that was assigned in relation with a Web page can be dragged to different positions on the browser window. Dragging should be optional and some widgets may choose to restrict dragging. Dragging is provided for the purpose of convenience of presentation so that a widget view can be arranged nicely when presented on top of external context view.

Define peers group:

A Widget can be shared by relating it with a peers group. A peers group is a group of friends or contacts account identifiers, such as Email addresses, unique Ids etc. that is set in relation with a widget. Defining a peers group is essential for sharing a Widget and is handled using special peers-group management View.

Sharing scenario given Widget-W1 on Glass-G1 : 1 . Peer-A open peers-group management.

2. Peer-A adds contact of Peer-B to the group and closes. Data is saved.

3. Peer-B signs-in with his/her account.

4. Peer-B is in the same sharing context referred by Glass-G1. For example, if Glass-G1 context is a web page then Peer-B is now watching the same web page where Widget-W1 was originally created.

5. System checks for Widgets shared with Peer-B and loads Widget-W1 .

6. Widget-W1 is now presented to Peer-B. P2P Channel

A widget may use a peer to peer channel in order to communicate with the parallel instance of the same widget, as inspected by peers in the peers-group assigned to the widget. Using P2P allows real-time collaboration with regards to widgets. P2P allows online streaming of data and events generated by Widgetl used by Peer-A "W1 (p-a)" to be perceived by the parallel instance of the widget as used by Peer-B "W1 (p-b)" given that Peer-A and Peer-B are both members in the peers group assigned to the widget. The stream is not limited to two peers only, but can be shared between multiple peers currently online.

This way we have two or more instances of the same widget: "W1 (p-a)" and "W1 (p-b)" communicate with each other. The communication may include exchange of data, exchange of events, and generally exchange of messages.

For example: FormConnector Widget is a widget that knows how to bind with Web page forms, and once the binding with the form attachment is made on both sides, by two (or more) peers, then one peer can fill the form fields for other peers.

Lifecvcle events

A widget may have many events during its lifecycle. For example, when a peer is added, content changes, position is set, minimizing, maximizing etc. An external program may be interested in those events for the purpose of applying some level of control. Accordingly, a mechanism is required to register listeners and report events to listeners.

Executing application logic

A widget is a software component. It includes settings, content, presentation view and can also include some logic. Hence any widget resembles a small application. Basic widgets serve mainly for presenting specific type of content so their logic is basic and limited to content view. Application widgets are widgets with logic that serves some flow of usage across time. Yet both cases may be considered as mini applications.

Embedding / Floating modes

Depending on background view provided by underlying context a widget may be embedded into context view or float on top of it. These are two modes of presentation that provide high flexibility and richer user experience.

Website context is an example where the two modes are possible. In the embedded mode a widget, say video viewer, can be located so it looks like embedded within website page. This is possible due to the nature of Web page DOM (data object model). In the floating view mode the same widget is located on top of the web page content, as if there was a transparent layer on top of the page and the widget can be positioned on top of it.

Binding with underlying context:

Some widgets are designed to bind with underlying context so they can get events and context from context components and use these events for the purpose of application logic, view control or real time collaboration. For example, InputConnector Widget is a widget that is capable of binding with HTML input elements of the underlying context (HTML web page) and transfer input element events and element value to other peers in order to create the effect of the two or more peers filling the input field together.

Linkage:

Linkage operation involves searching for related widgets by one or more semantic rules. The properties of the base widget are used as reference for searching other widgets with related properties. The relation is determined by applying some semantic rule such as: similar app properties, having the same Glass Type, semantic relations applied on glass's identifier (Glass Id), relation found in content such as using similar key terms and more. Linkage result is presented as a list of related widgets named: Linkage graph. Creating Custom Widgets Implementations (Fig. 35)

CG API provides developers with methodology to implement their own widgets and prepare a collections of their own custom widgets in the form of custom widgets libraries. Custom libraries of widgets are defined within a special manifest file. The file is added to the application or in other cases declared by meta-data. For example in the case of website, each website can add meta-data tag in the HTML script that defines custom libraries. When an external manifest file is detected it is loaded (after verification of developer details) and widgets referred by custom libraries become available for users.

STORAGE MODULE 330 DETAILED DESCRIPTION (Fig. 36) The storage module is responsible for storing widget data and plays a major role in the sharing mechanism. CG API uses a combination of local storage and remote storage. Local storage is a storage that exists on a device where the client is running. Remote storage is a central database or in some cases a storage service available on the Internet cloud, that can be accessed with API. For example, Amazon storage web-service, Rackspace cloud storage and others. Generally, any storage service that provides a sufficient search and storing API can be used for the purpose CG remote-storage. One of the applications of using storage services for holding the shared content is in the case of the personal-remote-storage features, as explained below.

Storage registers During the lifecycle of a widget, the information is kept on various registers as explained below and as depicted schematically in Figs. 36 through 38:

DOM memory

This is a register that stores data for immediate use in the browser or application DOM. The DOM memory is volatile and is not kept when

application is turned off. To hold persisting copy of the data we use a few other local storages.

'Pending' local store

This memory region holds completely new widget data that was not yet saved remotely. It means that this data has not yet been shared in any way. Pending data is data that is waiting to be stored remotely. During this period it serves for local persistence storage. When data on the pending memory is deleted it is simply removed and it is not required to sync the deletion with the server since this data was never stored remotely.

'Context' local store The Context store contains copy of what was previously loaded from the long- term remote store as-is. Its sole purpose is to provide fast initialization when reloading the same sharing context (for example upon refresh of the web page). When Glass is started and is set for a given sharing context state, the local context-storage related with the current state is fetched and widgets data stored on this register is loaded. Widgets are then constructed and rendered. This operation of loading widgets from the local storage occurs fast so widgets can be presented fast with no delay. At the same time the sync operation and after that the operation of loading shared widgets from remote-storage

(explained below) are running in the background. When sync, and load of shared widgets are done the context storage is set with updated remote data, and related widgets that were previously rendered are updated or possibly removed (if a widget has been deleted from remote storage). As a result of this logic we can render remote widgets with no delay while making the sync and load operations, which are relatively slow, in the background. 'Modified' local store

This storage holds data of widgets that was stored by context-storage after widget has been changed. In other words, a widget that was rendered from context storage and its content has been changed, will be moved from context-storage into modify-storage. 'Deleted' local store

This storage holds data of widgets that has been loaded from context-storage and has been deleted by the user. In other words, when widget that was loaded from context-storage is deleted, it is moved from context-storage into deleted-storage. 'Personal' local store

This register is responsible for storing personalized changes to widget. These are changes that we don't want to share. For example the position of a widget. The personal settings are stored locally and override the default settings when widget is rendered. 'Utility' local store

This register is used locally for storing meta-data and settings that can serve for the purpose of glass loading. For example, after user login to social- account we store user account and contact details in the utility store. This way user will not have to sign-in each time to this social-account and instead we will social-account details and contacts from the utility store. Long term remote store

The long term storage is hosted on a remote server, unlike other storage registers which are stored locally. The remote storage holds data for the long term and this is what allows sharing of data between different peers and different devices. Widget data is stored remotely as related with sharing context fields: Glass Type, Glass Id and other dimensions fields.

Sync Operation (Fig. 39)

The sync operation is responsible for synchronizing between locally stored data and remote data. This includes three steps:

• Take widgets stored on pending-storage and store them on the

remote-storage.

• Take widgets-stored on modified-storage and update the

corresponding widget records on the remote storage.

· Take Id of widgets stored in the deleted-storage and remove

corresponding records from remote-storage.

Load Shared Widget Operation (Fig. 39)

The Load operation uses the details of sharing context and creates a query to the server in order to load shared widgets related with current sharing context. Details of sharing context include specific values to search for Glass-Id, Glass-Type, Application-Id as well as optional values to search for widgets related with fields of the multiple dimensions that may be used to compose the sharing context state. The server-side API uses all these parameters to compose a query that is then used to find related widget records. The records are collected and sent to client. The client receives widget records and initializes the corresponding widgets on the DOM memory from the data returned from the server. Copy of the widgets created from server response is then stored in the context-store register. The content of context-store is used for fast loading of widgets upon refresh of CG loading, as explained above. Personal long-term storage

The Storage module that was described above uses a Remote storage for storing data that can be shared. This means that part of the data is assumed to be stored at a central storage that may be accessible for the purpose of sharing data among multiple users. Using central storage is a conventional model in any normal SaaS (Software as a Service) and it is the most convenient model for sharing data asynchronously (meaning that users may see the data in different times and with no direct connection between them).

Content Glass system provides a central storage for the purpose of data sharing. However, it also provides an advanced setting that allows data to be kept personally for either an individual peer or a group of peers that will be invited and authorized by the storage owner.

Personal remote storage (Fig. 38) means that the sole owner of the storage and the data is the user. The user either owns the storage facility or leases a storage using some storage provider and neither Content Glass system nor any other governmental authority may monitor the stored data unless storage owner or account owner is forced to do so by some authority.

In other words: the central storage for servicing data is in the ownership of the data owner and not the SaaS provider or any other Service Provider with all the implications.

Using personal storage is an advanced functionality of CG that requires users to set their own personal storage. User is required to make those settings only if choosing to work with personal storage. If not, the system uses the remote storage facilities provided by Content Glass System. In addition, for other peers to be able to receive information from the personal storage, a special invitation link needs to be used. The invitation link refers to information managed by CG that is used to make the appropriate settings in order to allow other peers to receive data from a personal storage on the sharing user. Advantages of using personal storage:

1 . Intranet use: Companies can use the Content Glass network for

internal uses by letting company workers share data that is stored on company facilities.

2. Computational SaaS (Fig. 40): Service providers can use ServicePort type of widgets to proxy personal service to users and provide users with full responsibility over their own data. This means that the service provider provides only the computational and data processing units and the actual personal data is stored in a facility provided or managed by the user.

3. Sharing personal information (Fig. 41 ): CG Widgets can be used as safe mechanism for sharing personal information when working as Computational SaaS. This means that the widget is a computational unit and the personal data is stored in a facility that is owned by user instead of by a service provider.

4. Authorities: Content Glass provides the option to protect against

surveillance by authorities.

Disadvantages of using personal storage:

1 . More settings are required. Understanding the concept of using

personal storage may not be easy for many common users. That is why this option is considered to be for advanced users.

2. User may be required to define an account on some cloud storage

service.

3. When sharing with group of peers, the credentials for accessing the long term storage need to be shared with other users via special invitation. It means that user must trust the people with whom he/she shares data access credentials.

Personal Storage Devices and Services

There are a few options for setting up a personal storage and CG as

Computational SaaS. CG system provides the appropriate Storage Adapter for any supported facility. Personal Computer Storage: the hard disk memory of personal computers can be used for storing personal data for the purpose of CG long term store. Information stored on local computer may be kept personally.

Cloud Storage APIs: private remote storage can also be

accomplished using various cloud based storage APIs. For example Amazon S3, Google Cloud Storage, Dropbox Datasore API and any other storage service's API that allows personal data to be kept on the cloud. The idea is that user, when choosing to set private storage, selects the storage service, enters credentials of private account and as a result the selected storage service starts to function as the remote storage for storing user's own widgets.

Self-managed DB: The same way CG uses a central DB facility for storing the shared data, a DB facility can be managed by another entity (user or company) and be used for storing the shared data. In this case storage settings include the host and DB credentials for accessing the managed DB owned by user or company.

WIDGETS IMPLEMENTATIONS

This chapter provides a short description of various CG widgets intended to be provided with a basic client API. These widgets can directly be used by end users and Glass applications but they are also used as reference implementation and code example for developing custom widgets. As a General guideline Content Glass is a platform or a framework for creating state oriented sharing apps and not an out of the box service. It means that CG encourages developers to develop their own custom widgets and specify their own custom widget libraries to be used with their own solutions.

Basic Widgets

Basic widgets are usually widgets with basic functionality that is mainly involved with presentation of data and does not involve much (or any) application logic. HTMLWidqet

A widget that lets the user enter html script for rendering some view. The HTML is filtered to prevent active content from running. This widget is a reference implementation for other script based widgets that may be implemented in the future. For example: SVGWidget for presenting SVG (Scalable Vector Graphics) script.

IFrameBox

This widget draws an IFrame (which allows a visual HTML Browser window to be split into segments) linked to a URL provided by the user. The widget is suitable for Web browser environment as well as other environments where Web browser can be embedded in an app.

LayoutWidget

Layout widget actually composes features from other basic widgets and lets the user select a layout and then for each cell in the layout select the graphic element to use. For example, a layout may include text on the left, image on the right and video at the bottom. An advanced format of LayoutWidget allows the layout of individual widgets. This may be very useful for arranging Device Proxy widgets (see Device Glass) in a way that may resemble web pages, with a content that refers to resources on the local PC. This notion of layout content is used by Desktop Glasses framework.

NoteWidqet

Note widget provides a simple way to share textual written notes. Note 'paper' can have many shapes and styles and it is possible for 3^rd party to add their own note styles. VoiceNote and VideoNote

These widgets let users share notes or comments or instructions using voice or video recordable data. Voice notes for example are very useful for sharing information with drivers using car's infotainment system. Also in the case of people with disabilities, such as blind or people that cannot write for some reason, voice notes may be very useful. PDFReader

This widget lets user set a link to PDF file or load PDF from local PC and present it on the widget using PDF reader. P2P data channel can be used when available, to provide synchronization of reader operations and events which allows two or more users to read the document together. This includes the ability for one user to open a locally stored document while another user gets the document for reading without being installed locally.

PictureBox

This widget lets users add their own picture or image from their PC and present the image (picture) on the widget. When available (e.g. WebRTC supported on browser) the widget allows users to take their own picture and if P2P is also supported take a picture of a remote peer user. Advanced version may allow picture effects and frame selection either offline or in real-time with friends whenever P2P is enabled. ProfileCapsule

This widget lets users show summary of profile details possibly with profile image. The widget is connected with APIs of Social Account networks and lets the user fetch profile information that can then be shared by the widget. One can think of profile capsule as a dynamic version of business card that can be shared on various contexts.

SlideShow Sharing

This family of widgets contains media players for showing slide shows of various formats. For example Slideshare files. The user sets a link to the slide-show resources so that the widget can be used to share Slide

presentations. When P2P is available, a P2P data channel can be used for synchronizing player's operations and events so that watching the slide-show together is possible. The widget may be useful in various situations of remote training or remote consulting. TextBox

This widget is a small box for writing plain text. Depending on device and client library P2P may be enabled to provide real-time collaboration of text writing. Text Editor

This widget provides styled text editor for sharing textual content. Depending on device and client library P2P may be enabled to provide real-time collaboration of text editing.

VideoBox

This widget lets the user paste a link to a video. The video can then be presented on a player. P2P channel allows synchronization of video control operations to provide co watching

Connector Widgets

Connector widgets are mainly used for real-time collaboration. Connectors, as their name implies, use the P2P module for connecting peers in real time for various purposes.

ChatBox

A widget that provides real-time text, voice and video chat. Text chat can also be handled off-line so that any peer can leave a message that will be available to other peers next time they visit the page (or the context), or once refreshing the page.

CoBrowsing

A connector that allows co-browsing between peers. Using P2P channel the URL of each peer's browser is distributed to other peers letting each peer see the browsing of other peers in real time. Connected peers are presented in a special viewing widget running on the collaboration dashboard popup (see tools section) so that P2P connection is maintained also when user switches pages. CoBrowsing can be used for fun but it is expected to be most useful for Experts Glass sessions, for example when shopping advisor shows products in a Web store to shopper. CoDrawing

This connector provides a white board for co-drawing. The connector lets peers pass ideas to one another through simple drawing. Drawing may be shared either online or offline. FormConnector & InputConnector

The form connector is a widget that can be attached to HTML web forms elements and as a result making a form collaborative, so that two people can fill the form together. For example: registration to service is one of the most common form tasks. Many people see the registration process as a barrier for using a service. With FormConnector filling the form can be guided and in fact can be performed together with another user that understands the form application. This widget can be of great help when used with friends, and is expected to be most useful in cases of remote support and Experts Glass sessions. The widget works on the principle of binding with the events generated by HTML input elements. These events can be used to identify user activity on the form and since users are connected over P2P data channel, it is possible to send message to other peers, with information that will cause the receiver side to imitate the form operation. For example, assuming user-A writes some word in the form's input field, this operation triggers an event of "Data Change". The event is captured by the Widget, and the widget as a result sends to User-B a message that tells the receiving peer to change the value of a corresponding form field on the receiver side.

InputConnector widget is a simpler version of FormConnector to provide realtime co-writing for a single text field or other input fields such as select or checkbox.

ShareScreens

This widget uses screen capturing technology together with P2P video stream in order to share one's own screen with connected peers. Tagging and Stamping Widgets

Tagging widgets is a family of widgets used for tagging content and/or things so that either the public or a limited audience will be able to see the tag associated with the content or thing. ContentStampWidget

This widget is used to tag specific content as belonging to some category. For example, it can be used to tag Advertlet (posts or articles that act as advertisement) posts in a virtual newspaper website. When the widget is set on the article by the editor, the newspaper readers will see a stamp icon that indicates this content is an Advertlet. The benefit of this widget is that you can stamp content without installing script within the content.

TagWidget

Tag widget is a little bit different than other widgets due to its physical nature. We use it for example in CG apps for MS office. Tags are special expressions or signs that when set on a document, are interpreted by CG as meta-data by which some widget may be presented. For example @ask-me is a

hypothetical tag that when set on a Word document, is detected by CG and translated to hyper link or a button control presented on the document, that when clicked a question/answer box is opened that lets the reader of the document interact directly with the writer that set the document. In other words, TagWidget is a meta-data set in the context itself, in the form of text or maybe some code that makes a reference for operating CG functionality.

Context Customization Widgets

These widgets do not add new content but instead manipulate the underlying context. The widgets are attached with the context and manipulate it. For example, they can be used to customize a website based on state dimensions without need to program the website code. Another example: split testing of websites. These widgets are presented only on a special layer available to the widget owner while other users see only the effect of the widget. ContextVisibilitvWidget

This widget can be used to hide or show an existing context element based on CG state layers. The widget is attached with the context element and manipulates its visibility. This widget is an example of how CG can be used for "negative sharing" or in other word sharing the absence of certain content - instead of seeing a content added by the owner at given sharing context state, peers and/or website/app users see the context without the hidden content.

ContextStyleWidget

This widget can be used to apply specific style to an element of the context. For example, widget can be configured to show the border of some context element in pink for female user and blue for male user, based on a state that uses the user properties dimension.

Application Widgets

Application widgets are usually more sophisticated than basic widgets and contain some application logic.

FloatingForm

FloatingForm widget is an example of a Widget that encapsulates a full application for sharing forms where users can enter data. For example, a form can be used to present users with a survey on some subject. The users with whom the widget is shared can answer the survey and the data will be stored on a shared database.

Monitoring Box

Monitoring Box widget is capable of receiving notifications regarding emails targeted toward a specific peer and the peer user can watch the notifications - like a minimal inbox. MonitoringBox usually cooperates with an activity involved by other widgets. For example, when an answer is provided on Question Answer w dget, an event is created to notify the peer about a new answer. These notifications can be watched in MonitoringBox.

ProfilePlaylist

Create Playlist of videos from posts of Facebook, Google+ and other social networks. This is a reference implementation that shows how widgets can cooperate with Social Accounts integrations for implementing various apps that combine CG capability and social-networks capability.

QuestionAnswer

Provide Question/Answer box with an ability to trigger notifications that can be monitored by MonitoringBox.

ExpertWidget

This widget is part of Experts-Glass framework and explained in great details there. The widget is used for connecting "expert" users into the experts- network of a website or application, and is also used as the tool for starting a dashboard by which expert and ordinary users can collaborate and share data.

Service Port Widgets (Fig. 42)

Service port widgets act as proxy of personal interaction with service providers. These widgets provide interactive linkage for either getting or setting personal data related with a service.

There are a number of advantages for using ServicePort widgets over ordinary use of personal account data within SaaS:

1 . Going social directly from company website: companies that use social networks find themselves dealing with virtual assets managed outside of their own website, for example Company Page on Linkedln or Facebook, that keep users detached from their actual website. In addition, companies use social-networks for commercial purposes while actually people use them for social activity. With ServicePort companies are able to generate social engagement directly from their own website (their own virtual asset). Companies are not restricted by social-network policy. Users come to the source website instead of being interrupted in their social act. And most important, the

engagement can involve personal and private information, knowing that this information is not shared over any other 3^rd party social networks. 2. Personal Data Consolidation (Fig. 42A): Today each service provider manages its own user accounts. Personal data is distributed among service providers without being able to be linked with each other and create association. A ServicePort may be perceived as a portion of user account, something that is capable of representing personal information on the outside. Different ServicePort widgets related with the same user, that are related with different service providers, thus provide a collection of personal information. If we are able to unify these data portions by some meta service we get a system where personal information from various sources (service providers) can be consolidated and managed in one place. CG is a kind of meta service that can be used to combine portions of personal information by providing a Content Linkage between Service Proxy widgets.

3. Personal data can be stored externally: ServicePort widgets support the Computational SaaS paradigm where data processed by a service is stored on a storage facility managed by user and the service provides the computation and data processing functionality only, without holding personal data in the service repository. Accordingly, service providers who want to assimilate this paradigm for some parts of their service can use ServicePort widget as an adapter between the data that is stored on user's own storage, and the processing part that is provided by the actual service. One can think of ServicePort as a type of Data-Connector that provides service with access to personal data, where the service is responsible to perform the computation and store the processed data on a personal storage as supported by Storage module in the core of ServicePort widget.

Resources Proxy Widgets

'Resource proxy widget' is a term that is used to define a family of widgets used for representing desktop resources in order to be shared by Device Glass framework. These widgets provide a representation of the resource so that it can be accessed or operated remotely by other devices than the desktop on which the resource reside. Below are two examples: PrinterProxy:

A widget that represents printer resource. The widget provides access from a remote device to the printer located on some desktop, outside of LAN and without taking over the desktop where the printer resides. Using the widget it is possible to send print tasks to the printer, so that it can be used by other devices through a connection with PrinterProxy.

FileProxy:

A widget that represents file resource. The widget enables files viewing and possibly editing. This way a representation of the file can be shared though a connection with FileProxy.

Virtual Widget

Virtual Widgets are used to represent a linkage between two or more widgets so that this linkage can be stored as an additional semantic of CG Sphere. In other words, once linkage is established it may be embodied in the form of a widget that can be stored on CG Storage and later presented to users and shared by peers. CG provides abstract implementations of virtual widgets that can be used to represent and store content linkage.

LINKAGE GRAPH

Linkage graph refers to Widgets that were found by a search to be related by some Linkage Dimension. The Graph (relation) presents a collection of widgets that were found to be related: by similar tag, or widget of the same Glass or widgets that were created with some association one to another. The term Linkage Graph refers to the logical collection of related widgets and CG provides various applications in relation with Linkage Graph. For example, the ability to move between or the ability to associate related Widgets with an action invoked by some trigger. Linkage Dimensions

Linkage dimensions define the types of relations that can be found between widgets. Searching widgets by one of these dimensions produces a Linkage Graph collection. Here are some possible dimensions:

1 . Linkage by app properties: collect all widgets with the same

application Id or that refer to the same developer key.

2. Linkage by Glass Type: Searching for shared or owned widgets that were set on the same glass type. For example: widgets related with different objects, that were created in relation with Object-glass type. Another example: widgets related with different websites that were created in relation with Web-page glass-type.

3. Linkage by semantic of glass's identifier (Glass Id): it means that semantic rules, such as "similarity" can be applied to find identifiers across glasses. For example, a linkage between a Widget on site "www.contentglass.com" and an Object related widget that was associates with the term "glass".

4. Linkage by Widget content: Searching for relation by widget's

content, for example finding contents that share the same keywords. For example a linkage between Widget that holds the text "Financial crisis" and another Image widget with the title: "Personal crisis"

5. Linkage by Tags: Searching for Widgets that were tagged with the same word.

6. Linkage by association or proximity: The exact type of association may vary, for example two widgets created by Location Glass that were set close to each other in term of GPS coordinate. Another example: All widgets created on the same date.

7. Grouping relations: special case of a VirtualWidget that is created by grouping other widgets that show the subcomponent widgets. Sphere Pane - Visualizing Linkage Graph

Linkage graph collection is presented to user using the Glass Sphere Pane view. The view can be used either on CG client or from CG Dashboard service that provides central management of one's own widgets. The purpose of this view is to present a list with general details of related widgets. For Glass Sphere pane to appear, a search needs first to be accomplished; and for a search to be accomplished user (or program) is required to perform some Linkage graph search operation using one or a combination of the Linkage Dimensions presented above. The result of the search operation is a collection of other Widgets related by one or few Linkage Dimensions. This result is then presented on the Glass Sphere Pane, which is then used to apply various operations on related widgets.

Linkage Graph Widget Interaction

Widgets in the same Linkage Graph may be set to perform some mutual interaction with each other. The interaction is usually managed from within Glass Sphere Pane that presents the related widgets. Here are some examples of possible interactions:

In the examples below Widget-A is the current Widget used as reference for semantic rules of search. Widget-B is another widget selected from the Linkage Graph collection that was returned by the search.

1 . Data copy: copy data from one widget to another. For example copy the text content from TextEditor widget-A into the text field on

TextEditor widget-B. Each widget is exposed to the API set of copy- able items (read) and past-able items so that copy is more flexible than just copying data between similar widgets, and for similar fields of content.

2. Data merge: merging data or combining data of two widgets; for

example, merge picture from PictureBox widget-A into PictureBox widget-B and vice versa and get two widgets that show the two pictures side by side. As with copy, each Widget may define a merge-able set of data fields that can be merged so that merge semantic has clear meaning and users are able to use selecting the merging semantic. Data override: replace the content in one widget with the content from other widget. This operation is usually limited to override data with similar format. For example, override the video link in a

VideoBoxWidget by video link taken from another widget related by Linkage graph.

Operational Link: Creating operational link from Widget-A to Widget- B. An operational link may be presented as a button or text link (link in Browser) and by clicking it the user may go from one widget to another. Operational link may also be logical property in the software and Widget application may trigger the link programmatically on some Widget state.

Widgets state swap: This operation allows replacement of a state conditions of one widget reference with a state condition of another widget from linkage graph. For example, if Widget-A was swapped with Widget-B then the conditions used to invoke Widget-B will now be applied to Widget-A, and vice versa.

Tagging: Setting the same tag(s) for a selected group of widgets.

Semantic Grouping: Semantic grouping is the operation of selecting two or more widgets from the graph and applying a "logical" linkage between them in the form of a new created Virtual-Widget that refers to the selected items by some semantic.

Shared action: Setting two or more widgets to perform some action together or response to a shared trigger in a certain way. This is explained below with more details.

SEMANTIC GROUPING (Fig. 43)

Content Glass provides its search engine with a methodology that lets users contribute their own semantics to the Content Linkage search engine by adding an ability to create associations between items returned by Content Linkage Search Engine Results Page (SERP).

In practice, user selects two or more widgets found on Linkage Graph and assigns them with some "meaning" either by tagging or by setting a title or a short description. This way two or more widgets are set to be "grouped" by new semantic meaning.

To understand grouping one should think in terms of Linkage Graph and Content Glass Sphere. The linkage between widgets when looking through psychological eyes is a feature that makes distinct and arbitrary events (widgets) into a reality. It is a reality because it provides the means for relating distinct events with each other that provides the meaning. We call this meaning created by linkages: Content Glass Sphere. This is the "Whole" beyond the "Things" which is always created retroactively as in the act of "Interpretation". Any linkage is an interpretation because it generates meaning from distinct events using some mega-structure rules - The Linkage 25 Dimensions. In this aspect CG system has the built in capability of creating meaning.

Grouping extends this capability toward the Creative Power of users themselves by providing a way for users to generate Meta-Level events - Virtual Widgets. These meta-level events then become part of the CG Sphere and Linkage Graph for future searches. Grouping is therefore the ability to create new meanings and inject them into CG Sphere. Semantic Relations

The following is an initial list of specific acts that may be used by a user to assign new meaning to a group of selected widgets:

1 . Textual meaning:

a. Title: providing title to group.

b. Description: Describing the group textually.

2. Tagging: Tagging the grouped widget.

3. Visual meaning: Setting an image or picture as the meaning for this group.

4. Association by state: the group refers to a specific state or meaning of each of the grouped component. For example, let's assume two or more widgets refer to objects (Object Glass) in the space. These objects are places for tourists to visit. A relation by association can be used to set a Group that represents a recommended tour. So far this could be achieved by textual description. However, what if the

"Opening Time" of the places needs to be synchronized so that the tourist will not come into a closed place? Also what about

transportation from place to place? So let's assume that the distinct widgets composed into relation have two fields: a field that states the open/close time and another field that represents the location. Having these two fields, setting a relation between widgets also allows the user to arrange the order of places (related to by distinct widgets) according to the value set for these two fields. The implication is that a linkage search by association of order between things, for example a search with the semantic rule "what next?", may use this information defined by the grouping operation to show a list of the next recommended place to visit - a widget that should come after the current reference widget, and this is concluded from the virtual group that was previously created.

30

Presentation of groups on Linkage Graph

Implicit presentation is the presentation of grouped Widgets as a result of linkage graph that found a Virtual Widget to be related with search conditions. In other words, instead of presenting the Virtual Widget we show its components. User can drill-up from the view of distinct items to the view of one singe grouping item (virtual widget)

Explicit presentation is when Virtual Widget is presented as is. The user has the option to drill down to the actual grouped components, however the 5 presented unit is the group itself and not its component.

TRIGGERS AND ACTIONS (Fig. 44)

Triggers & Actions is a module provided by CG Client API combined with CG Server API. The module goes beyond the basic act of presenting widgets, and is intend to be used mostly programmatically, although some level of exposure may be available for end users. The module provides developers with the ability to define rules by which a certain trigger invokes a certain action on a given condition. CG lets developers set Triggers and Actions conditions for manipulating widgets. Trigger is related with a given state of an application in which some action needs to be applied. Action is the actual operation that needs to be applied on one or more widget.

For example, a scheduler mechanism can be used as the trigger for setting a flag on a widget that indicates if the widget can be presented or not, so that the widget will be presented on a Glass only for some specific period of time.

Triggers and actions can involve also interaction with Linkage Graph but this is not a must. A Trigger and a related action can be set programmatically for any set of widgets selected by a program. Using the Linkage Graph a user (or a program) can set triggers and actions for related widgets. For example: creating hierarchy of presentation between widgets on the same Glass.

Widget-B can be presented only if Widget-A was previously presented, and Widget-C can be presented only if Widget-B was first presented and so on.

The mechanism has three stages: 1 . A rule needs to be defined. The rule determines a trigger type (source) and the condition on which this trigger will perform some selected action. So we have the trigger type, the state (condition) and the action.

2. The state needs to be checked repeatedly against rule settings.

3. Once the state of a trigger source matches the defined condition the action is fired.

Type of triggers

1 . Scheduler: action will be triggered on pre defined times or periodically each given amount of predefined time.

2. Software state: on some state an action will be invoked

3. Widget state: a state of one widget is used as the trigger for setting and action on another widget.

Type of actions:

1 . Visual changes, for example:

a. Hide/Show widget

b. Change theme or style

c. Set text color

2. Widget content, for example:

a. clear content

b. Set fixed content.

c. Switch the content based on condition

3. Widget operation: perform some operation, for example send

notification.

4. Run some code.

MARKERS GLASS TECHNOLOGY/FRAMEWORK (Figs. 45 -51 ) Markers Glass is a technology that utilizes Content Glass in order to manage interactive relation of offering/using places on top of internet assets, e.g.

website, web application, mobile application etc.

Markers Glass manages interactive relations between two parties: 1 . Owner of web asset (e.g. website owner or app owner).

2. Customer who uses a place on the web asset for publishing some content.

Web asset's owner Role

The web asset's owner is interested in leasing one or more places on its asset. A place in this term is some region on a website or maybe some area on an application page, or even a full page of a mobile application.

Customer Role

The customer wishes to lease some place(s) on the web. For example, using a free place in order to post some Ad banner. After retiring from the place or upon expiry of the leasing period the customer will be billed according to the time that the place has been leased or a fixed price, depending of payment conditions of the place. Billing for place is optional. Some variations of Markers-Glass solutions may use the framework for the purpose of adding some value to users, and not necessarily for generating revenue.

Requirements

Markers Glass uses the Content Glass infrastructure to service both Website owner and Customer. Accordingly, it is required that Content Glass will be installed on a website in one of the normally used approaches: 1 . Content Glass button is installed

2. Content Glass button plugin is installed

3. Direct installation of the API

In addition, since transactions are involved, it is required that both parties will be registered. In addition, both parties should have an account in some payment or micropayment system, for example PayPal.

Markers Service

This service provides central management for finding places by prospects as well as verifying and managing places by providers. The service runs in the form of SaaS on the main website of content glass or a related website. Markers Glass General flow

Fig. 46 shows the general flow of Markers Glass. Figs. 47-51 show detailed flow for each of the general steps.

Marking Places Flow (Fig. 47)

The process of marking places involves setting special Marker Widgets on specific places on a website or an app. In the case of Website, the widgets may be set with the DOM embed feature, so that a widget is embedded as an element in the page and therefore maintains its relative position. In the case of mobile apps, a variety of approaches is used so that a widget can mark a region on application page, or may be a full page.

Regardless of the technique used to set the Marker widget, once it is set it will be presented only to prospect customers that operate the "show places" function. Other visitors of the website, or users of the app will not see the marks. In other words- markers to not interfere with the normal view of app or website. They can be watched only on-demand.

Flow for Invoking marked place and setting content there (Fig. 48)

Once marks have been created, prospective customers may arrive to the website either directly or by using the "Markers" service on

www.contentglass.com that provides overview of many places and a link to get there. The flowchart of Fig. 48 describes the steps of invoking places marks by prospects and placing a content in a place.

Verification Process and Approval or Disapproval Flow (Fig. 49)

The verification process is aimed to check that presented content matches the terms of the leased place and that the customer is reliable and can be trusted to pay. In some cases the payment occurs in advance, in other cases payment is requested upon usage.

Testing and verifying content in places can be handled either from a special view associated with ContentMarker widget or from "Markers" service on www.contentglass.com Presenting approved markers content (Fig. 50)

After approving the content on a given marked place the content becomes available to the public. This part is different from conventional Content Glass scenarios in which shared content is usually limited to the scope of peers- group, either defined by user or by application.

Content Glass API includes a dedicated CG Layer for fetching approved content of places, for a given webpage or app. The process of loading data for public layer is very similar to the process of getting shared widgets from non-public layer, however, the criterion of peers-group in this case is dismissed from the search, so that the content is not limited by peers-group and can be invoked for any visitor of the website. The process of presenting the content widget is exactly the same process as of presenting shared widgets by other CG patterns - widgets data is received from the server and is then used to create and render widgets on the Glass rendering container. Marked Place Expiration Flow (Fig. 51 )

A process that is runs on the server-side API scans widgets related with places and confronts them with settings of corresponding ContentMarker widget representing the place. If expiration date or period timeout has been set, delete the content widget that utilizes the place and notify both customer and website owner.

Combining Markers Glass with State Dimensions

Markers Glass can be combined with state dimensions in two major ways:

1 . Associate state dimensions with the ContentMarker widgets. The purpose of applying state dimension to place markers is to limit the markers to appear on some given condition and accordingly limit the content to a certain state of the context. For example, it is possible to use the time dimension in order for markers to be shown only for a limited period(s) of time. Another example, it is possible to use properties of user info browser dimension in order to present the markers only for people of some given country, and so on. Content widgets that are set in those places therefore inherit the state dimensions of their underlying places. While it may be helpful to force the same state condition on a ContentMarker as that of its designated content Widget, this is not always the case. In some cases

Content Markers may be presented on a normal state, but the state for presenting a content related with it is more restricted and should be specified in the leasing terms. For example, on an international news website we may not restrict the appearance of markers themselves, however we will define the markers with a rule that limits the attached content by some time dimension. So advertiser in Israel for example can set a content that will be available only for audience in the EDT time-zone.

2. Customer configures state dimension to the content widget set in place.

In this case like with any other widget, and since the place is leased anyway, it is possible for customer to determine that content will appear only for some given state. For example, only for users at some given location or only when it is cold outside.

Sharing a marked place by more than one customer

Advanced mode of Markers Glass also enables the sharing of a place by more than one customer. For example, if some content is limited to a certain location, then other content of a different customer can be presented when the location is different. Of course there are implications of leasing contract and calculation of payments.

Tracking

In some situations tracking of impressions and user interaction events may be required by content widgets set in places. For example, if the content includes Ads, it may be required to count impressions for the purpose of billing.

Tracking of content appearance in places uses both basic tracking handled by CG system and possible integration with an external tracking system using an API. For example, integration with Google Analytics or Piwic or similar software/service. Example 1 - Markers Glass for On-Demand Ad Placing

Markers Glass can be used as a system for setting ad banners or text ads on a website. Website owners (Publishers) mark places where they want ads to be set. Advertisers search for open places, where ads are allowed (according to place terms) using the "Markers" service, based on website category and other criteria. Once found, advertiser goes into website and places ad banner or textual ad in the place. Upon approval the ad starts showing to the public.

What makes this approach different from other approaches?

- No need to install any additional script on the website beside Content Glass.

- Advertiser can select the exact place where ad will appear.

- Advertiser has full control of when ad will be shown, which is the

timeout or expiration period of a place (if set).

- Advertiser has full control on when to remove the ad.

- Publisher can directly contract with advertiser and get paid (the place terms) and does not depend on some mediator.

- Advertiser can have its own custom widgets developed for its purpose and can ask the publisher to include its library for CG to load the special widgets. Adding custom library has no integration barrier.

- Markers Glass and Experts Glass (Virtual Consulting network) can be combined in order for advertiser to achieve direct contact with leads on publisher website.

- Advertising relevancy can be controlled by state dimensions (see

example 3). Example 2 - Dynamic Boards pages

Board pages show a collage of messages from various sources in one place.

Website owner can use Markers Glass in order to create a dynamic board page by placing markers on a table. For example, a board for selling cards, a board for private teacher etc. People who want to publish on a certain board will position their note Widget or picture, or application, etc. and once confirmed they are promised to be presented there. Example 3 - Combining Markers Glass and State dimensions

Let us take the Ad markers example from above. We can add location dimension settings to the banner ads widgets in order for these widgets to appear only when user is located as some region of the city, or maybe some country. Assuming that we advertise a coat, we can make the banner appear only when it is cold outside as measured by a temperature sensor of user's wearable or mobile device. Assuming we advertise evening dresses, we can use the time dimension in order to make the banner appear only when it is night. To summarize, adding state dimensions can be used to increase relevancy for exposure of content.

Example 4 - Combining Markers Glass with Expert Glass Dashboard

Experts Glass (Virtual Consulting network) is used in order for website (or app) visitors to interact with experts. By combining features from Experts Glass into Markers Glass the content widgets set in marked places may also function in a similar way to experts-glass. An advanced feature of markers glass makes the content Widgets having similar capabilities as of 'Expert- Widget' (the widget that is used by Experts Glass for interaction between visitors and experts). The general idea is to use the markers glass in order to allow direct interaction between advertiser (the one that set the content widget in the place) and leads (visitors).

EXPERTS GLASS TECHNOLOGY/FRAMEWORK (Figs. 52-56) Overview

A state oriented experts-network is a network of users that are willing to contribute their expertise for the purpose of helping other users, either for free or for some incentive provided by a website owner. Experts-network can be created by website visitors without being organized in advance by the website owner.

The participants in the experts-network may be divided according to two roles: Expert: Users who join networks of experts in order to use their expertise to advise, consult, help, support or train other visitors to website (or other users of mobile app).

Visitor: Some end-user that is asking for help, advice, support etc. with regard to subject matter.

Experts-Glass networks has a few characteristics that distinguish it from other types of on-line help solutions:

1 . Independent or voluntary: An experts-network can be created

independent of context provider, i.e. the owner of the website for which experts-network is created. In fact, end-users can voluntarily join and/or use experts-network over some website without the need for CG to be preinstalled or integrated with this website. This can be handled by CG browser plugin or CG Bookmarklet. In practice, however, we provide a way for a website to allow or disallow experts-network on top of it.

2. Can be used with affiliation model: Experts-network may serve the website and it may be of interest for website owner to provide some incentive for qualified experts. Therefore experts-glass may act as a kind of affiliate network. Still, the nature of experts-network is to be initiated by website visitors or community.

3. Ad hoc networks: An experts-network is initialized once one or more end-users decide to set an Expert-Widget on a website (or app). This act is a spontaneous ad hoc event the same as the event of leaving the experts-network. The network is created ad hoc based on willingness of visitors and/or incentive given to visitors to provide some service based on user's own expertise.

4. Run on top of Content Glass technology: experts-network runs

entirely on top of Content Glass using the same widgets as can be used by CG users regardless of advisory networks. In fact, experts- network is a case of State Oriented Sharing app - the shared factor is user's own expertise using CG platform and CG collaboration tools.

5. Dynamic peers group: Unlike basic State Oriented Sharing in which end-users build their own peers-group in order for sharing to occur, experts-network uses a dynamic grouping to allow for Expert and Visitor to become part of the same peers-group in an on demand session. Dynamic grouping exists in many other state-oriented sharing apps (SOSA) and is part of the grouping functionality provided by CG API.

Terminology

Experts Network

Experts-Network refers to one or more users that join a network of users considered to be experts in the subject matter of a website. These users are willing either for free or for some incentive to contribute their knowledge in order to help other users. The network may be created, exist or terminated based on expert users will. A user is added to an experts-network by setting a special widget (Expert-Widget) on a website. A user is removed from the network by deleting the widget. Once in the network user can perform various activities of helping ordinary visitors, such as answering visitor questions and getting into on-line session with the visitor.

Experts Peers-Group

In order for visitors queries to arrive into a group of unrelated expert users, the framework internally manages a peers-group logic, that includes all experts. This logic allows for example for different nonrelated expert users, to receive a query sent by a non connected visitor. This group is managed internally by server-side CG API without user intervention.

Visitor Queries

Ordinary visitors can send questions and/or requests (queries) to the experts- network. These queries are distributed among experts of a given website. Advanced features allow distribution of queries based on fine-tuned expertise category so that a query can be sent as related with a specific category and be distributed to a relevant group of experts.

Choosing Expert

Visitors are able to choose an expert and start an on-line session. The Ul for viewing available experts and selecting an expert to get into session with, is implemented in the form of Experts-Toolbar widget. When expert is selected for a session, CG creates an ad hoc peers-group of expert and user and starts an on-line session using a collaboration dashboard tool. The dashboard provides collaboration widgets by which user and expert can communicate and exchange information.

Consulting Session (Fig. 53)

Consulting session is an on-line session between expert and visitor. In an online session CG adds the user automatically into the peers-group of the Experts-Widget related with the expert. By doing this Expert-Widget becomes available for the user. Both sides can then start a collaboration dashboard from a button on the widget. The dashboard shows a toolbar by which user and expert can select collaboration tools to use. The tools are actually ordinary CG widgets (for example Chat, Co-Browsing, Co-reading etc.) however, user is not required to set the peers-group for these widget. It is set automatically to contain the account Id of user and expert. This way any widget is automatically set for collaboration between the sides.

Experts-Glass functional flows

Expert is added to network (Fig. 54)

The flowchart of Fig. 54 describes a situation in which a user arrives at a website and decides to join its experts-network.

Visitor Flow (Fig. 55)

The flowchart of Fig. 55 describes a situation in which a visitor arrives at a website where experts-network is defined and starts an interaction with some expert(s).

Experts-Glass Components (Fig. 56)

There are a few components that compose Experts-Glass:

Expert-Widget (Advisor Mode, Visitor Mode and Dashboard)

Experts-Toolbar Expert Account

Performance tracking

Rating

Expert-Widget Functional Description

Experts Widget is a special CG Widget created specifically for the purpose of Experts-Glass framework. This widget is used for two purposes:

1 . Declaring the presence of an expert user in the experts-network - when a user sets this widget on a website the user is added

automatically into an experts-network of the related website.

2. Providing a reference point for starting the Ul for interacting with

visitors - Collaboration Dashboard.

Expert-Widget has two facets: one for the Expert (the owner of the widget) and another for a visitor. It means that these two types of users see an instance of the same widget, however in a different way.

Expert-Widget - Expert Mode

When a user sets the Expert-Widget on a website page a special process takes place that adds this user into an ad-hoc network of experts for this website. In the same manner when a user deletes the Expert-Widget he will be detached from the experts network of the website.

In addition, Expert-Widget is being used as the proxy for operating the collaboration dashboard tool. Without getting too technical, the widget acts as controller for operating the dashboard in relation with the two users. For example, the widget instructs the dashboard which tools need to be enabled depending on the current user. Expert sees some tools that user does not see. The dashboard is used for example by expert to receive and/or answer questions sent by visitors. Expert-Widget - Visitor Mode

When a visitor gets into a Website the user does not automatically see Expert- Widget (unless this specific user/account was added in advanced into peers- group of this widget). The presence of Expert-Widget to visitors is a little bit different than the conventional approach taken by regular CG app. In fact, for visitor to interact with an expert through Expert-Widget, it is first required from the visitor to select an expert from the Experts-Toolbar widget (see below) and start an on-line session with that expert.

When a visitor asks to start a session with a specific expert, the visitor is asked to login with one of his social-accounts (if he hasn't done so already). The social-account Id of the user (e.g. gmail address) is then added

programmatically into the peers-group of Expert-Widget of the requested expert, and the page refreshes. All this happens in the background without user intervention, and after page refresh the visitor will see the Expert-Widget of the requested expert, as in a conventional widget sharing scenario.

Expert-Widget can now be used by the visitor to operate collaboration dashboard and interact with an Expert using the collaboration widgets provided by the dashboard. For example Chat-Widget, Share-Screen-Widget, Connector-Widget, PDFRead-Together widgets and more.

Collaboration Dashboard

The dashboard provides a collection of CG Widgets that can be used for offline and on-line collaboration between Expert and Visitor. The same widgets are provided by CG API and can be used individually. The difference is that when attached with the dashboard, widgets and their control

mechanism are arranged in a way that provides a unified collaborative experience. In addition, widgets are set automatically with a peers group that includes both expert and user, so sharing and collaboration is immediate and there is no need to manage peers-group manually. Some examples of widgets:

• Chat • Widgets Board where parties can share widgets such as: Text-Box , Notes, Photo, Video etc. (the basic widgets provided by CG)

• On-line collaboration widgets: Co-Browsing, Co-Reading of PDF , Co- Viewing of Slideshows , Web Form Connector

· Custom 3^rd party widgets

For expert user only: dashboard also includes one Queries Inbox that shows queries compiled by Visitors through Experts-Toolbar widget. Using this widget the expert can answer queries sent by visitors and also send an invitation link to a visitor that when clicked, a session with the expert will be established.

Experts-Toolbar Widget Functional Description

Experts-Toolbar is a special CG widget that provides the Ul for visitors to perform an initial interaction with Experts. The widget is presented on a public CG Layer, whenever at least one expert exists in the experts' network of a website. It means that when some experts-network exists for a website, all visitors will see the Expert-Toolbar widget and all visitors will be able to send queries to the experts.

The widget is used for three major tasks: 1 . Providing a Ul where visitors can send queries to experts - queries are textual questions or requests for help.

2. Providing a link for accessing expert profiles on CG main website.

3. Providing the Ul that lets visitors select an expert and start a session with this expert. Experts-Toolbar widget has some unique behaviors when comparing with ordinary CG widget:

1 . Automatically Installed: It is not required for a user to select this widget and add it to a website. In fact, widgets gallery does not provide an access to set this widget. Presenting the widget on a website is automatically controlled by Experts-Glass framework logic. It is usually shown when at least one expert exists in the network and hidden when there are no experts in the network.

2. Run in a public layer: This widget is hosted by a public CG layer. A public CG layer is required here since we want the widget to be presented to all visitors of a website.

Interaction with Experts

Since Experts-Toolbar is used for sending queries to experts and for getting into live sessions with experts, and since Expert-Widget is the interface by which experts interact with visitors, there needs to be some interaction between the two types of widgets. The following section explains how this interaction is implemented.

Experts-Toolbar Widget provides two levels of interaction with Expert- Widgets:

1 . On-line interaction: P2P connection is established between Expert- Toolbar widget on the visitor's side and Expert-Widget on the expert's side, using the conventional P2P data channel that is used for P2P interaction between widgets.

2. Off-line interaction: Visitors' queries as well as experts' answers are managed within the data store of Experts-Toolbar widget (as with any other widget). This allows information to be shared by exchanging data by server- side logic related with Experts-Glass framework.

Expert Account Functional Description

Having an expert account is optional. In the most basic case experts can simply join a network without having any account recognized with their legal entity. However, there are benefits to having an account. Accounts are created by registering in the Content Glass main website, and applying for the role of "Expert".

Having an account provides the following benefits: Some websites may force a settings that requires experts to first have an account. In these cases users will not be able to access the Expert- Widget without first having an account and without first logging-in with their credentials. Login with CG user account credentials is managed from the "preferences" view in CG Client.

Having an account provides a way for experts to create a profile where the expert can present his/her expertise. This of course contributes to reliability and may help the expert to promote himself.

Expert account is required for the purpose of performance tracking and expert rating.

Performance Tracking

Performance tracking feature becomes relevant only when expert has an account. The account is required in order to attach the performance data with a profile of the expert entity. Performance can be measure and tracked on various events. Here are some examples:

• Clicking on invitation links sent from expert to visitor

• Time of session

• Time till selecting expert since landing on a page

· Clicking on various chat command links that may be used during

session

• Usage of tools, for example number of chat messages

• Numbers of queries responded

• Other

Rating

For having some rating value, an expert needs to have an account. The rating can then be related with the expert profile and can be presented to visitors when deciding if they want to get into session with some expert. There are two scales for rating experts: 1 . Visitor Rating: a rating provided by visitors following a response to a query or following a session with an expert.

2. Service Provider rating: This is a rating that can be provided by a website owner as a tool for website owners to recommend some experts acting on the experts-network active on the provider's website.

DESKTOP GLASS TECHNOLOGY/FRAMEWORK (Figs. 57-69) Overview

Device Glass and Desktop-Glass are two related technologies. Device Glass is the core technology of widgets of type Resource-Proxy that have the ability to represent a relationship with resources on a desktop or other device. Desktop-Glass (Fig. 57) is a framework that utilizes device glass for the purpose of creating mini-portals running on a user's desktop and basing their content on conventional resources usually found on a desktop - Word files, Excel files, PowerPoint, Plain text files etc.

Resource Proxy Widget

The Resource-Proxy widget represents the main widgets technology used by Device Glass. Resource-Proxy widget has a behavior that is similar to the behavior of other CG widgets: 1 . The widget has local and remote memory representations.

2. The widget is created and rendered on top of a Glass (that in this case is created as part of a desktop application).

3. It is related with a State - the sharing context is derived from the desktop app that runs CG API. 4. It's state is managed by the concept of Content glass State layer

5. A peers group can be set to narrow the scope of widget presentation and set the social boundaries of the sharing 6. Advanced functionality includes: P2P connection that allows on-line sharing and collaborating in relation with a widget.

This widget however has some unique capability not found in ordinary widgets. The unique capability of Resource-Proxy widget is its ability to connect with desktop resources such as file and other devices connected with the desktop via some device driver, such as printers, storage, camera etc. For simplicity we will refer in the examples only to files.

Resource-Proxy widget has the following unique abilities:

1 . Being related with a resource. Example: holding a file path data. 2. Having a basic mechanism for checking the availability of the resource. Example: checking if file exists.

3. Establishing connection with the resource. Example: open file for read/write.

4. Establish stream with the resource. Example: read and/or write from file. Resource-Proxy widget is used by desktop applications that use the CG API, and would like to share content found on desktop in the form of files or other resources. One example for such application is the Desktop-Glass technology that is explained below.

Algorithm for Creating Resource Proxy Widget (for File) (Fig. 58)

The flow of creating Resource-Proxy widget is quite similar to the flow of creating an ordinary CG Widget. In the case of Proxy-Widget however, the user selects the resource to which the widget will be related. In this case the user selects a path of file that will be mediated by the widget. Note that the widget does not hold the file content but instead holds the path, and possibly other meta-data about the file, such as permissions. Resource-Proxy as set by its name is a proxy for accessing the resource. It lets us share file metadata but is also lets us read and/or write to the file data exchanged via P2P data channel. Algorithm for Invoking Shared Resource Proxy (Fig. 59)

Resource-Proxy widget is invoked from remote-storage in the same way as other CG Widget. Given Glass application that is set to a given state, all widgets related with this state and shared with currently logged-in user are loaded. For example, if we created application named "PC Share" with CG API embedded, we set state fields for this application (example: Glass- Type=99 Glass-ld="PC Share") and load shared widgets of currently logged- in user. So far this is the usual algorithm for loading shared widgets. However, in the case of sharing Resource-Proxy widgets there is another step of connecting with the remote resource. For that there is a need to connect with the remote desktop and then connect with the remote instance of proxy widget that mediates the interaction with the actual resource.

Connect with the source Desktop (Fig. 60-61 )

The first challenge is creating a mechanism that lets two desktops discover each other in order to achieve data stream connection that will be used for transferring resource data and/or resource commands (e.g. a command to print or a command to take picture). This mechanism is both: "accountless" and "meta-data based"

The term "accountless" means that user should not be subscribed and logged in on some SaaS in order for sharing to be possible.

The term "meta-data based" means that there is no copy of the resource on a shared resource on a network. For example, in the case of Microsoft

OneDrive or in the case of GoogleDrive, resources are shared by having a shared copy of the file on a central server. In the case of Device Glass the shared information holds only meta-data that refers to the resource on its original desktop.

There may be various approaches for resources on a network to recognize each other. The following describes only two of the approaches, both can be used depending on network capabilities: i. Broadcastinq/P2P (Fig. 60)

This approach uses UDP broadcasting. In practice it is more suitable to use high level API (such as JXTA or WebRTC) that knows how to overcome various limitations of broadcasting interaction and provide the core for P2P interaction between two desktop apps. ii. Shared Port on centralized DB (Fig. 61 )

The second approach is more primitive in terms of network solution for such a problem but it can be implemented very quickly and be used for a broad scope of implementations. Interaction with Resource (Fig. 62)

The following algorithm describe an interaction with a resource. For the purpose of this example we refer to file resource only. While the general mechanism on widget interaction is similar for different types of resources, each resource type have different API of interacting with. Therefore we use in practice different types of Resource-Proxy widgets for interacting with different type of resources.

Note that Resource-Proxy widget does not store the resource data on its public shared copy. Only meta-data about the resource is shared and this meta-data is used for establishing interaction. The major principle of sharing content is by sending a copy of the original resource to the requesting app (on Desktop-B in the flow). This copy is stored in a "Sandbox" and can be viewed or change. The Sandbox is a memory area assigned to the copy of the file loaded from the source desktop. Any manipulation of the file is handled within the sandbox. Updating resource (write operation) (Fig. 63)

After opening the interaction channel between the two desktops, the application can load the shared resource for edit (if permissions allow). The changes are monitored, and when change is saved the new content is delivered to the source desktop, where the original copy of the file resides. The change can then be applied to the original file. Desktop Glass Overview

Desktop Glass framework utilize Device Glass technology to generate remote interaction with desktop resources, in order to provide end users with an ability to create mini portals on their desktop from ordinary known file formats existing on the desktop, and without the need to have any IT and/or web programming skills or expertise.

Desktop Glass uses Portal-Widget - an advanced variation of Layout-Widgets that provides a layout on which other widgets can be created.

Generally it can be claimed that Desktop-Glass is a technology that provide a way for composing widgets into mini-portals running on a desktop and exposing resources located on end-users' desktops side by side with collaboration tools.

The sharing mechanism used by Desktop Glass is similar to the mechanism used by Device Glass. However, instead of sharing distinct Resource-Proxy widgets we share Portal-Widgets.

Desktop Glass Functional Flows

Creating mini-portals (Fig. 64)

Fig. 64 shows the general steps for creating a new portal. The highlight of this process is that users get some drag and drop visual editor that lets them create views with content found in files set on the desktop. We can see the difference from classical working process when creating a website. Let's assume that user has some Word document with content that user want to show on a website. For doing that user needs to convert the document into HTML, buy a domain name, lease some hosting plan or use some hosting service, install a webserver, and upload the HTML content. Of course it is possible to use some SaaS service for generating websites, still the process requires some learning curve of working with the service and understanding it. In the case of Desktop-Glass user starts the application, defines new portal, designs a layout for arranging content and selects files to present in the layout. No domain name, no SaaS service, no webserver, no HTML, and very low learning curve. Desktop-Glass and Portal-Widget are not intended to replace ordinary websites, but they open a new opportunity for anyone to create his own desktop portal.

Viewing portals (Fig. 65) Note that conceptually viewing desktop-glass portals from desktop apps and viewing desktop-glass portals from web pages is similar. The only difference in the underlying container app: either a desktop application or a web browser.

Since mini-portals may be created using various CG APIs it is important to note that each viewing application can support Mini-Portals created by the same technology. For example, when creating the Mini-Portal with CG Web API (Java Script) then the Web viewer used to watch mini-portals needs to be able to present CG widgets from CG Web API.

Desktop Glass Unique Widgets

Two widgets play a major part in the creation and sharing process of Desktop- Glass mini-portal application. The next chapters explain the two widgets that participate in the construction of the mini-portal: Layout-Widgets and Portal- Widgets.

Layout-Widget

Layout Widget is a Content Glass widget that provides various layouts for setting widgets. A layout is made of cells. Each cell may contain either a widget or static content. Layout-Widget is also the base for creating mini portals. Layout Widget shows widgets in two modes: Edit and View

Edit mode of layout-widget: The edit mode is used for setting widgets and static content in cells. Each cell can occupy a single widget. While working in the edit mode widgets are presented with their toolbar, letting user edit and set the peers-group for each of the widgets. Note that not all the widget necessarily have the same peers-group .This allows some content set in the layout to be presented to some users, while other parts can be presented to other. Fig. 66 shows an example of a tabular Layout-Widget that provides a tabular layout of cells. Each cell contains one widget that is presented with a toolbar, same as ordinary widgets in a Glass application.

Inherit Peers-Group

When hosted by layout it makes sense to provide widgets with the options to inherit the peers-group and possibly other settings from the parent Layout- Widget or from the top level Portal Widget. The option for inheriting parent's settings is added to the toolbar menu of the hosted widget only when widget is hosted by Layout-Widget. View mode of layout-widget: The view mode is what is presented to users with whom the Layout-Widget is shared. When running in a view mode the widgets are rendered without their toolbar - which is called "content only mode". Accordingly, only the content part of widgets is being presented. Fig. 67 shows the same layout as above but in a view mode. Note that in the case of Resource-Proxy Widget that is hosted in a layout the "content only mode" will not show or open the software related with file type. Instead, a transformation will be applied on the file content to show its content in a read-only mode. For example, MS word doc can be transformed to HTML that will be presented in the view mode showing the file content in a styled fashion. The transformation of file into view presentation is handled

automatically for known file types. In the case that Resource-Proxy wants to expose a file for editing and not only for viewing we provide a small image button on the widget that when click, the file is open for editing using the software related with the file type. For example, in the case of MS Word file, the Word software will be loaded with the file content, as saved in the local Sandbox.

Sharing mechanism of Layout-Widget

The layout widget and the contained widgets, each has its own instance. For example, in the images of Figs. 66 and 67 there are 5 different widgets: the layout widget plus the four contained widgets. In order to allow each widget to define its own scope we do not merge all widgets into one but instead each widget has its own instance in the storage (like any other Glass application). There is only one exception however: the contained widgets are not presented if the state conditions blocks the Layout- Widget from appearing. CG manages a sophisticated logic for layout scope based on the peers-group of hosted widgets.

Portal-Widget

The Portal-Widget lets users create mini-portals on their desktops by composing Content Glass widgets. This is the top level widget used by Desktop Glass, for creating and showing mini-portals. The Portal-Widget extends Layout-Widget by adding some more capabilities required by mini- portals, other than layout widgets.

The Portal-Widget is a CG widget, used as the top level widget in a mini-portal created be Desktop-Glass framework. The content area of the Portal-Widget contains one or more Layout-Widgets used to show the content of a portal. The side bars of the portal-widget contain widgets that can be used for browsing content layouts, or providing added value tools to the mini-portal.

Fig. 68 shows an exemplary layout to be used for creating a Mini-portal. The toolbar & menu area contains a menu and tool buttons. This is a similar approach as used by conventional desktop apps, where the top bar is used for holding a menu and tool-bar.

The Top, Bottom, Left and Right panes are used for holding various tool widgets and or content based widgets. The contained widgets are actually ordinary Content Glass widgets, either built-in or third party widgets. The tools are used to enrich the mini-portal with functionality. In addition, a pane may include navigation menu for browsing among Layout-Widget views in the central content area. Some Examples:

1 . Navigation: Tabs-Widget, Menu-Widget, Links-Widget

2. Tools: Chat-Widget, Open-Remote-File-Widget ^* 3. Content: Note -Widget, Resource-Proxy widget

* Open-Remote-File-Widget can be thought of as Resource-Proxy-Widget that instead of just representing a single file on the desktop, represents a file-system, so that it is possible from remote to open a file for viewing and/or editing using the core mechanism of Resource- Proxy widgets.

Views pane contains instances of Layout-Widgets showing mini portal views. To switch among layouts (which is in metaphor similar to switching pages in a website) user uses either the toolbar navigation buttons or layouts can be switched by menu and/or toolbar, or by view control widgets in the side bar panes, such as tabs widget or links widget.

View mode of Portal Widget: The view mode used by Portal-Widget is similar in concept to the view mode of Layout-Widget (that is the base class or prototype by which mini-portal widget is made). When in the view mode users see only the content facet of the widgets contained by the mini portal layout. If some widgets are set to a narrower scope of users or dimensions than the top level widget (the portal), these widgets will not be presented. If in a sidebar pane or in the main views pane, none of the contained widgets can be set due to inappropriate peers-group scope or due to certain combination of state dimensions, the label "No access" is presented. In other words - a portal is like a puzzle of widgets and each individual widget may have its own sharing scope.

Edit mode of Portal Widget: The edit mode allows users to compose widgets and build the mini-portal. Desktop-Glass provides a minimized portal editor for creating portals.

The editor has three major parts:

1 . Create portal wizard: the wizard walks the user through the basic steps of creating new portals.

2. Settings section: the settings section provides views for changing portal settings.

3. Editor section: this is where user composes the portal. Mini-Portal Editor (Fig. 69)

The editor contains three major parts:

1 . Portal Tree: The tree is used for representing the hierarchical structure of widgets contained by portal and providing easy navigation for accessing widgets.

2. Portal Layout: Portal layout is where portal components are added into layouts.

3. Menu and toolbar: provide the required controls for editing, saving and setting the sharing properties of portals.

Fig. 69 shows a conceptual portal editor.

GLASS-FOR-SEARCH TECHNOLOGY/FRAMEWORK (Fig. 70-75)

Glass for Search or Glass4Search is a Content Glass framework for sharing widgets in the context of search engine result pages (SERP). The SERP as a context for sharing content is a special case since users use search words and phrases that can be used to compose the State Id for sharing CG widgets.

Search engine pages today have a major part in Internet sociology. Users are using search pages as entry for accessing knowledge. The act of searching is a recognized behavior and search engine providers make a continuous efforts to shape the search behavior and user experience on search pages in various ways.

While search engine providers take care of the "access to data", what Content Glass can bring into search user experience is meta-level of referring to the search activity itself. The subject referred to by Glass4Search is therefore the act of search itself and the semantic relationships of the searching user with the search results. Glass4Search is therefore not a new search engine, neither a searching methodology. Glass4Search is CG framework for sharing, in the context of search engine pages, that provides an appended social sharing and user experience based on user's search terms and the resulting list of searched topics.

Glass4Search major features:

• Used on search engine pages.

• Uses user's search terms to construct the sharing state.

• Combines search terms with CG multidimensional state mechanism.

• Uses CG semantic grouping to generate virtual-widgets from search result items.

• Can be used with multiple search engines (each engines require a dedicated parser).

CG Installation for search engine pages

Glass4Search uses the conventional installation approaches for making CG work on search engine pages:

1 . User uses CG bookmarklet or browser plugin to operate CG when in search engine page.

2. User uses browser plugin.

3. By direct installation of CG API into search engine pages.

Functional Flows (Fig. 70)

The situation occurs on a search engine portal. We do not define a specific portal or search-engine since Search4Glass can be used with multiple search engines. User performs search and the results page is used to construct a sharing context, based on search term. From here user can create or view shared widgets, as well as add semantic to the search results by creating virtual widgets. Sharing State by Search Term - Using text as is

Fig. 71 shows the operation of preparing CG state from a search term, using the search term as Glass-ID (refer to CG State Oriented Sharing for more details about Glass-Id field). Sharing State by Search Term - By predefined terms list

Fig. 72 shows the operation of preparing CG state from a search term, but instead of using the entire search term the algorithm uses a specific word or term from a list of predefined terms. The selected term is then used as Glass- ID. For example, given a predefined list of terms "crisis, political, election" provided by the search engine provider and given a search term entered by the user: "who will be the next prime minister in 2015 election". The word "election" is taken and is being used to set the sharing content.

Sharing State by Search Term - Interpreted Dimensions In this flow, as shown in Fig. 73, the search term is parsed in a way that various words are interpreted as related with CG state dimensions. The sharing state is then composed of these dimensions. For example, if a user sets some date in a search term we parse this term into actual date data and use it to set the date time dimension in CG layer. If a user mentions some location we parse it into actual location details and use it to set the location dimension of CG Layer etc.

Creating Virtual Widgets from search results

The following mechanism, as shown in Figs. 74A and 74B, uses the Semantic Grouping feature. Semantic Grouping of Content Glass is an operation of creating some semantic relation between two or more widgets and saving this relation. The product of this operation is a Virtual Widget.

Glass4Search framework refers to both: the internal search-engine of CG for searching of Linkage graph and other search engines such as Google, Bing Yahoo, etc. A similar technique is applied in both cases. In the case of CG internal search mechanism, a semantic relation is applied on actual widgets found in the search view, as result of searching widgets by some criterion. In the case of Search Engine the situation is a little different, since there are no widgets to perform the relation on, but search result items instead. To overcome this challenge Content Glass perceives search result items as if these were ordinary widgets with textual content and a link. So if, for example, user performs search in Google and gets as response 10 results, Content Glass applies a hidden logic that perceives each result as if it was a widget.

To implement a grouping of two or more SERP results CG provides a special Ul tool that lets the user mark SERP items to be included by semantic grouping. The user can then click "Group" button that actually creates the Virtual Widget. The next operation is similar to setting details of virtual widget from items found in CG SERP (see Content Glass -State Oriented Sharing).

When ready, the new widget is stored on Content Glass remote storage. As a result of this activity the widget will be loaded next time a search is performed using the same sharing state (as defined by the search term).

Loading Virtual-Widget related with SERP (Figs. 75A, 75B)

When a search engine page is loaded a sharing state is established according to one of the flows describe in Fig 75A and Fig. 75B. Once the state was set, it is possible to load shared widgets associated with current SERP. This also includes Virtual-Widgets that have been created previously on the same sharing state.

In the case of CG internal search we can associate Virtual-Widget with its source widgets since each widget is precisely identified by UID. In the case of ordinary search engine we cannot, since search engine items are not identified entities but arbitrary results of a search mechanism, and because search engine items' text continuously vary, even for the same search term. In short, we assume that search result items are not identified entities, therefore we cannot really associate them by Virtual-Widgets created from search items. However, we can associate between the Virtual-Widget and the links (URLs) that were referred to by the search items. Accordingly, when loading Virtual-Widget we analyze the search items and if we find items with the same URL we refer to them as related, and show this relation on the page. If we find a few items with similar URLs we take the closest URL based on URL's host name, path and query string. Example given:

URL 1 - http://www.contentglass.com/content/glass4search

URL 2 - http://www.contentglass.com/view/sosa

The URL http://www.contentglass.com/content/layers is closer to URL 1 above than to URL 2, if comparing by URL path.

Claims

1 . A method of multi-dimensional state oriented sharing over the Internet comprising sharing data relating to an object according to sharing context defined by the object state.

2. The method of claim 1 wherein said object is selected from the group consisting of physical and virtual objects.

3. The method of claim 1 , wherein said object state is selected from the group consisting of: codes, paths, URIs, physical and physiological factors, locations, time, verbal words or phrases, marks, signs, conditions, functions, states and events that define a specific state or condition of the object.

4. The method of claim 1 , wherein said object state comprises mandatory fields and optional fields.

5. The method of claim 1 , wherein said sharing comprises creating and sharing widgets of various types.

6. The method of claim 5, further comprising a transparent layer of

software (Glass) that allows widgets to be layered on top of or in relation with external context.

7. The method of claim 6, wherein a glass comprises a glass type

representing the sharing context type and a glass ID representing the sharing context state.

8. The method of claim 7, wherein said glass type is a representation of the context selected from the group consisting of: website, object and place.

9. The method of claim 5, wherein said widget types are selected from the group consisting of: basic widgets, connector widgets, tagging and stamping widgets, context customization widgets, service port widgets, resource proxy widgets and virtual widgets.

10. The method of claim 5, wherein said widget is shared offline or online with a group of peers.

1 1 . The method of claim 10, wherein said group of peers is selected from external networks.

12. The method of claim 10, wherein said group of peers is selected by a user.

13. The method of claim 10, wherein said group of peers is created ad hoc by an application from peers that share the same state of the object.

14. The method of claim 10, wherein online sharing comprises peers in the group communicating over a P2P network.

15. The method of claim 5, further comprising defining relations between widgets in a linkage graph.

16. The method of claim 15, wherein the linkage graph may be viewed on- demand.

17. The method of claim 15, wherein said relations comprise linkage of one of application properties, glass type, semantic of glass identifier, widget content, tags, association or proximity and grouping relationships.

18. The method of claim 15, further defining interactions between widgets on the same linkage graph.

19. The method of claim 18, wherein said interactions are selected from the group consisting of: data copy, data merge, data override, operational link, widgets swap, tagging, semantic grouping and shared action.

20. The method of claim 5, further comprising defining rules by which a trigger related with given state of an object invokes an action on a given widget.

21 . The method of claim 20, wherein the trigger is selected from the group consisting of: scheduler, software state and widget state.

22. The method of claim 20, wherein the action is selected from the group consisting of: visual changes to the widget, changes in widget content, widget operation and running code.

23. The method of claim 5, further comprising storing said widgets both locally and remotely.

24. The method of claim 23, wherein said local storage comprises one of:

DOM memory, 'pending' local store, 'modified' local store, 'deleted' local store, 'context' local store, 'personal' local store and 'utility' local store.

25. The method of claim 23, further comprising synchronizing between said local and remote stores.

26. The method of claim 5, further comprising storing said widgets in a personal remote storage means owned by the user.

27. A state-oriented sharing application for implementing a method of multi-dimensional state oriented interactive sharing of content in marked places set on top of internet assets, comprising: setting by the owner of an internet asset at least one marker widget on at least one specific location on the internet asset; selectively displaying the at least one marker widget on top of the internet asset; placing a content widget by a content owner in said at least one marker widget; and displaying the content widget on top of the internet asset in the set place.

28. The method of claim 27, wherein said internet asset is selected from the group consisting of: website, web application and mobile application.

29. The method of claim 27, wherein said selectively displaying comprises displaying by request.

30. The method of claim 27, wherein said marker widget comprises at least one state identifier and wherein said content widget is displayed selectively according to said state identifier.

31 . The method of claim 30, wherein said state identifier comprises at least one of place and time.

32. The method of claim 27, wherein said placing a content widget

comprises placing the content widget for a limited time.

33. A state-oriented sharing application for implementing a community based method of providing multi-dimensional state oriented interactive expert assistance to visitors of a website or online application, independent of the underlying website or application, comprising: placing at least one expert widget on the website or application view by one or more expert users to create or join an experts-network;

defining said experts as a peers group;

displaying an experts-toolbar widget on top of said website or application view; and

conducting an on-line session using collaboration widgets.

34. The method of claim 33, wherein said conducting an on-line session comprises:

sending by the user queries to the experts-network; and

distributing said queries among experts of said website.

35. The method of claim 33, wherein said conducting an on-line session comprises:

selecting by a user an expert from said experts toolbar widget, adding the user into the peers-group of the experts-widget related with the selected expert; and

using collaboration widgets and dashboard to exchange

information.

36. The method of claim 35, wherein the collaboration widgets are

selected from the group consisting of: chat widgets, co-browsing widgets and co-reading widgets.

37. A state-oriented sharing application for implementing a method of sharing information between a desktop resource on a remote device and user's device, comprising: providing a resource-proxy widget on the user's device for: connecting with the remote desktop; connecting with a remote instance of a resource-proxy widget that mediates the interaction with the desktop resource; checking the availability of the desktop resource on the remote device;

establishing connection with the desktop resource; and

establishing a data stream between the user's device and the desktop resource.

38. The method of claim 37, wherein said desktop resource comprises a file.

39. The method of claim 37, wherein said desktop resource comprises a peripheral device.

40. The method of claim 38, wherein establishing a data stream comprises reading from the file via a P2P data channel.

41 . The method of claim 38, wherein establishing a data stream comprises writing to the file via a P2P data channel.

42. The method of claim 37, wherein said resource-proxy widget holds only meta-data that refers to the resource on its original desktop.

43. The method of claim 37, wherein said connecting with the remote

desktop comprises using one of broadcasting technology and sharing desktop UID and address via shared DB.

44. The method of claim 37, further comprising setting said desktop

resources in the form of a mini-portal.

45. The method of claim 44, wherein said mini-portal comprises a user created layout with content found in files set on the desktop.

46. The method of claim 44, wherein said mini-portal is created using a portal-widget.

47. A state-oriented sharing application for implementing a method of creating and sharing a personal interactive portal on a user computer's desktop, solely from resources hosted on the desktop.

48. The method of claim 46, wherein said creating a personal interactive portal comprises: defining a new portal; designing a layout for arranging content; and selecting desktop resources to present in the layout.

49. The method of claim 47, wherein said resources comprise files.

50. A method of sharing widgets in the context of search engine results, comprising: defining search terms used for the search as state identifiers; and defining widgets to be shared according to said identified states.

51 . The method of claim 50, further comprising grouping two or more results into a virtual widget.

52. The method of claim 51 , wherein said virtual widget is stored in

relation with the same state identifiers.

53. The method of claim 50, wherein said search engine is a widgets search engine and wherein said search results are widgets.

54. The method of claim 51 , wherein using said virtual widget comprises comparing a URL saved with the virtual widget with URLs in the search results.