Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document introduces the W3C Multimodal Interaction Framework, and identifies the major components for multimodal systems. Each component represents a set of related functions. The framework identifies the markup languages used to describe information required by components and for data flowing among components. The W3C Multimodal Interaction Framework describes input and output modes widely used today and can be extended to include additional modes of user input and output as they become available.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C .
W3C's Multimodal Interaction Activity is developing specifications for extending the Web to support multiple modes of interaction. This document introduces a functional framework for multimodal interaction and is intended to provide a context for the specifications that comprise the W3C Multimodal Interaction Framework.
This document has been produced as part of the W3C Multimodal Interaction Activity, following the procedures set out for the W3C Process . The authors of this document are members of the Multimodal Interaction Working Group (W3C Members only ). This is a Royalty Free Working Group, as described in W3C's Current Patent Practice NOTE. Working Group participants are required to provide patent disclosures .
Please send comments about this document to the public mailing list<EMAIL_ADDRESS>(public archives ). To subscribe, send an email to www-multimodal-request@w3. org with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe).
A list of current W3C Recommendations and other technical documents including Working Drafts and Notes can be found at http://www.w3.org/TR/ .
The purpose of the W3C multimodal interaction framework is to identify and relate markup languages for multimodal interaction systems. The framework identifies the major components for every multimodal system. Each component represents a set of related functions. The framework identifies the markup languages used to describe information required by components and for data flowing among components.
The W3C Multimodal Interaction Framework describes input and output modes widely used today and can be extended to include additional modes of user input and output as they become available.
The multimodal interaction framework is not an architecture . The multimodal interaction framework is a level of abstraction above an architecture. An architecture indicates how components are allocated to hardware devices and the communication system enabling the hardware devices to communicate with each other. The W3C Multimodal Interaction Framework does not describe either how components are allocated to hardware devices or how the communication system enables the hardware devices to communicate. See Section 6 for descriptions of several example architectures consistent with the W3C multimodal interaction framework.
The Multimodal Interaction Framework is intended as a basis for developing multimodal applications in terms of markup, scripting, styling and other resources. The Framework will build upon a range of existing W3C markup languages together with the W3C Document Object Model (DOM). DOM defines interfaces whereby programs and scripts can dynamically access and update the content, structure and style of documents.
Figure 1 illustrates the basic components of the W3C multimodal interaction framework.
Human user — A user who enters input into the system and observes and hears information presented by the system. In this document, we will use the term "user" to refer to a human user. However, an automated user may replace the human user for testing purposes. For example, an automated "testing harness" may replace human users for regression testing to verify that changes to one component do not affect the user interface negatively.
Input — An interactive multimodal implementation will use multiple input modes such as audio, speech, handwriting, and keyboarding, and other input modes. The various modes of input will be described in Section 3.
Output — An interactive multimodal implementation will use one or more modes of output, such as speech, text, graphics, audio files, and animation. The various modes of output will be described in Section 4.
Interaction manager — The interaction manager is the logical component that coordinates data and manages execution flow from various input and output modality component interface objects. The input and output modality components are as described in Section 5.
The interaction manager maintains the interaction state and context of the application and responds to inputs from component interface objects and changes in the system and environment. The interaction manager then manages these changes and coordinates input and output across component interface objects. The Interaction manager is discussed in section 6.
In some architectures the interaction manager may be implemented as one single component. In other architectures the interaction manager may be treated as a composition of lesser components. Composition may be distributed across process and device boundaries.
Session component — The Session component (discussed in Section 7) provides an interface to the interaction manager to support state management, and temporary and persistent sessions for multimodal applications. This will be useful in the following scenarios but is not limited to these:
System and Environment component — This component enables the interaction manager to find out about and respond to changes in device capabilities, user preferences and environmental conditions. For example, which of the available modes, the user wishes to use — has the user muted audio input? The interaction manager may be interested in the width and height of the display, whether it supports color, and other capability and configuration information. For more information see Section 8
Figure 2 illustrates the various types of components within the input component.
Recognition component — Captures natural input from the user and translates the input into a form useful for later processing. The recognition component may use a grammar described by a grammar markup language. Example recognition components include:
Other input recognition components may include vision, sign language, DTMF, biometrics, tactile input, speaker verification, handwritten identification, and other input modes yet to be invented.
Interpretation component — May further process the results of recognition components. Each interpretation component identifies the "meaning" or "semantics" intended by the user. For example, many words that users utter such as "yes," "affirmative," "sure," and "I agree," could be represented as "yes."
Integration component — Combines the output from several interpretation components
Some or all of the functionality of this component could be implemented as part of the recognition, interpretation, or interaction components. For example, audio-visual speech recognition may integrate lip movement recognition and speech recognition as part of a lip reading component, as part of the speech recognition component, or integrated within a separate integration component. As another example, the two input modes of speaking and pointing are used in
"put that," (point to an object), "there," (point to a location)
and may be integrated within a separate integration component or may be integrated within the interaction manager component.
Information generated by other system components may be integrated with user input by the integration component. For example, a GPS system generates the current location of the user, or a banking application generates an overdraft to prohibit the user from making additional purchases.
The output for each interpretation component may be expressed using EMMA, a language for representing the semantics or meaning of data. Either the user or the system may create information that may be routed directly to the interaction manager without being encoded in EMMA. For example, audio is recorded for later replay or a sequence of keystrokes is captured during the creation of a macro.
Figure 3 illustrates the components within the output component.
Generation component — The generation component determines which output mode or modes will be used for presenting information from the interaction manager to the user. The generation component may select a single output mode or it may select complementary or supplementary modes. The "internal representation" language used to describe the output from the generation component is under discussion by the working group.
Information from the interaction manager may be routed directly to the appropriate rendering device without being encoded in an internal representation. For example, recorded audio is send directly to the audio system.
Styling component — This component adds information about how the information is "layed out." For example, the styling component for a display specifies how graphical objects are positioned on a canvas, while the styling component for audio may insert pauses and voice inflections into text which will be rendered by a speech synthesizer. Cascading Style Sheets (CSS) could be used to modify voice output.
Rendering component — The rendering component converts the information from the styling component into a format that is easily understood by the user. For example, a graphics rendering component rectangle displays a vector of points as a curved line, and a speech synthesis system converts text into synthesized voice.
Each of the output modes has both a styling and rendering component.
The voice styling component constructs text strings containing Speech Synthesis Markup Language tags describing how the words should be pronounced. This is converted to voice by the voice rendering component. The voice styling component may also select prerecorded audio files for replay by the voice rendering component.
The graphics styling component creates XHTML, XHTML Basic, or SVG markup tags describing how the graphics should be rendered. The graphics rendering component converts the output from the graphics styling component into graphics displayed to the user.
Other pairs of styling and rendering components are possible for other output modes. SMIL may be used for coordinated multimedia output.
This section describes how the input and output components of sections 3 and 4 are specified. In brief, input and output components of the user interface will be specified as DOM objects that expose interfaces pertaining to that object's functionality. This enables the modality objects to be accessed and manipulated in the interaction management environments described in section 6.
(The use of the term "object" in this section is intended in the sense of "object" as used in the Document Object Model, and is not intended to imply a particular class or object hierarchy.)
User interface components make their functionality available to interaction managers through a set of interfaces, and can be considered as receiving values from and returning values to the host environment. Here, values can be simple or complex types, and components can specify the location for binding the received data, perhaps using XPath, which is W3C's language for addressing parts of an XML document, and was originally designed to be used by both XSLT and XPointer. The set of interfaces will be built on DOM, and thereby provide an object model for realizing the functionality of a given modality.
The functionality of a user interface component can therefore usefully be encapsulated in a programming-language-independent manner into an object exposing the following kinds of features:
The DOM defines a platform-neutral and programming-language-neutral interface to documents, their structure and their content. The user interface objects extend this model by adding modality-specific interfaces. In this way, user interface objects can define abstract interfaces which are usable across different host environments.
In multimodal applications, multiple user interface components are controlled and coordinated individually by the interaction manager.
User interface objects should follow certain guidelines to integrate into the multimodal framework:
In general, the formalization of features into properties, methods and events should not be taken to imply that the manipulation of the interface can take place only in local DOM architectures. It is the intention of this design that modality interfaces should remain agnostic to component architectures where possible. So the object feature definitions should be considered as abstract indications of functionality, the uses of which will probably differ according to architectural considerations (for example property setting may take different forms, and implementation mechanisms for event dispatch and handling are not addressed here.)
Each user interface object will specify a set of interfaces in terms of properties, events and methods, using a formal interface definition language. Bindings into XML, ECMAScript and other programming languages will also be defined.
In addition to formal definition of markup and DOM interfaces, a description of the execution model of the user interface object will be defined, that is, the behaviour of the object when used. Further, a user interface object should also describe how it is controlled in different interaction management environments, for example, those which support:
As work proceeds on the definition of individual modality interfaces, sufficient commonality of features may be found such that it is desirable to standardize in some way those features across different modalities. As such, the MMI group will investigate the possibilities for establishing a set of common interfaces that may be shared among all relevant modalities
The interaction manager is a logical component. The interaction manager is contained in the host environment that hosts interface objects. Interface objects influence one another by interacting with the Host Environment. A host environment provides data management and flow control to its hosted interface objects. Some languages that may be candidates as Host Environment languages include SVG, XHTML (possibly XHTML+ XForms), and SMIL.
A Host Environment's hosted interface objects may range from the simple to the complex. Authors will be able to specify the interface object components through a mixture of markup, scripting, style sheets, or any other resources supported by their Host Environment's functionality. The Host Environment design makes possible architectures where the interface objects may each have their own thread of execution independent from context of the Host Environment. The design also supports each component communicating asynchronously with the Host Environment (however familiarity with synchronization primitives such as mutexes will not be required to successfully author multimodal documents).
In some architectures, it is possible to have a hierarchical composition of Host Environments similar in spirit to Russian nesting dolls. Different aspects of interaction management may be handled at different levels of the hierarchy. For example, "barge-in", where speech output is cut off on the basis of user input, is an interaction management mechanism that may handled by one lower level Environment that just hosts the basic speech input and speech output objects while a different higher level Host Environment coordinates the multimodal application. Hierarchical interaction management also enables the delegation of complex input tasks to lower levels of the hierarchy. As an example, a date dialog might encapsulate the necessary interaction management logic needed to produce appropriate tapered prompts, error handling, and other dialog constructs to eventually collect a valid date. This form of nesting enables the creation of hierarchical interaction management that reflects the task hierarchy within the overall application.
An important goal of the W3C Multimodal Interaction Framework is to provide a simplified approach for authoring multimodal applications whether on a single system/user or distributed across multiple systems/users. The framework is architecture neutral, and abstractly relies on passing messages between the various framework components. The session component provides a means to simplify the author's view of how resources are identified in terms of source and destination of such messages. The session component is particularly important for distributed applications involving more than one device and/or user. It hides the details of the resource naming schemes and protocols used and provides a high-level interface for requesting and releasing resources taking part in the session.
The session component can be used for replicating state across devices, or across processes within the same device. In a graphical interface scenario running on a hand held device coupled to a voice interface running in the network. The user can choose to navigate or enter data using the device keypad or using speech. When filling out a form, this gives two ways to update the field's value. The session provides a scope for the replication mechanism and provides a way to keep multiple modes in sync.
For certain applications the session is short lived. In theses cases the same session may last for a single page or for several pages as the user navigates through the application, for example when visiting a web site. This makes it practical to retain state information for the duration of the application. For applications that involve persistent sessions such as meeting rooms, multiplayer games, there is a need for session management, and a means to locate, join and leave such sessions.
In a distributed environment there are several ways to identify a resource. The session component provides a means to query descriptions of resources, including the type of the resource, what properties the resource has, and what interfaces it supports.
The following use case provides the basis of defining session component:
Devices with limited capability provide a good example of the importance of a session component. The sequential multimodality allows user to experience multiple modes but only one mode at a time. In such a scenario the user has to switch between modes to experience multiple modes. In an application where the user is filling out a form using voice as the input mode since voice is preferred/easier mode for providing input. After the user has provided the input the application saves the form fields in a session object and switches the mode to visual. In visual mode the application retrieves the values from session and uses the form fields for further processing. An example of such application would be Driving Directions application where the user provides source and destination using voice mode and then selects directions from visual mode to see the directions.
Form filling presents another use case for a session component. Especially when partial information is filled using the keypad attached to the device and partial information is filled using the speech processed at the speech server in the network. For example in an airline reservation system the user can provide date of travel by clicking on appropriate dates in the calendar and provide source and destination using speech which is processed in the network. A session component helps in synchronizing the input provided in either mode and provides filled form information back to the application.
The session in this case is persistent and users join/leave the session during the application. A session component allows a user to query the session environment. A session environment would consist of the resources and the values of the attributes in the resources. In case of meeting room application the user can query: i) who else is in the meeting room. ii) Get the information about a particular member in the meeting room e.g. contact information, whether the member is online etc.? The resources that application wants its user to share is stored and proper interfaces are provided to access the attributes of the resource.
For multimodal applications running across multiple devices, the session component can play an important role in the synchronization of state across the devices. For example a user may be running an application while sitting in a car using a device attached to the car. The user gets off the car and goes to his office and wants to continue with the application on his laptop that he was running in the car. The session component provides interfaces to save the state of the whole application on a device and reinstating the whole state on another device. The few examples of such applications could be video conferencing, online shopping, airline reservations etc. For example in an airline reservation system, the user selects the itinerary while he is still in the car. The user gets out of the car and buys the same ticket using his laptop in his office.
The W3C Multimodal Interaction Requirements call for the ability for developers to be able to create applications that dynamically adapt to changes in device capabilities, user preferences and environmental conditions. The multimodal interaction framework must allow the interaction manager to determine what information is available, as this will be system dependent. In addition, the framework must support stand-alone as well as distributed scenarios involving multiple devices and multiple users (see section 7 for more details).
It is expected that the system and environment component will make use of the work of the W3C Device Independence activity, in particular the CC/PP language, whose aim is to standardize ways of expressing device features and settings, and to describe how they are transmitted between components. Profiles regarding multimodal-specific properties, such as those listed below, are expected to be defined in accordance to the CC/PP Structure and Vocabularies specification.
To illustrate the components functionality it is worth considering the following few user case scenarios:
Mobile devices typically have limited capabilities and resources, so that applications need to be tailored to the specifics of the device. For example, many mobile phones have small monochrome displays, while others have rich, fast color displays. The following are typical characteristics of mobile devices that can be provided to the Interaction Manager through the System and Environment component:
Location information can be provided by an increasing number of mobile devices. Typically this information is derived from cell quadrant (cellular radio networks), GPS satellite data or dead reckoning based on motion sensors. The Location Interoperability Forum - now part of the Open Mobile Alliance — has been responsible for much of the work on this to date. Location-based services (LBS) provide time stamped location data of varying accuracy, in some circumstances, this can be to within a few meters. This information can be provided upon request at sub-second intervals. Multimodal applications can use such information to orient maps and to provide geographically relevant information.
Signal strength provides information on network connectivity as well as the quality of service that can be provided. As signal strength decreases a Multimodal application could adapt accordingly. This could be as simple as switching to an alternative low-bandwidth mode of communication.
Aural noise level for mobile devices is an important consideration because of the variety of situations where the device can be used, for example, noise from passing vehicles, other people talking nearby, or loud music. Speech recognition can be tailored based on noise levels returned by the System and Environment component.
Battery level provides information on the remaining operational time. Such a notification to the Interaction Manager is particularly revelant to small un-tethered devices where power consumption is critical.
Automotive — Multimodality is typically an on-board capability that senses the local environment to determine what services can be adapted to the drivers situation, for example:
Aural noise Level within the car can be generated and modified by numerous environmental factors for example driving with the windows down, radio volume, the AC/Fan on/off or windscreen wipers on/off. Environmental conditions of the vehicle, controlled by the driver, can be notified via the System Environment component to the Interaction Manager to adapt the speech recognition.
In gear notifications could provide information on the drivers ability to use a touch screen in a Multimodal application. In addition there are legal ramifications associated with the driver operating devices whilst the vehicle is in motion. Therefore the general behavior of a Multimodal application may need to adapt according to whether the vehicle is parked or "in-drive".
GPS notifications are an important feature of an on-board Multimodal navigation system. The update frequency and accuracy of updates being higher than typical LBS mobile services (see Mobile section).
Desktop — Multimodal applications can be tailored to the user's preferences. These choices can be dynamic or static for example:
Static user preferences — the default volume setting, the rate in words per minute for playing text to speech, a general preference to using speech rather than a keyboard. People with visual impairments may opt for easy to see large print text and high contrast color themes.
Dynamic preferences — the user may suddenly mute audio output, or switch from speech to pen input, and expect the application to adapt accordingly. The application itself may monitor's the user's progress, and react appropriately, for example, prompting the user to use a pen after successive failures with speech recognition.
The above examples give a general indication of the functionality that the System and Environment component offers as a means for enabling applications to be tailored to adapt to device capabilities, user preferences and environmental conditions.
Environmental conditions can be monitored and reported to to the Interaction Manager. One way to look at these characteristics is to inspect interference channels:
Auditory
Environment too noisy and bad for listening - the application should adapt to this change to provide a better experience.
A speaker system/headphone attached? A speaker system allows the user to see the screen as well as listen at the same time.
Car environment factors - radio on/off, radio volume, AC/Fan on/off, windscreen wipers on/off windows up/down.
Visual
Whether gesture recognition is possible. The user should be able to see the sensor for a gesture based application. Moreover, if the user cannot see the device then audio becomes the predominate mode of communication and the application adapt to it.
Tactile
Pen — large or small or finger begin used as a tactile input device.
System notifications can be derived from numerous environmental sources, particularly within mobile and automotive applications. Notifications from the System and Environment component to the Interaction Manger can range from GPS location information to the fact that the laptop has been closed. Many of these system notifications indicate that the application should switch to an alternative mode of operation.
User preferences help with tailoring the application to the user. These characteristics are most apparent in rich Multimodal scenarios such as the desktop where resources are less of an issue (large screens and fast CPU's). Preferences can be modified to best suit user choices. Furthermore, it is possible to dynamically adapt to the users preferences overtime.
To illustrate the component markup languages of the W3C Multimodal Interaction Framework, consider this simple use case. The human user points to a position on a displayed map and speaks: "What is the name of this place?" The multimodal interaction system responds by speaking "Lake Wobegon, Minnesota" and displays the text "Lake Wobegon, Minnesota" on the map. The following summarizes the actions of the relevant components of the W3C Multimodal Interaction Framework:
Human user — Points to a position on a map and says, "What is the name of this place?"
Speech recognition component — Recognizes the words "What is the name of this place?"
Mouse recognition component — Recognizes the x-y coordinates of the position to which the user pointed on a map.
Speech interpretation component — Converts the words "What is the name of this place?" into an internal notation.
Pointing interpretation component — Converts the x-y coordinates of the position to which the user pointed into an internal notation.
Integration component — Integrates the internal notation for the words "What is the name of this place?" with the internal notation for the x-y coordinates.
Interaction manager component — Stores the internal notation in the session object. Converts the request to a database request, submits the request to a database management system which returns the value of "Lake Wobegon, Minnesota". Add the response to the internal notation in the session object The interaction manager converts the response into an internal notation and sends the response to the generation component.
Generation component — Access the Environment component to determine that voice and graphics modes are available. Decides to present the result as two complementary modes, voice and graphics. The generation component sends internal notation representing "Lake Wobegon, Minnesota" to the voice styling component, and sends internal notation representing the location of Lake Wobegon, Minnesota on a map to the graphics styling component.
Voice styling component — Converts the internal notation representing "Lake Wobegon, Minnesota" into SSML.
Graphics styling component — Converts the internal notation representing the "Lake Wobegon, Minnesota" location on a map into HTML notation.
Voice rendering component: Converts the SSML notation into acoustic voice for the user to hear.
Graphics styling component: Converts the HTML notation into visual graphics for the user to see.
There are many possible multimodal architectures that are consistent with the W3C multimodal interaction framework. These multimodal architectures have the following properties:
Property 1. THE MULTIMODAL ARCHITECTURE CONTAINS A SUBSET OF THE COMPONENTS OF THE W3C MULTIMODAL INTERACTION FRAMEWORK. A multimedia architecture contains two or more output modes. A multimodal architecture contains two or more input modes.
Property 2. COMPONENTS MAY BE PARTITIONED AND COMBINED. The functions within a component may be partitioned into several modules within the architecture, and the functions within two or more components may be combined into a single module within the architecture.
Property 3. THE COMPONENTS ARE ALLOCATED TO HARDWARE DEVICES. If all components are allocated to the same hardware device, the architecture is said to be centralized architecture . For example, a PC containing all of the selected components has a centralized architecture. A client-server architecture consists of two types of devices, several client devices containing many of the input and output components, and the server which contains the remaining components. A distributed architecture consists of multiple types of devices connected by a communication system.
Property 4. THE COMMUNICATION SYSTEMS ARE SPECIFIED. Designers specify the protocols for exchanging messages among hardware devices.
Property 5. THE DIALOG MODEL IS SPECIFIED. Designers specify how modules are invoked and terminated, and how they interpret input to produce output.
The following examples illustrate architectures that conform to the W3C multimodal interaction framework.
In this example, the user wants to go to a specific address from his current location and while driving wants to take a detour to a local restaurant (The user does not know the restaurant address nor the name). The user initiates service via a button on his steering wheel and interacts with the system via the touch screen and speech.
Property 1. The driving architecture contains the components illustrated in Figure 4: a graphical display, map database, voice and touch input, speech output, local ASR, TTS Processing and GPS.
Property 2. No components are partitioned or combined with the possible exception of the integration and interaction manager components, and the generation and interaction components. There are two possible configurations, depending upon whether the integration component is stand alone or combined with the interaction manager component:
Information entered by the user may be encoded into EMMA (Extensible MultiModal Annotation Markup Language, formerly known as the Natural Language Semantic Markup Language) and combined by an integration component (shown within the dotted rectangle in Figure 4) which is separate from the interaction manager.
Information entered by the user may be recognized and interpreted and then routed directly to the interaction manager, which performs its own integration of user information
There are two possible configurations, depending upon whether the generation component is stand alone or combined with the interaction manager component:
Information from the interaction manager may be routed to the generation component, where multiple modes of output are generated and the appropriate synchronization control created.
Information may be be routed directly to the styling components and then on to the rendering components. In this case, the interaction manager does its own generation and synchronization.
Property 3. All components are allocated to a single client side hardware device onboard the car. In Figure 4, the client is illustrated by a pink box containing all of the components.
Property 4. No communication system is required in this centralized architecture.
Property 5. Dialog Model: The user wants to go to a specific address from his current location and while driving wants to take a detour to a local restaurant . (The user does not know the restaurant name or address.) The user initiates service via a button on his steering wheel and interacts with the system via the touch screen and speech.
The Name dialing example enables a user to initiate a call by saying the name of the person to be contacted. Visual and spoken dialogs are used to narrow the selection, and to allow an exchange of multimedia messages if the called person is unavailable. Call handling is determined by a script provided by the called person. The example supports the use of a combination of local and remote speech recognition.
Property 1: The architecture contains a subset of the components of the W3C Multimodal Interface Framework.
Property 2: No components have been partitioned or combined with the possible exception of the integration component and interaction component, and the generation component and the interaction component (as discussed in example 2).
Property 3. The components in pink are allocated to the client and the components in green are allocated to the server. Note that the speech recognition and interpretation components are on both client and server. The local ASR recognizes basic control commands based upon the ETSI DES/HF-00021 standardized command and control vocabulary, and the remote ASR recognizes names of individuals the user wishes to dial. (The vocabulary of names is too large to maintain on the client, so it is maintained on the server.)
Property 4. Communications system is SIP. SIP is a session initiation protocol and is a means for initiating communication sessions involving multiple devices, and for control signaling during such sessions.
Property 5. Navigational and control commands are recognized by the ASR on the client. When the user says "call John Smith," the ASR on the client recognizes the command "call" and transfers the following information ("John Smith") to the server for recognition. The application on the server then connects the user with John Smith's telephone.
In the Form fill-in example, the user wants to make a flight reservation with his mobile device while he is on the way to work. The user initiates the service by means of making a phone call to a multimodal service (telephone) or by selecting an application (portal environment metaphor). The dialogue between the user and the application is driven by a form-filling paradigm where the user provides input to fields such as "Travel Origin:", "Travel Destination:", "Leaving on date", "Returning on date". As the user selects each field in the application to enter information, the corresponding input constraints are activated to drive the recognition and interpretation of the user input.
Property 1: The architecture contains a subset of the components of the W3C Multimodal Interface Framework, including GPS and Ink.
Property 2: The speech recognition component has been partitioned into two components, one which will be placed on the client and the other on the server. The integration component and interaction component, and the generation component and the interaction component may be combined or left separate (as discussed in example 2).
Property 3. The components in pink are allocated to the client and the components in green are allocated to the server. Speech recognition is distributed between the client and the server, with the feature extraction on the client and the remaining speech recognition functions performed on the server.
Property 4. Communications system is SIP. SIP is a session initiation protocol and is a means for initiating communication sessions involving multiple devices, and for control signaling during such sessions.
Property 5. Dialog Model: The user wants to make a flight reservation with his mobile device while he is on the way to work. The user initiates the service via means of making a phone call to a multimodal service (telephone metaphor) or by selecting an application (portal environment metaphor). The dialogue between the user and the application is driven by a form-filling paradigm where the user provides input to fields such as "Travel Origin:", "Travel Destination:", "Leaving on date", "Returning on date". As the user selects each field in the application to enter information, the corresponding input constraints are activated to drive the recognition and interpretation of the user input. The capability of providing composite multimodal input is also examined, where input from multiple modalities is combined for the interpretation of the user's intent.


Description
- This fair, also on Vishuwat Sankranti day is held in the Shiva temple at Masi.
- It is a famous fair of Pali Pachhaun.
- Animals, specially bullocks and calves, are sold at this fair.
- On the same day a fair is held at Thal.
- In the summer the people in the valley of Ramganga (West), especially in Masi
and Bhikiasen, celebrate the unique machhli utsav (the fish festival).
- The villagers bearing tumra come with Jaal, fatyav and hathiya to the river to catch fish.
- The fish festival is locally known as Dahau.


Book
China
From $456.99
(8k Reviews)
Book
France
From $435.99
(15k Reviews)
Book
Egypt
From $756.99
(4k Reviews)
Book
Italy
From $658.99
(2.5k Reviews)
Book
Italy
From $640.99
(5k Reviews)
Book
Mexico
From $336.99
(3k Reviews)
Book
Brazil
From $389.99
(10k Reviews)
Book
Jordan
From $689.99
(900 Reviews)
Book
Peru
From $419.99
(1.5k Reviews)
Book
India
From $849.99
(5k Reviews)
Book
Greece
From $749.99
(2k Reviews)
Book
Goma, Democratic Republic of Congo
From $1209.99
(350 Reviews)


Continuum
A Next-Generation JavaScript (ES6) Virtual Machine Written in Last-Generation JavaScript (ES3)
View on Github


Javascript is disabled in your browser. You are missing out.
Enable javascript to use Pocket on the web.


This alpha test is primarily for mapping functions. This home page is under construction.


Kids, kids.  That only happens to bad people. Thank you, steal again. Our differences are only skin deep, but our sames go down to the bone. Look out, Itchy! He's Irish! What good is money if it can't inspire terror in your fellow man? Old people don't need companionship. They need to be isolated and studied so it can be determined what nutrients they have that might be extracted for our personal use.


Picking up:
agra
ahmedabad
bengaluru
chennai
hyderabad
jaipur
kolkata
lucknow
new delhi
mumbai
Dropping off:


Represents a Vigenère square initialized with a certain alphabet, to which strings can be passed for encryption or decryption.
More...
#include <vigenere_square.hpp>
Represents a Vigenère square initialized with a certain alphabet, to which strings can be passed for encryption or decryption.
◆ vigenere_square()
| vigenere_square::vigenere_square |
( |
const std::string & |
i_alphabet | ) |
|
Parametrized constructor. If i_alphabet contains duplicates, an exception is thrown.
- Parameters
-
| i_alphabet | String to represent available characters. |
- Exceptions
-
◆ decrypt()
| std::string vigenere_square::decrypt |
( |
const std::string & |
chipher, |
|
|
const std::string & |
key |
|
) |
| |
Decrypt a string using the vigenere_square instance's data member table.
- Parameters
-
| cipher | Reference to the string to be decrypted. |
| key | Reference to the key used in decryption. |
- Returns
- Decrypted string.
◆ encrypt()
| std::string vigenere_square::encrypt |
( |
const std::string & |
plaintext, |
|
|
const std::string & |
key |
|
) |
| |
Encrypt a string using the vigenere_square instance's data member table.
- Parameters
-
| plaintext | Reference to the string to be encrypted. |
| key | Reference to the key used in encryption. |
- Returns
- Encrypted string.
◆ operator=()
operator= overload. Copy assignment.
- Parameters
-
- Returns
- Reference to vigenere_square.
◆ print()
| void vigenere_square::print |
( |
std::ostream & |
os | ) |
const |
Print string representation to std::ostream.
- Parameters
-
| os | Reference to std::ostream. |
◆ to_string()
| std::string vigenere_square::to_string |
( |
| ) |
const |
String representation of the Vigenère table.
- Returns
- std::string.
The documentation for this class was generated from the following files:


Checkboxes & Radios
Default Checkboxes, styled with FontAwesome. You can use absolutely any icon and any color for checked option.
Modern Fields
These boxes will react to them when you type or select a value.
Email
(required)
Password
(required)
Website
(required)
Phone
(required)
Select a Value
Enter your Message
(required)
Minimalist Fields
These boxes will react to them when you type or select a value.
Email
(required)
Password: Minimum 8 Characters and 1 Number
(required)
Website
(required)
Phone
(required)
Select a Value
Enter your message
(required)
Select your Birthday
Range Sliders
Slide and increase or decrease their value.


#{extends 'main.html' /} #{set title:'We have just sent an email to '+existingOwner.userName /} #{set hasForm: true /}
We have just sent an email to #{user existingOwner/} on your behalf.


Write everything you want! The first step to make your dreams happen, it's by putting them on the paper, writing.
Don't get limited just with the letters! You can draw any kind of geometric form, since circles, squares, triangle till any form your mind is able to imagine.
One of the most cheapest tools in the world that has hundreds of utilities.
Recomended for: small companies
Recomended for: medium companies
Recomended for: big companies


Property
Edit Property
Remove Property
Add Property
Testimonial
Add
Remove
View
Edit
Users
Edit User
View User List
Add_User
Membership
Edit Membership
Remove Membership
Add Membership


Example 6.5.6.
Diego borrowed money at a 15% interest rate for 5 years, compounded daily. If they had to pay back $3000, how much did they borrow originally?
Diego borrowed money at a 15% interest rate for 5 years, compounded daily. If they had to pay back $3000, how much did they borrow originally?


General View Options
Each view offers the following options:
• File
• Close View closes the selected view.
• Print Setup displays print options.
• Print prints the selected view.
• Exit closes the view window.
• Edit clears the selection.
• View
• Displays a list of available views.
• Collapse collapses all levels in the view.
• Expand expands all levels in the view or expands a specified level (1st Level to 5th Level).
• Window
• Refresh updates the selected view if you make a change in a text view.
• Zoom enables you to zoom in or out, fit the view to the window, or reset the view.
• Displays all opened views.


Why Women 35+ Can’t Stop Raving About This Beauty-Enhancing
Pillowcase
Looking for THE Holy Grail product to help you unlock vibrant skin and strong, shiny hair?
What if I told you…
That the best-kept secret to flawless skin and hair isn't a supplement, serum or conditioner…
But sleeping on a luxuriously soft and smooth pillowcase?

And since you’re reading this — you probably are, too!
So you get my frustration with
skin
issues
like acne, wrinkles, and dryness…
No matter how many expensive skincare products I tried.

But it was so brittle and dry that I couldn't even run a brush through it!
This went on for years, until…
“You’re Not Still Sleeping on Cotton, Are You?”
Lydia was not only one of my closest friends…
But a WIDELY popular beauty influencer in her late 30s.
No wonder:
Her skin was gorgeous and glowing…
And her curly hair was simply spectacular.
One lazy Sunday brunch over a few Breakfast Margaritas…

See, though it was pretty, soft and comfy…
Because of its high friction, cotton pillowcases cause skin dryness, wrinkles and fine lines.
Plus, cotton takes away the natural oils from your hair — resulting in frizz, split ends and breakage.
“You have to switch to silk,” Lydia said matter-of-factly.
“But not just any brand out there.
Try Silky Cloud and you’ll NEVER look back.”
What’s So Special About These Silk Pillowcases?
Imagine resting your head on the most luxurious silk in the world each night…
(Like the Queen that you are!)
That’s exactly what Silk Cloud is.
Made of luxury 22-Momme (superior quality) 6A Mulberry silk…
Which is shinier, softer and stronger than any other silk in the world…
These pillowcases feel incredibly smooth and supple.
But there’s so much more to them…
Here’s What I LOVE About Silky Cloud…
And You Will, Too!
Here’s what I noticed after sleeping on Silky Cloud for a month:
-
No friction or skin irritation
-
Skin stays plump and hydrated
-
Less split ends and hair
-
Hair is easier to style
-
Better sleep thanks to its thermo-regulating properties
You’ll also love how they give your bedroom a touch of timeless sophistication…
While looking luxurious and feeling amazing on your skin.
Perfect for Maintaining Bed Hygiene
Mulberry silk is resistant to stains, odors, dust, mite and bacteria.
Plus, it’s hypoallergenic — so say goodbye to congestion, sneezing, itchy eyes and runny nose!
… So Easy to Take Care Of
If you’re thinking:
“Wow, this sounds GREAT, but isn’t silk high-maintenance?”
Not in this case.
Thanks to their superior 22-Momme quality and tight weave…
You can wash these pillowcases easily in your washing machine.
Also, they are more durable than cotton ones!

Check Out All the Love for Silky Cloud
Still on the fence? Don’t just take my word for it.
See what women like you are saying about Silky Cloud pillowcases.
"I used to sleep on a satin pillowcase, but learned that satin is only a polyester blend, so not great even though it SEEMS luxurious. This has been my first week sleeping on a Silk Cloud pillowcase, and I already see changes. My face is no longer oily when I wake up. It looks smoother and fresher."
— Brianna, 37
“My acne is under better control. I usually have pimples here and there sprouting (thanks, perimenopause!) but not since I switched to Silk Cloud! My hubby loves it, too! He says it’s like a hug for his face. 🤣🤣🤣 “
— Jessica, 42
“Thrilled to say my hair is more knot-free than ever. And I was a knotty mess! I have fine thin hair, and usually my hair gets clumpy and knotty easily…And looks kinda sad. But this silk pillowcase has allowed me to run my fingers through my hair - not just when I wake up, but throughout the day!"
— Katie, 50
"I've always been a hot sleeper, but since switching to a Silk Cloud pillowcase, I sleep much more comfortably. And my skin clearly loves it — it looks firmer, more hydrated and better overall!”
— Kelly, 39
A Beautiful And Practical Gift
Think Mulberry silk pillowcases are just for us ladies?
NOPE!
They are perfect for men, children, the elderly, hot sleepers, people with sensitive skin and hair-care concerns…

Pillowcases come in 6 classy colors that compliment every bedroom style…
And 3 different sizes (standard, queen and king).
Let’s Recap… Silky Cloud Pillowcases Are:
-
Made of premium Mulberry silk
-
Ultra Soft, Smooth and Skin-Friendly
-
Stylish & Luxurious
-
Natural Beauty and Sleep Enhancers
-
Easy to clean
-
Long-lasting
-
Perfect for traveling
-
A thoughtful gift for your loved ones
-
Available in 6 colors & 3 sizes
-
Hypoallergenic
-
Dust and mite resistant
-
Temperature regulating
A Beautiful And Practical Gift
By now, you’re probably asking how you can get your hands on Silky Cloud for yourself.
These pillowcases are sold directly by the manufacturer…
And are NOT available in retail stores.
But don’t worry — you can order them right HERE without leaving your home.
Because they cut out the middleman and pass on the savings directly to you…
You can enjoy the ultimate luxury and comfort of Silky Cloud pillowcases at an absolute BARGAIN.
The cool part?
The company that makes them has received such overwhelmingly positive feedback and raving reviews…
That each pillowcase comes with a 100% Satisfaction Guarantee.
If within 30 days of the purchase date, you're not head-over-heels for this silky goodness…
They’ll refund you every penny.
No questions asked.
The last time I checked, they were running an amazing deal.
Check out if you can still take them up on it!
EXCLUSIVE LIMITED-TIME OFFER
For a limited time only…
The manufacturer is offering 50% OFF + FREE FAST SHIPPING to all new customers.
But because of the high demand, rising inflation and supply chain issues…
This deal might be taken down any day now.
If you’re ready to reduce fine lines, wrinkles and hair frizz — all while enjoying a good night’s sleep…
These pillowcases are EXACTLY what you need.
Remember — you’re fully covered by their 100% Satisfaction Guarantee.
So, order Silky Cloud today with confidence — for yourself, your friends and your family.
Please check their site to see if stock is currently available.


OK I have put together my Emon TX shield and connected to my Arduino. I've followed the steps setting up the Arduino environment, I've downloaded all the Libraries listed,unzipped and put in a seperate folder name OEM, rather than the Arduino library as advised. I've then downloaded the Emon TX firmware, unzipped it and located it in the Arduino sketches folder. I've open the folder and opened the CT1234_voltage sketch, its opened ok and is also showing the additional tab labeled emonlib. I clicked the verify and its stops with the following error.
emonTxShield\Shield_CT1234_Voltage\Shield_CT1234_Voltage.ino:54:73: fatal error: JeeLib.h:
No such file or directory
#include <JeeLib.h> // make sure V12 (latest) is used if using RFM69CW
^
compilation terminated.
exit status 1
Error compiling.
I've tried google it seems others have come across this issue but I can't find the answer. I plan to use the setup for pv diversion and monitoring once I have the basics sorted. Im planning on using ethernet card and have no rf if that makes a difference.
Steve
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
Jeelib is a separate library which is required by the RFM12B and RF69 radio modules. Unless this one is in place, compilation will fail because the file JeeLib.h can't be found. You will need to download and install this library.
The attached copy is OK for my needs but may not be the latest version. The unzipped folder needs to sit alongside all the other main libraries. After installing it, the IDE needs to be closed for the change to take effect.
Hope this helps.
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
thanks for the response. I had already downloaded jeelib but have tried the link you suggested incase there was something different. I've unzipped the folder and placed it alongside my other librarys. I've restarted the IDE and opened the emox tx sketch, clicked verify and i'm getting the same error message. I've spent most the afternoon trying to get past this stage and am stuck.
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
see photo.
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
What version IDE have you installed?
If it is later than ~v1.6.2 you cannot use the additional level of folders. The abc.h and abc.ccp files and examples folder etc must be in sketchbook/libraries/abc as sketchbook/libraries/anythingelse/abc will fail to be located by the IDE.
Try moving one of your library folders from your "OEM" folder directly into the libraries folder to see if that works (restart of IDE required). You can confirm the lib is detected by checking if menu => Sketch => Include Library has the lib listed at the bottom (no need to select it just confirm if it's there or not)
Paul
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
pb66: You can confirm the lib is detected by checking if menu => Sketch => Include Library has the lib listed at the bottom (no need to select it just confirm if it's there or not)
Neat, I've never tried that one :-)
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
Hi Paul, thanks for the advise. I got to a point where I could see the the librarys under the library tab, but i was still getting the no jeelib.h file found error.
In the end I uninstalled Arduino and reinstalled version 1.0.5
Im still getting errors which I dont understand.
Am I even clicking on the correct sketch for what I require, i've been selectrion CT1,2,3,4_voltage? one also has nanodeRF, and one also says serial only? I am not using any RF I eventually want to plug a wifi shield in.
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
Just reading back through since I am not using any RF should it be trying to locate this file? Maybe the sketch I need to run is the serial only version?
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
It sounds like you could probably use a different sketch if you don't need JeeLib for RF, I'm not familiar with the emonLib examples or using the wi-fi shield so I won't comment on which sketch is the better for your needs.
The comments I made above are aimed at the very latest IDE versions as they have changed, if using 1.0.5 you can ignore pretty much all I said and the guides should work as they are tried and tested with the version you are using.
If you can see the Lib under the file => sketchbook => libraries menu and still it isn't found then the usual suspests are that the IDE hasn't been restarted since the libs appeared in the right location, this involves shutting down all instances of the IDE, if one remains open it will not reload the libs. Or the folder is not named correctly, from memory the JeeLib folder unzips with the name "jeelib-master" this must be renamed to "jeelib" or it will not be recognized as a lib even if the IDE(s) are restarted and also if there are more than one copy of jeelib "seen" by the IDE it will not list more than 1 but it will have difficulties using the lib, either it won't know which to use or possibly even try and use the wrong one which may not be valid.
Although you may not need jeelib the chances are you will need other libs at some point (wi-fi perhaps?) so cracking this will be useful, the only "quirk" with jeelib specifically is the downloaded folder name, also worth checking when you are unzipping that you are not adding a folder there and ending up with jeelib/jeelib-master/JeeLib.h etc it must be jeelib/JeeLib.h etc as in Robin's own version.
Paul
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
Last night, I downloaded Arduino V1.6.7 into a copy of Win 10 running on a virtual machine, and despite putting the libraries exactly where the Arduino documentation requires (which has changed since our guide was written, which was for V1.0.5), I too got exactly the same error message. So I am beginning to think that V1.6.7 is broken. I shall do some more investigation later today. Just for information, V1.0.5 is still the latest version in the Ubuntu software centre.
If you (saggers) are still having problems with libraries, Paul is correct and some do need the names changed. I think our guide shows the correct names.
Also, if you use a sketch that sends commands to the radio but you do not have a radio fitted, the sketch will hang at that point and lock up. So you need to use the 'serial only' version "Shield_CT1234_Voltage_SerialOnly". If you use (or convert) any other sketch, then you must remove all the radio commands.
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
I think I know what the problem is - a failure of the Arduino documentation. What is not made clear is the directory (folder) which it calls "Sketchbook" must be the parent of both the user's top level sketch directory and the "libraries" directory. This can be (but need not be) the "Arduino" directory.
This shows the structure you need for the libraries to be found:
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
Ah ha you are right the default folder name has changed, although the IDE always refers to it as "Sketchbook" the later version creates and uses the Arduino folder as it's "Sketchbook" where as earlier versions actually created and used a folder named Sketchbook for it's "Sketchbook" well spotted. That confuses things unnecessarily, not only from this angle but also from the fact that it is well established that the boards.txt, programmers.txt, bootloaders and avrdude files are usually all found under the "Arduino" directory.
It's worth noting in both cases the "Sketchbook" folder can be defined in the preferences. It may well be worth considering changing the preferences to Sketchbook and rename the Arduino "Sketchbook" folder to avoid future confusion, I think that is the route I will take.
And for clarification if you are using v1.0.5 it is likely to still be Sketchbook so this might not be the reason it can't find JeeLib.h.
Paul
Re: Problem whilst verifying Emon TX sketch on Arduino, fatal error: JeeLib.h: No such file or directory
I've never managed to understand the Arduino design mentality. Until the Arduino appeared (and everywhere else since as well) there's been a default location for libraries but it is perfectly permissible to put a library anywhere, provided its path is specified in the "include". This is why K&R distinguish between #include < ... > and #include " ... ". I've just rewritten the installation instructions. I've pointed out there that the "Sketchbook" directory is by default called "Arduino", but it can be a name of the user's choice. What HAS changed significantly is the relative positions in the hierarchy of "Sketchbook", the libraries and the user's sketches.


{% extends 'v2/layouts/layout-email.html' %} {% block pageTitle %} EMAIL {% endblock %} {% block content %}
We will let you know if they accept your invite.
Contact us or speak to your GP if you did not do this or someone is pressuring you to do this.


unity-technologies
Businessmodel of Unity Technologies
Customer Segments
Unity serves a large customers base comprising amateur and professional games designers across multiple platforms and devices. These customers can be organised into two core categories:
- Consumers, including students, hobbyists, and amateur game developers;
- Games Developers, including individual professionals, large games developers, independent studios, and software companies; and
- Other Companies and Organisations, including consumer goods companies, media houses, government agencies, and publishing companies. Unity serves a number of leading games developers, including Electronic Arts, Facepunch Studios, Juggernaut Games, Square Enix Montreal, Ubisoft, and Mografi. It also customers such as Coca Cola, LEGO, NASA, Nickelodeon, Warner Brothers, and Microsoft.
Unity is based in the US, which represents its key market. The Company, however, also serves a number of international clients across markets across north America more broadly, as well as in Europe and Asia Pacific.
Value Propositions
Unity provides value to its clients in the following ways:
- Its industry standing and reputation, with the Company established as a leading provider of gaming software, with its game engine the most popular third party development software in the world, utilised by leading games developers such as Electronic Arts, Square Enix, and Ubisoft;
- Its brand and intellectual properties, with the Company having developed a strong brand identity, and developing a range of proprietary technologies that make its software engine unique within the industry;
- Its diverse client base, with the Company serving a broad spectrum of clients, including individuals, independent developers, and large publishing houses across North America, Europe, and Asia Pacific;
- Its network of partners, with the Company working closely with a number of technology companies and platform operators – such as Android, Sony, iOS, and Windows – that make the Company’s software flexible and accessible to a broad range of clients; and
- Its industry expertise and experience, with the Company employing specialist software development personnel, as well as a team of experienced gaming and technology industry executives. ### Channels
Unity operates a website at www.unity3d.com, through which the Company provides information regarding its flagship game engine, its ancillary services, and its operating locations. The Company operates an online sales channel that allows customers to download software and set up subscriptions directly from the Company’s website. Unity additionally operates an online asset store, through which customers can purchase and download assets, environments, and architecture that can then be used in the development of games.
Unity sells its products and services to larger enterprises through a direct sales force that is organised across the Company’s operating regions. These sales personnel operate out of the Company’s sales and administrative offices across the US, Canada, Colombia, South Korea, China, Singapore, Japan, the UK, Denmark, Germany, France, Russia, Finland, Ukraine, and Lithuania. These sales teams can be contacted over the phone or through an online contact form.
Additionally, Unity markets and sells its products through a network of channel partners. This includes various resellers and sales across all of the Company’s operating regions.
Customer Relationships
Unity sells products to customers on a self-service basis through its website. This includes its free subscription to its Unity game engine platform, as well as its mid-range Plus and Pro packages, which customers are able to download without interacting directly with members of the Company’s sales and service personnel. The Company’s online asset store also operates on a self-service basis, with users able to make purchases independently.
Unity’s Enterprise subscription is available to larger commercial operators through the Company’s various sales teams. Unity’s sales personnel consult directly with these enterprise-level customers order to ensure that their solutions are scaled appropriately and, where possible, tailored to suit each individual client’s needs. The Company arranged custom subscription plans and pricing for each of these clients, seeking to establish long-term relationships.
Unity offers clients ongoing support services. Customers are able to contact the Company directly via email, in order to receive personalised assistance. The Company also operates an online support page, where customers can find answers to common questions, and access documentation and resources. Additionally, Unity operates a community portal, through which users can interact with one another, collaborate on projects and issues, and share ideas.
Unity maintains several social media accounts – including with Facebook, Twitter, Google+, LinkedIn, and YouTube – through which the Company interacts directly with clients and publishes company updates.
Key Activities
Unity is engaged in the design and development of games, applications, and related software. The Company’s flagship offering is a game engine platform designed to allow users to create games and interactive 2D, 3D, virtual reality, and augmented reality experiences. Unity additionally offers ancillary services and solutions relating to advertising, analytics, collaboration, cloud services, performance reporting, and productivity.
The Company principally serves large-scale game developers, independent studios, and software companies, as well as individual hobbyists and students, and commercial businesses. Unity is based in the US, which remains its core market, but also operates offices across markets across the Americas, Asia Pacific, and Europe.
Key Partners
Unity works in close collaboration with a network of partners and organisations, primarily form within the technology and gaming space. These partners can be organised broadly into the following categories:
- Supplier and Vendor Partners, including suppliers of services, technologies, and equipment that are utilised in the development and implementation of the Company’s software products and solutions;
- Channel and Distribution Partners, including the Company’s network of authorised resellers, distributors, and sales agents that assist in enhancing the Company’s in-house sales and marketing capabilities;
- Platform and Technology Partners, including various high-profile technology companies, software developers, and gaming software developers with which the Company develops integrations and joint products; and
- Strategic and Alliance Partners, including a number of high-profile companies, primarily within the technology and gaming industries, with which the Company collaborates on joint projects in branding, development, and marketing. Unity names a number of its partners on its website. This includes various high-profile gaming and technology companies, including Sony, Nintendo, Facebook, Google, Samsung, Microsoft, Intel, Qualcomm, and Oculus.
Key Resources
Unity’s key resources are its proprietary technologies, its products and flagship game engine, its IT and communications infrastructure, its sales and distribution channels, its network of partners, and its personnel.
Unity owns a number of intellectual properties that enable it to develop and provide unique and effective products. Searches of records published by the US Patent and Trademark Office identified several patent applications filed in Unity’s name, both as applicant and assignees, including applications entitled ‘System and method for managing game-playing experiences’, ‘Software development kit for capturing graphical image data’ and ‘System and method for managing game-playing experiences’.
Unity additionally owns and or leases a network of properties around the world that comprise its network of sales and administrative offices.
Cost Structure
Unity incurs costs in relation to the development of its technologies and products, the maintenance of its IT and communications infrastructure, the operation of its sales and distribution channels, the procurement of services and equipment, the management of its partnerships, the implementation of marketing and advertising campaigns, and the retention of its personnel.
Revenue Streams
Unity generates revenue through the development and sale of gaming software solutions and various related services. The Company principally derives revenue under subscriptions for its flagship game engine platform. It also derives revenue under individual sales contracts and through the sale of assets on it online asset store.
Unity remains a privately owned company, and as such is not obliged to disclose its financial results online. Research did not identify any recent reference to the Company’s annual revenue figures.


{% extends "layout.html" %} {% block head %}
| Type | Number | Example | Purchase |
| Leaderboard | Two | Click Here | Buy This |
| Type | Number | Example | Purchase |
| Box | Two | Click Here | Buy This |
| Type | Number | Example | Purchase |
| Leaderboard | One | Click Here | Buy This |
| Type | Number | Example | Purchase |
| Box | One | Click Here | Buy This |


|
DeviceClaimRK
|
Class for device claim library. More...
#include <DeviceClaimRK.h>
Public Types | |
| enum | Progress { Progress::IN_PROGRESS, Progress::FAILURE, Progress::DONE } |
| Result codes from getProgress() More... | |
Public Member Functions | |
| DeviceClaim () | |
| Constructor. Typically this object is created as a global object. | |
| virtual | ~DeviceClaim () |
| Destructor. Typically this object is created as a global object and thus never deleted. | |
| void | setup () |
| You must call this method from setup() | |
| void | loop () |
| You must call this method from loop();. | |
| void | forceClaim () |
| Force claiming again. More... | |
| DeviceClaim & | withEepromAddr (size_t eepromAddr) |
| Sets the address in virtual EEPROM where data is stored. The default is 1998. More... | |
| DeviceClaim & | withClaimEventName (const char *claimEventName) |
| Sets the event name to use to trigger claiming. More... | |
| DeviceClaim & | withTestEventName (const char *testEventName) |
| Sets the test name to use to test whether claiming worked. More... | |
| DeviceClaim & | withConnectWaitMs (unsigned long ms) |
| Sets the amount of time after connecting to the cloud to send the claim event. Default: 2000 ms. | |
| DeviceClaim & | waitClaimRequestWaitMs (unsigned long ms) |
| Sets the amount of time after sending the claim event before disconnecting. Default: 3000 ms. | |
| DeviceClaim & | withTestWaitMs (unsigned long ms) |
| Amount of time to wait for a test event response before declaring failure. Default: 10000 ms. More... | |
| Progress | getProgress () const |
| Gets the progress of the claiming. More... | |
| size_t | getEepromDataSize () const |
| Gets the size of the data stored at the specified EEPROM location. | |
| void | setFlag (uint16_t mask, bool value=true) |
| Set a flag value in the configuration data. More... | |
| bool | getFlag (uint16_t mask) const |
| Get a flag value in the configuration data. More... | |
| bool | isClaimed () const |
| Returns true if CONFIG_FLAG_CLAIMED flag bit is set in the configuration data. | |
| virtual bool | readConfigData (DeviceClaimConfigData *data, size_t dataSize) |
| Reads the configuration data out of EEPROM at address eepromAddr. More... | |
| virtual bool | writeConfigData (const DeviceClaimConfigData *data, size_t dataSize) |
| Writes the configuration data to EEPROM at address eepromAddr. More... | |
Static Public Attributes | |
| static const uint32_t | CONFIG_MAGIC = 0x750ca339 |
| Magic value stored in the DeviceClaimConfigData in EEPROM. | |
| static const uint16_t | CONFIG_FLAG_CLAIMED = 0x0001 |
| Bit in to indicate that claiming has been done. | |
Protected Types | |
| enum | State { State::START, State::CONNECT_WAIT, State::REQUEST_WAIT, State::DISCONNECT_WAIT, State::RECONNECT_WAIT, State::CHECK_CLAIM, State::CHECK_WAIT, State::FAILURE, State::DONE } |
| Finite state machine states. More... | |
Protected Member Functions | |
| void | subscriptionHandler (const char *eventName, const char *data) |
| Subscription handler for test event. More... | |
Protected Attributes | |
| size_t | eepromAddr = 1998 |
| Address to store the saved data. Must have 8 bytes available at this location see also withEepromAddr(), getEepromDataSize(). | |
| String | claimEventName = "deviceClaim" |
| Name of the event used to claim a device. See also withClaimEventName(). | |
| String | testEventName = "deviceTest" |
| Name of the event used to test claiming. See also withTestEventName(). | |
| DeviceClaimConfigData | configData |
| Data stored in the EEPROM (8 bytes) | |
| State | state = State::START |
| Current state of the finite state machine. | |
| unsigned long | stateTime = 0 |
| Timing information for some state transitions. | |
| unsigned long | connectWaitMs = 2000 |
| The amount of time after connecting to the cloud to send the claim event. See also withConnectWaitMs(). | |
| unsigned long | claimRequestWaitMs = 3000 |
| Sets the amount of time after sending the claim event before disconnecting. See also withClaimRequestWaitMs(). | |
| unsigned long | testWaitMs = 10000 |
| Amount of time to wait for a test event response before declaring failure. See also withTestWaitMs(). | |
Class for device claim library.
You typically allocate one of these as a global variable
|
strong |
Result codes from getProgress()
|
strongprotected |
Finite state machine states.
| void DeviceClaim::forceClaim | ( | ) |
Force claiming again.
If the device is already claimed it will succeed, however it uses 3K to 6K of data, so you probably don't want to do this unnecessarily. This will also retry after failure.
| bool DeviceClaim::getFlag | ( | uint16_t | mask | ) | const |
Get a flag value in the configuration data.
| mask | The mask bit to get. For example CONFIG_FLAG_CLAIMED. Mask should be a uint16_t with one bit set. |
| DeviceClaim::Progress DeviceClaim::getProgress | ( | ) | const |
Gets the progress of the claiming.
Returns one of the constants:
DeviceClaim::Progress::IN_PROGRESS
Claiming is in progressDeviceClaim::Progress::FAILURE
Claiming failed (the claiming event was sent, and the test event did not succeed)DeviceClaim::Progress::DONE
The device was either previously claimed, or it was just succeessfully claimed
|
virtual |
Reads the configuration data out of EEPROM at address eepromAddr.
This method is virtual so you can subclass this class and store the configuration somewhere else, for example your own EEPROM, Flash, FRAM, etc.. For custom storage methods you don't have to use eepromAddr and you can use your own logic instead.
| void DeviceClaim::setFlag | ( | uint16_t | mask, |
| bool | value = true |
||
| ) |
Set a flag value in the configuration data.
| mask | The mask bit to set. For example CONFIG_FLAG_CLAIMED. Mask should be a uint16_t with one bit set. |
| value | The value to set (true to set, or false to clear) |
|
protected |
Subscription handler for test event.
Note: This function will transition state from CHECK_WAIT to DONE when called.
|
inline |
Sets the event name to use to trigger claiming.
This must match the webhook that you set up to handle claiming. The default is "deviceClaim".
|
inline |
Sets the address in virtual EEPROM where data is stored. The default is 1998.
| eepromAddr | The address to save the data at. There must be 8 bytes available at this address. |
On Gen 2 devices (Electron and E Series), there are 2047 bytes of EEPROM. On Gen 3 devices (Boron), there are 4096 bytes of EEPROM.
You can use any available addresses that you are not already using in your application.
It's also possible to subclass this class to store the data elsewhere, such as in your own EEPROM, Flash, FRAM, etc.. See readConfigData.
The function getEepromDataSize() return the value of 8.
|
inline |
Sets the test name to use to test whether claiming worked.
This must match the webhook that you set up to handle claiming. The default is "deviceTest". Maxmium string length is 24 ASCII characters.
|
inline |
Amount of time to wait for a test event response before declaring failure. Default: 10000 ms.
This is a timeout value. Under normal circumstances the response is returned quicky indicating success and the end of this time limit is never reached.
|
virtual |
Writes the configuration data to EEPROM at address eepromAddr.
This method is virtual so you can subclass this class and store the configuration somewhere else, for example your own EEPROM, Flash, FRAM, etc.. For custom storage methods you don't have to use eepromAddr and you can use your own logic instead.


The four hundred men and women of the Blister Lane Cormorant Patrol brandished their pencil sharpeners, toffee apples, and inaccurate atlases as they reached the peak of the tor after marching all day. Below them, beyond the pig huts, the curiously-stained bridge, and the abandoned swimming baths, they were just able to see, shrouded in mist, the famous (or infamous) Wotan and Tantalum ponds, so dried up after successive droughts that they were now little more than puddles.
“Onwards!” cried Captain Federico ‘Gwyneth’ Paltrow, undisputed leader of the Cormorant Patrol and the man whose stupendous energy had helped it thrive even through such lean times. Seldom has a puny and diminutive physiognomy been so misleading.
And so began their descent. Three quarters of the way down, the newest recruit, fey young Daisy ‘Ricardo’ Montalban, stopped in her tracks, pointed, and yelled out: “Look! Look! Something with a beak and feathers!” And indeed, as they peered through the enshrouding mist, the others saw it too, perched on the branch of a withered pugton tree sprouting hopelessly on the banks of one of the ponds, or puddles. Excitedly, they began running, capering and gambolling down the muddy slope of the tor. But as they closed upon their prey, they realised it was not a cormorant at all. It was a little bittern.
Source : Forty-Six Bird-Related Adventure Stories by Vercingetorix Sepulveda (out of print)