INTERACTING TOYS

Abstract

Various embodiments include a toy comprising a processor; a memory for storing at least one group of data, each said at least one group comprising of a plurality of expressive responses, and each said group representing a respective theme; an output for said expressive responses; the toy being adapted to exchange such expressive responses with another such toy; an interface for receiving an instructive response from a user; and a suitably programmed processor and associated memory for altering the exchange of expressive responses between the toys in dependence upon the received user instructive response.

Description

CLAIM OF PRIORITY

This application claims the benefit of priority under 35 U.S.C. §119 of United Kingdom Patent Application Serial Number GB1222755.9, entitled “INTERACTING TOYS,” filed on Dec. 17, 2012, the benefit of priority of which is claimed hereby, and which is incorporated by reference herein in its entirety.

This invention relates to toys. In particular, although not exclusively, this invention relates to toys such as dolls that interact with each other. This invention also relates to an H-bridge circuit arrangement, which is particularly applicable, but by no means limited, for use in amplifiers for battery-powered devices, for which polarity protection is desired. The invention also relates to detecting potentially corrupt or otherwise invalid signals. The signals are signals such as audio signals. This invention also relates to an audio coding scheme.

Embedded computers and micro-processors have improved toys for children. They have been used most extensively in educational toys, but have also been used in interactive toys. ActiMates® Barney® is one example of an interactive toy which responds to interaction from a child by appropriate vocalisations, and can sing-a-long to videos.

User-Doll Interactions

According to one aspect of the invention, there is provided a toy comprising: a processor; a memory for storing at least one group of data, each said at least one group comprising of a plurality of expressive responses, and each said group representing a respective theme; an output for said expressive responses; the toy being adapted to exchange such expressive responses with another such toy; means for receiving an instructive response from a user; and means for altering the exchange of expressive responses between the toys in dependence upon the received user instructive response.

The toy may be adapted to receive an instructive response during the exchange of expressive responses, and the means for altering the exchange of expressive responses may alter the subsequent exchange of expressive responses. Preferably at least one expressive response includes a query. Preferably the query is addressed to the user.

The toy may be adapted to await an instructive response from a user following output of a query. Preferably the toy is adapted to await the instructive response for a predetermined period. Preferably the toy is adapted to continue to exchange expressive responses with the other such toy in the absence of an instructive response within the predetermined period.

The toy may be adapted to exchange expressive responses representing a respective theme in dependence on the instructive response from the user.

The toy may comprise means for receiving an instructive response from a user. Preferably the means is at least one of: a button; a remote control; a touch screen; and a linked computing device.

According to another aspect of the invention, there is provided a method of communication between first and second toys comprising: storing at least one group of data on each toy, each said at least one group comprising of a plurality of expressive responses, and each said group representing a respective theme; exchanging expressive responses between first and second toys; receiving an instructive response from a user; and altering the exchange of expressive responses between the toys in dependence upon the received user instructive response.

Name Files

According to another aspect of the invention, there is provided a toy adapted to interact with another such toy, the toy comprising: a processor; a memory for storing audio data; an output for outputting said audio data; means for receiving an identifier from the other such toy; and means for downloading audio data relating to said identifier for subsequent output by the toy.

The audio data relating to said identifier may include audio data specific to that other toy. Preferably the specific audio data includes any one or more of the following types of personal data relating to that other toy: its name; place of birth; home town; a hobby or interest; and favourite colour or food. The identifier may identify any one or more of the following variables relating to that other toy: the specific toy; a name; place of birth; home town; a hobby or interest; and favourite colour or food. Audio data may be in a specific form dependent on an audio output setting of the toy. Preferably the audio output setting is user selectable, and more preferably the audio output setting is a user selectable voice. Yet more preferably all audio data output by the toy is in the selectable voice. All audio data stored by the toy may be in the selectable voice. Preferably the audio data relating to said identifier is in the selectable voice.

The toy may be adapted to be connectable to a server thereby to download said audio data relating to said identifier from the server. Preferably said identifier is stored in the toy memory. Said audio data relating to said identifier may be associated with the identifier on the server.

Said audio data relating to said identifier may be associated with and/or linked to the identifier in the toy memory.

The toy may exchange identifiers with the other such toy when it comes into contact with the other toy. The toy may comprise means for transmitting an identifier relating to the toy to another such toy. The toy may further comprise means for modifying the audio data output to the other toy in dependence on whether or not the toy has stored thereon the audio data relating to said identifier for the other toy.

Preferably the audio data is in the form of expressive responses adapted to be exchanged between the toys. More preferably the sequence of the expressive responses is adapted in dependence on whether or not the toy has stored thereon the audio data relating to said identifier for the other toy. An expressive response may be selected in dependence on whether or not the toy has stored thereon the audio data relating to said identifier for the other toy.

The toy may further comprise means for initializing the toy with particular personal data associated with the toy. The toy may further comprise means for determining whether audio data relating to the received identifier is already stored in the toy memory. The toy may further comprise means for determining whether the received identifier is already stored in the toy memory. Preferably if the received identifier is not stored, then the identifier is added to the memory for subsequent request of audio data relating to the identifier. Preferably upon receipt of audio data corresponding to an identifier the identifier is deleted.

The means for storing audio data may be adapted to store a predetermined maximum quantity of audio data file relating to a predetermined maximum number of identifiers.

The processor may be adapted to store audio data corresponding to an identifier of the toy itself. The processor may be adapted to prevent deletion of the audio data corresponding to an identifier of the toy itself.

Preferably the toy is a doll.

According to further aspect of the invention, there is provided a system for providing audio data to interacting toys, the system comprising: a server for storing identifiers corresponding to each of the toys, and audio data relating to said identifiers; a plurality of toys adapted to interact with one another and exchange identifiers when coming into contact with one another; and wherein the toys are adapted to download from the server the audio data related to the identifiers for subsequent output by each of the toys.

Each toy may be provided with an audio output setting, and the audio data downloaded to a toy may be related both to the audio output setting of that toy and the identifier of another toy.

The system may further comprise means for storing the audio data relating to a said identifier in a plurality of audio data files, each one of said plurality of audio data files corresponding to a respective audio output setting.

According to further aspect of the invention, there is provided a method of communication between first and second toys, the method comprising: exchanging identifiers between the toys; and downloading audio data relating to said identifiers for subsequent output by the toys.

Personality Fitting—Role Selection

According to further aspect of the invention, there is provided a toy adapted to interact with at least another such toy, the toy comprising: a memory for storing at least one group of data, each said at least one group of data comprising a plurality of expressive responses, and each said group representing a respective theme; an output for said expressive responses, the toy being adapted to exchange such expressive responses with other such toys; and means for selecting certain of the expressive responses in dependence on a personality parameter associated with the toy.

The plurality of expressive responses in each said group of data may be grouped together to define predetermined character roles within the theme, and the selecting means may be adapted to select a particular role in dependence on the personality parameter, and preferably the expressive responses are grouped together to define the predetermined roles via role identifiers.

The personality parameter may be a compound parameter consisting of a plurality of personality trait parameters. Preferably the compound parameter consists of between 1 and 15 personality trait parameters, preferably between 3 and 12 personality trait parameters, and more preferably 8 personality trait parameters. Preferably each personality trait parameter is a variable defining the level of said personality trait parameter, and preferably said level is selectable and/or adjustable by a user. The personality parameter may be user-defined.

Each role may be provided with an associated personality parameter, and the selecting means may be adapted to compare each of the role personality parameters in the theme with the toy's personality parameter and to select a role that matches the toy's personality parameter most closely.

Personality Fitting—Authoring Tool

According to yet a further aspect of the invention, there is provided an authoring tool for creating themed data for toys, comprising means for receiving content relating to a particular theme; means for associating at least a part of the content with a personality parameter; means for processing said content to generate a set of instructions for operating said toy within said particular theme; and means for outputting said set of instructions.

The content may be in the form of a plurality of expressive responses grouped together to define predetermined roles within a theme, and a personality parameter may be assigned to each role.

The personality parameter may be a compound parameter consisting of a plurality of personality trait parameters. Preferably the compound parameter consists of between 1 and 15 personality trait parameters, more preferably between 3 and 12 personality trait parameters, and yet more preferably 8 personality trait parameters.

Script Importation—Authoring Tool

According to another aspect of the invention, there is provided an authoring tool for creating themed data for toys, comprising means for receiving content in the form of a scripted dialogue relating to a particular theme; means for processing said content to generate a set of instructions for operating said toy within said particular theme; and means for outputting said set of instructions.

The authoring tool may further comprise means for providing a plurality of user selectable content elements, and means for receiving a user selection of at least one of said content elements thereby to create said scripted dialogue.

The authoring tool may further comprise a graphical user interface, and wherein the content elements are provided in the form of user selectable graphical indicia. Preferably the graphical user interface comprises a storyboard on to which content elements (optionally) in the form of expressive responses can be dragged and dropped. Preferably the storyboard comprises a plurality of panels. Preferably at least one panel comprises means for setting the theme and/or at least one character. Preferably at least one panel provides a placeholder for a content item (preferably an expressive response) associated with a character, and wherein the authoring tool is adapted to receive a user-selected expressive response and replace the placeholder with the user-selected expressive response.

The authoring tool may be adapted to provide a plurality of potential expressive responses for user selection. Preferably the authoring tool is adapted to provide a plurality of potential expressive responses in dependence on at least one of: the panel; the theme setting; the character; and prior user-selected expressive responses.

The plurality of potential expressive responses provided may be filtered in dependence on at least one of: the panel; the setting; a character; a user-selected expressive response.

The authoring tool may be adapted to receive a user input and adapt at least one of the potential expressive responses to comprise the user input.

According to another aspect of the invention, there is provided a method of creating themed data for toys, comprising receiving content in the form of a scripted dialogue relating to a particular theme; processing said content to generate a set of instructions for operating said toy within said particular theme; and outputting said set of instructions.

The method may further comprise providing a plurality of user selectable content elements, and receiving a user selection of at least one of said content elements thereby to create said scripted dialogue. Preferably the user selectable content elements are selected via a graphical user interface. Preferably the content element is at least one of: an expressive response; a role; a number of participating roles; a theme; and a topic.

According to another aspect of the invention, there is provided an apparatus for creating themed data for toys, comprising means for receiving content in the form of a scripted dialogue relating to a particular theme; means for processing said content to generate a set of instructions for operating said toy within said particular theme; and means for outputting said set of instructions.

The apparatus may further comprise means for providing a plurality of user selectable content elements, and means for receiving a user selection of at least one of said content elements thereby to create said scripted dialogue. Preferably the apparatus further comprises a graphical user interface, and preferably the content elements are provided in the form of user selectable graphical indicia.

Conditional Flow—Authoring Tool

According to another aspect of the invention, there is provided an authoring tool for creating themed data for toys, comprising means for receiving content relating to a particular theme; means for processing said content to generate a plurality of different conversations each based on a set of expressive responses relating to a theme, wherein the conversations vary in dependence on a conversation condition; means for generating a set of instructions for operating said toys within said particular theme; and means for outputting said set of instructions.

The conversation condition may be at least one or more of the following: the nature or type of toy; a character role within the theme; the nature and/or type of theme; an attribute of the toy; a prior conversation sequence; a dialogue parameter; and a personality parameter associates with the toy and/or a character role within the theme. Preferably the conversation condition relates to the number of toys or character roles participating in the conversation. Preferably the conversation is tested in a pre-determined sequence for each of a plurality of toys or character roles.

Audio Synthesis—Authoring Tool

According to another aspect of the invention, there is provided a method of creating themed data for toys, comprising receiving content in the form of a scripted dialogue relating to a particular theme; processing said content to generate a set of instructions for operating said toy within said particular theme; and outputting said set of instructions.

According to another aspect of the invention, there is provided apparatus for creating themed data for toys, comprising means for receiving content in the form of a scripted dialogue relating to a particular theme; means for processing said content to generate a set of instructions for operating said toy within said particular theme; and means for outputting said set of instructions. According to another aspect of the invention, there is provided an authoring tool for creating themed data for toys, comprising means for receiving content relating to a particular theme; means for processing said content to generate a set of instructions for operating said toy within said particular theme; means for synthesising audio data relating to said content; and means for outputting said set of instructions.

Preferably the synthesising means is adapted to synthesis audio output in a plurality of synthetic voices.

Various aspects of the above inventions also provide the following functionality/advantages:

• • A simplified authoring tool for creating themed data for toys.
  • Arithmetic capability: a toy comprising: a processor; a memory coupled to said processor; and an output coupled to said processor, wherein said processor includes means for performing arithmetic operations (preferably addition, subtraction, multiplication, and/or division).
  • Voice modulation: phrase versions in different audio files; or alternatively a doll with the capability of volume modulation and/or volume control.
  • A toy or device that connects to a web site and contributes to a point score table (leader board).

Communication Interface

According to another aspect of the invention, there is provided a communication interface for connecting a toy with a remote server, comprising means for detecting the toy; means for receiving an identification which identifies the toy; means for forwarding the identification on to the remote server; and means for transferring data between the remote server and the toy.

The communication interface may be adapted to execute on a computing device. Preferably the communication interface is adapted to execute as a background process on the computing device. Preferably the communication interface is adapted to run in the notification area or system tray.

The communication interface may be adapted to synchronise data stored on the toy with data associated with the toy and stored on the server.

The server may include a website.

The communication interface may be adapted to receive from the server an indication of whether the toy is legitimate in response to forwarding the identification. The communication interface may be adapted to receive from the server an indication of whether the toy is registered at the server in response to forwarding the identification. Preferably the communication interface is adapted to initiate registration if the toy is not registered at the server.

The identification may include a user identifier and a toy identifier. Preferably the communication interface is adapted to receive from the server an indication of whether the toy is registered to the user at the server in response to forwarding the user identifier and toy identifier.

The communication interface may be adapted to receive toy characteristics data from the toy and forward the toy characteristics data on to the remote server. Preferably the toy characteristics data includes data relating to one, some, or all of the following: conversation participation count; count of instances of undertaking a particular activity; and count of instances of speaking a particular phrase. Preferably the toy characteristics data includes identifiers of required data, more preferably identifiers of required audio data, required variable audio data, required name audio data, and/or references to required themed data. The communication interface may be adapted to forward the identifiers of required data to the server, receive the required data, and dispatch the required data to the toy.

The communication interface may be adapted to receive toy settings from the server, receive toy settings from the toy, determine whether there is a difference, and if there is a difference then dispatch the updated toy settings to the toy. Preferably the communication interface is adapted to receive a toy settings update from a user input and forward the toy settings update on to the remote server. Preferably the toy settings include data relating to one, some, or all of: a toy name; a toy variable; a toy personality; and a toy voice.

H Bridge Circuit Arrangement

Polarity is defined herein as the orientation in which a power supply is connected to a circuit. In many electrical devices there is a correct polarity and an incorrect polarity. If a power supply is connected incorrectly, the device may not operate correctly, or circuit elements could become damaged. For example, a user may connect a DC battery with opposite/incorrect polarity (i.e. the battery is installed the wrong way round). Alternatively the user may connect an alternating current (AC) power source instead of a direct current (DC) power source, resulting in the AC current source providing undesirable current of opposite polarity for half the AC cycle.

To guard against the problems associated with power supplies of incorrect polarity, existing electrical devices often simply include one or more diodes in the circuit to stop current from flowing in the wrong direction. The use of diodes has a number of disadvantages. Firstly, a diode always consumes some power, even during correct operation of the circuit. In battery powered devices, this can lead to shortened battery life or reduced performance of the device. Furthermore, if the user connects an AC power source instead of a DC source, the device may show some signs of operation, but the circuitry may become damaged by the reverse-polarity component of the AC power.

An alternative solution addressing at least some of the above-mentioned problems is therefore needed.

According to a further aspect of the invention, there is provided an H-bridge circuit arrangement comprising: a pair of bipolar transistors and a pair of field-effect transistors (FETs), arranged such that each side of the H-bridge comprises a bipolar transistor and a field-effect transistor; and a pair of reverse-biased diodes, each of the reverse-biased diodes being connected between the base of a respective one of the bipolar transistors and signal ground; such that, in the event of a given bipolar transistor being subjected to polarity reversal, its base potential is substantially the same as its emitter potential such that it does not come into a state of conduction.

This asymmetrical “hybrid” arrangement, including the reverse-biased diodes, provides the advantage that, if the power supply to the H-bridge is reversed, the bipolar transistors do not turn on, and the H-bridge circuit is thereby protected.

Preferably, on each side of the H-bridge, the collector of the bipolar transistor is connected to the drain of the accompanying field-effect transistor.

In a presently-preferred embodiment, the bipolar transistors are PNP bipolar transistors and/or the field-effect transistors are MOSFETs. Other bipolar and field-effect transistor types are possible, though, as those skilled in the art will appreciate.

The circuit arrangement may further comprise a power supply arranged to supply power to the H-bridge. Preferably no diode is provided between the power supply and the H-bridge, thereby avoiding an undesirable voltage drop (across such a diode) and consequently lost electrical energy. Instead, an inductor may be connected between the power supply and the H-bridge.

The power supply may be a (DC) battery, to supply (ideally) a constant DC voltage.

Heartbeat

Audio signals are commonly encoded, compressed, transmitted, decoded, stored and have various other processes performed on them prior to actual playback. These processes are often necessary to facilitate transmission and subsequent playback, or to save space on the audio playing device. In any digital or analogue audio processing, there is a chance of the signal becoming corrupted due to errors propagating; for example the encoding and decoding processes not being exactly inverse, the compression removing important data, or data loss during storage.

Countermeasures to this include simply repeating the signal so that the probability of the same error appearing in all repetitions is very low. This is inefficient as it multiplies the amount of data by at least two. A more advanced countermeasure is to introduce a ‘checksum’ into the data stream, produced by code such as a Cyclic Redundancy Check (CRC). This is a data segment which is derived from the original (correct) data. The receiver uses the same algorithm to generate a checksum on the received data and thus can determine if the data has become corrupted. This can be a processor-intensive process, and may not suit situations where the processing power is limited or the size of data is particularly large. Furthermore, if the checksum itself is corrupted, the receiver may incorrectly assume the data stream itself as being corrupted.

An alternative solution to detecting corruption in a signal, avoiding at least some of the potential disadvantages with the prior art, would be advantageous.

According to another aspect of the invention, there is provided a method of processing a signal, the method comprising:

• • periodically adding a characteristic signal into a first signal, thereby creating an augmented signal;
    (optionally) encoding the augmented signal;
    (optionally) decoding the augmented signal;
  • sampling the (decoded) augmented signal for a sampling period greater than the period of the characteristic signal; and
  • determining the presence of the characteristic signal in the (decoded) augmented signal, the presence of the characteristic signal in the (decoded) augmented signal indicating that the augmented signal has not been corrupted and/or is from an authentic source.

The characteristic signal may be of the form of a narrow pulse or spike. Preferably the period of the characteristic signal is between every 200 and 2000 samples of the first signal, preferably every 1000 samples.

The sampling period may be at least twice the period of the characteristic signal in the augmented signal.

The first signal may have an amplitude less than a threshold value and the characteristic signal may have an amplitude greater than said threshold value. Preferably determining the presence of the characteristic signal comprises monitoring the decoded signal for amplitude deviations above said threshold value.

The first signal may be an audio signal. Preferably the method further comprises muting an audio output if the characteristic signal is not found in the sampling period.

According to another aspect of the invention, there is provided a method of processing a decoded signal, the method comprising: sampling the decoded signal for a predetermined sampling period; and determining the presence of a periodic characteristic signal in the decoded signal, the presence of the characteristic signal indicating that the decoded signal has not been corrupted and/or is from an authentic source.

The characteristic signal may be of the form of a narrow pulse or spike.

The step of determining the presence of the characteristic signal may comprise monitoring the decoded signal for amplitude deviations above a predefined level.

Preferably the decoded signal is an audio signal, and more preferably the method further comprises muting an audio output if the characteristic signal is not found in the sampling period.

According to another aspect of the invention, there is provided a method of processing a decoded signal, the method comprising:

• • analysing the frequency spectrum of the decoded signal; and
  • determining the presence of a periodic characteristic signal in the decoded signal, the presence of the characteristic signal indicating that the decoded signal has not been corrupted and/or is from an authentic source.

According to another aspect of the invention, there is provided a method of encoding a signal, the method comprising:

• • receiving a first signal;
  • periodically adding a characteristic signal into the first signal, thereby creating an augmented signal; and
  • encoding the augmented signal.

The characteristic signal may be of the form of a narrow pulse or spike. Preferably the period of the characteristic signal is between every 200 and 2000 samples of the signal, more preferably 1000 samples.

The first signal may have an amplitude less than a threshold value and the characteristic signal may have an amplitude greater than said threshold value. The first signal is preferably an audio signal.

According to another aspect of the invention, there is provided a signal produced in accordance with the method described above.

According to another aspect of the invention, there is provided apparatus for processing a decoded signal, the apparatus comprising:

• • means for sampling the decoded signal for a predetermined sampling period; and
  • means for determining the presence of a periodic characteristic signal in the decoded signal, the presence of the characteristic signal indicating that the decoded signal has not been corrupted and/or is from an authentic source.

The means for determining the presence of a periodic characteristic signal may comprise means for monitoring the decoded signal for amplitude deviations above a predefined level. Preferably an output is halted if no characteristic signal is determined within said predetermined sampling period.

The predetermined sampling period may be defined by a specific number of signal samples being sampled. Preferably the number of samples is between 500 and 5000, preferably between 1000 and 3000, and even more preferably 2000.

The apparatus is preferably a toy.

According to another aspect of the invention, there is provided apparatus for processing a decoded signal, the apparatus comprising:

• • means for analysing the frequency spectrum of the decoded signal; and
  • means for determining the presence of a periodic characteristic signal in the decoded signal, the presence of the characteristic signal indicating that the decoded signal has not been corrupted and/or is from an authentic source.

According to another aspect of the invention, there is provided apparatus for encoding a signal, the apparatus comprising:

• • means for receiving a first signal; and
  • means for periodically adding a characteristic signal into the first signal, thereby creating an augmented signal.

The characteristic signal may be of the form of a narrow pulse or spike. Preferably the period of the characteristic signal is between every 200 and 2000 samples of the signal, preferably 1000 samples.

The apparatus may be configured to add the characteristic signal such that it has an amplitude greater than a threshold value, the amplitude of the first signal being less than the threshold value.

According to another aspect of the invention, there is provided a system for processing a signal, the system comprising:

• • means for periodically adding a characteristic signal into a first signal, thereby creating an augmented signal;
    (optionally comprising) means for encoding the augmented signal;
    (optionally comprising) means for decoding the augmented signal;
  • means for sampling the decoded signal for a sampling period greater than the period of the characteristic signal; and
  • means for determining the presence of the characteristic signal in the (decoded) augmented signal, the presence of the characteristic signal in the (decoded) augmented signal indicating that the augmented signal has not been corrupted and/or is from an authentic source.

The characteristic signal may be of the form of a narrow pulse or spike. Preferably the period of the characteristic signal is between every 200 and 2000 samples of the first signal, preferably every 1000 samples. The sampling period may be at least twice the period of the characteristic signal in the augmented signal.

The first signal may have an amplitude less than a threshold value and the characteristic signal may have an amplitude greater than said threshold value. Preferably the means for determining the presence of the characteristic signal comprise means for monitoring the decoded signal for amplitude deviations above said threshold value.

The first signal may be an audio signal, and the system is preferably arranged to mute an audio output if the characteristic signal is not found in the sampling period.

Overlay Buffer

Devices which process data in order to perform specific tasks invariably have a limited processor size; therefore, the overall operation of the device is often limited by the amount of Random Access Memory (RAM) associated with the processor. Processors with large amounts of RAM are generally more expensive than their smaller counterparts, and also tend to consume a larger amount of energy. Thus, for applications with limited battery life, or devices where cost is critical, processors with large RAM components are often not practical.

In standard non OS computers (for example flash drives) where RAM is limited, the compiler and linker control the memory map, and re-use of RAM is performed by ‘Last-in-first-out’ (LIFO) using the ‘stack’ mechanism. This mechanism can easily crash due to a ‘stack overflow’ where there is not enough RAM to be shared between competing tasks.

Therefore there is a need to improve the performance of devices with limited RAM without changing the hardware involved.

According to another aspect of the invention, there is provided a memory controller for allocating Random Access Memory (RAM), the controller comprising: means for allocating a portion of the available RAM to a first group of processing tasks; means for allocating the same portion of RAM to a second group of processing tasks; wherein the first group of processing tasks comprises write/erase tasks and the second group of processing tasks comprises decode/read tasks; and wherein the memory controller is adapted to control the tasks so that they are mutually exclusive.

The controller may be adapted to control the processing tasks so that the first group of processing tasks takes priority over the second group of processing tasks. Preferably the memory controller of claim 144 or 145 is a Serial Flash Memory device. The write/erase group of processing tasks may comprise Universal Serial Bus (USB) file system write access.

The decode/read group of processing tasks may comprise at least one of data decompression, data decoding, data processing, data reading. The data is preferably audio data.

According to another aspect of the invention, there is provided a Random Access Memory (RAM) device wherein the RAM allocation of one group of processing tasks is overlaid onto another group's RAM allocation, the two groups of processing tasks comprising:

• • (a) write/erase
  • (b) decode/read
    wherein processing tasks in group (a) are mutually exclusive to processing tasks in group (b).

The RAM device may be a Serial Flash Memory device. The write/erase group of processing tasks preferably comprises Universal Serial Bus (USB) file system write access.

The decode/read group of processing tasks may comprise at least one of data decompression, data decoding, data processing, data reading. The data is preferably audio data.

According to another aspect of the invention, there is provided a method for allocation of Random Access Memory, the method comprising:

• • allocating a portion of the available RAM to a first group of processing tasks;
  • allocating the same portion of RAM to a second group of processing tasks;
    wherein the first group of processing tasks comprises write/erase tasks and the second group of processing tasks comprises decode/read tasks; and wherein the first and second groups of processing tasks are mutually exclusive to one another.

The first group of processing tasks may take priority over the second group of processing tasks. The method may be performed by a microprocessor.

According to another aspect of the invention, there is provided a processor configured to execute the method described above.

Compression—Audio Coding Scheme

Audio coding schemes are used to reduce the number of bits (data) required to contain an audio signal whilst maintaining a certain degree of quality or reliability. Smaller amounts of data result in faster transmission times and take up less storage space. Larger amounts of data can result in a signal of higher quality or one which is less liable to corruption. Furthermore, there is a wide choice of other attributes a coding scheme has including:

1. Lossy/lossless—Generally it is possible to compress and de-compress an audio signal without any loss of information, i.e. the output is bit-for-bit identical to the input. This form of compression is referred to as lossless. There is a theoretical limit to the amount of lossless compression that can be imposed upon a signal. If a higher compression is required then lossy compression must be used. Although the bits delivered by a lossy compression system are not the same as those delivered by a lossless compression system, every effort is normally made to achieve only the minimum amount of audible degradation consistent with the amount of data compression required.

• • 2. Fixed/variable data rate—Lossless methods of compression, by their very nature, yield a variable data rate, less data when the signal is quiet, more when it is complex. Lossy methods can deliver a variable rate, if designed for a constant low level of degradation, or a fixed data rate, if allowed to impose a variable amount of degradation.
  • 3. Large/small buffering—More or less large buffers may be used, both during encode and decode. Such buffers allow the designer to try to smooth out the data rate of a variable data rate system to appear more like a fixed rate system, or to keep the delivered data rate below some defined limit.
  • 4. High/low complexity—The computational complexity of the encode and decode processes may be large or small, normally, complex process deliver better performance but at a cost.
  • 5. Low/high delay—Low delay systems are used in applications like telephony where the total encode-decode delay is limited. High delay systems are used for the encoding of data onto pre-recorded media (Digital Versatile Disc (DVD), BluRay etc.) where the whole of the audio data to be transported is available to the encoder before any encoded output is required.

For a particular signal and a particular application, there is an optimum combination of all these attributes. However, given a particular application and a range of different signals, a ‘one size fits all’ solution is unlikely. Therefore there is a need for an audio coding scheme which can suitably code a range of signals given a particular application.

According to another aspect of the invention, there is provided a method for encoding an audio signal, the method comprising the steps of:

(a) normalising the peak level of the signal;
(b) applying a gain transformation to the signal;
(c) quantising the signal into a number of bits;
(d) applying a pre-emphasis filter to the quantised signal; and
(e) applying an encoder table to generate an encoded signal.

The gain transformation is preferably a curve bender.

The method may further comprise, after step (c) and before step (d), a step of applying a noise gate to the quantised signal.

Step (c) preferably further comprises applying noise shaping to the quantised signal in order to increase the signal to noise ratio.

Step (e) preferably further comprises generating a probability table from the signal produced by the pre-emphasis filter and, from this probability table, generating the encoder table that is then applied.

The encoder table may be a Huffman code table.

Step (d) preferably further comprises selecting a pre-emphasis filter before applying said filter.

The method may further comprise transmitting the encoded signal to a decoder. Preferably the method further comprises transmitting encoder information to the decoder. The encoder information may comprise one or more of:

• • gain transformation information,
  • pre-emphasis filter selection, and/or
  • decoder table information corresponding to the encoder table applied in step (e).

The method is preferably performed by a microprocessor.

According to another aspect of the invention, there is provided a processor configured to execute the method described above.

According to another aspect of the invention, there is provided a method for decoding audio data, the method comprising the steps of:

(a) acquiring an encoded signal and encoder information;
(b) applying a decoder table to the encoded signal;
(c) applying an inverse pre-emphasis filter; and
(d) applying an inverse gain transformation.

The encoder information may comprise information relating to one or more of the decoder table, the pre-emphasis filter and the gain transformation. The gain transformation may be a curve bender. The decoder table may be a Huffman code table.

The method is preferably performed by a microprocessor.

According to another aspect of the invention, there is provided a processor configured to execute the method described above.

According to another aspect of the invention, there is provided apparatus adapted to encode an audio signal, the apparatus comprising:

(a) means for normalising the peak level of the signal;
(b) means for applying a gain transformation to the signal;
(c) means for quantising the signal into a number of bits;
(d) means for applying a pre-emphasis filter to the quantised signal; and
(e) means for applying an encoder table to generate an encoded signal.

According to another aspect of the invention, there is provided apparatus adapted to decode an encoded audio signal, the apparatus comprising:

(a) means for receiving an encoded signal and encoder information;
(b) means for applying a decoder table to the encoded signal;
(c) means for applying an inverse pre-emphasis filter; and
(d) means for applying an inverse gain transformation.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

The invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. Furthermore, any, some and/or all features in one aspect can be applied to any, some and/or all features in any other aspect, in any appropriate combination.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

These and other aspects of the present invention will now be described, by way of example only, with reference to the following figures, in which:

FIG. 1a is an illustration of various themed toys and/or dolls;

FIG. 1b is a schematic illustration of a doll;

FIG. 2 is a schematic illustration of a wireless communications dongle;

FIG. 3 is a schematic conversation flow diagram in which user-doll interaction is provided;

FIG. 4 is an example of a conversation flow diagram showing user-doll interaction;

FIG. 5 is a schematic diagram showing a toy with name audio files and name references connected to a website;

FIG. 6a is an example of a conversation tree;

FIG. 6b is an example of four roles with different personality values, and a doll with a personality value that has a closest match with one of the roles;

FIG. 6c is three examples of conditional conversation flow;

FIG. 7 is the ‘Theme Development’ window of authoring tool graphic user interface;

FIG. 8 is the ‘Theme’ window of the authoring tool graphic user interface;

FIG. 9 is a populated ‘Theme’ window of the authoring tool graphic user interface;

FIG. 10 is the ‘Publish’ form of the authoring tool graphic user interface;

FIG. 11 is the ‘Voice Maintenance’ form of the authoring tool graphic user interface;

FIG. 12 is the ‘Names Maintenance’ form of the authoring tool graphic user interface;

FIG. 13 is the ‘Stock Phrase Maintenance’ form of the authoring tool graphic user interface;

FIG. 14 is the ‘Add Attribute’ form of the authoring tool graphic user interface;

FIG. 15 is the context list of the authoring tool graphic user interface;

FIG. 16 is the ‘Add Phrases’ form of the authoring tool graphic user interface;

FIG. 17 is the ‘Edit Phrases’ form of the authoring tool graphic user interface;

FIG. 18 is the ‘Add Role’ form of the authoring tool graphic user interface;

FIG. 19 is the ‘Import Audio’ form of the authoring tool graphic user interface;

FIG. 20 is the ‘Set Label’ Form of the authoring tool graphic user interface;

FIG. 21 is the ‘Set Attributes’ Form of the authoring tool graphic user interface;

FIG. 22 is the context entry list with attributes set;

FIG. 23 is the ‘Conditions’ form of the authoring tool graphic user interface;

FIG. 24 is the ‘Say’ form of the authoring tool graphic user interface;

FIG. 25 is the ‘Branch’ form of the authoring tool graphic user interface;

FIG. 26 is the ‘Transition’ form of the authoring tool graphic user interface;

FIG. 27 is the ‘Choose Phrase’ form of the authoring tool graphic user interface;

FIG. 28 is the ‘Choose Attribute’ form of the authoring tool graphic user interface;

FIG. 29 is the ‘Choose Numeric’ form of the authoring tool graphic user interface;

FIG. 30 is the ‘Choose Dolls Data’ form of the authoring tool graphic user interface;

FIGS. 31 to 33 are simulation windows of the authoring tool graphic user interface;

FIG. 34 is the ‘Publish’ form showing theme, topic, and scenario information;

FIG. 35 is the ‘Edit Scenario Text’ form of the authoring tool graphic user interface;

FIG. 36 is the ‘Edit Topic Text’ form of the authoring tool graphic user interface;

FIG. 37 is the ‘Edit Theme Text’ form of the authoring tool graphic user interface;

FIG. 38 is the ‘Publish’ form showing voice information;

FIG. 39 is the ‘Edit Voice Text’ form of the authoring tool graphic user interface;

FIG. 40 is the ‘Publish’ form showing name information;

FIG. 41 is the ‘Edit Name Text’ form of the authoring tool graphic user interface;

FIG. 42 is the ‘Publish’ form showing a log of website communication;

FIG. 43a is a storyboard view in the Story Creator tool;

FIG. 43b is a panel editing view in the Story Creator tool;

FIG. 44 is a schematic illustration of a computing device for the Story Creator tool;

FIGS. 45a, 45b and 45c are exemplary screen shots of connection interfaces;

FIG. 46 is a circuit diagram showing an amplifier circuit incorporating a traditional FET-based H-bridge arrangement;

FIG. 47 is a circuit diagram showing an amplifier circuit incorporating a new hybrid H-bridge arrangement;

FIG. 48(a) is an example signal prior to augmentation with a characteristic signal;

FIG. 48(b) is an example signal augmented with a characteristic signal;

FIG. 49 is a flow diagram showing the signal augmentation process;

FIG. 50 is an example device for augmenting a signal;

FIG. 51 is a flow diagram showing the playback process of an augmented signal;

FIG. 52 is part of an example playback device;

FIG. 53 is a representation of the RAM usage of an example playback device;

FIG. 54 is a flow diagram showing an example signal encoding process;

FIG. 55 is a flow diagram showing an example signal decoding process;

FIG. 56 shows example curve bender graphs as used in the decode process;

FIG. 57 is an example signal encoder;

FIG. 58 is an example signal decoder;

FIG. 59 is a mathematically generated example filtered waveform;

FIG. 60 shows the waveform of FIG. 59 with various curve benders applied; and

FIG. 61 shows the effect of various curve benders on a different example waveform.

In the figures, like elements are represented by like reference numerals.

The numerical values (e.g. of resistors and inductors) given in the figures are merely provided as examples, and alternative values are possible.

BACKGROUND

The basic features and operation of such interacting toys are known in the art, for example in International Patent Publication Nos. WO2006/114625, WO2009/010760, WO2010/007336, or WO2011/124916 (which are hereby incorporated herein by reference in their entirety); however a brief description is provided below to aid in the understanding of the present invention.

Children enjoy playing with dolls, and often incorporate them into their imaginary play. Dolls such as those shown in FIG. 1a are able to interact more fully with children, and with each other, in such play. A first doll 10 and a second doll 20 have generic bodies 12, 22 which may be themed by adding dresses, shoes and accessories. In FIG. 1a a first doll 10 having a generic body 12 represents a female adult and is themed as a ballerina, being dressed in a tutu with ballet shoes. A second doll 20 also having a generic body 22 represents a female adult, and is themed as a tennis player, having appropriate clothing and racket and ball accessories. The theme may be pre-programmed, determined by the downloaded/inputted data, or set by a key accessory (tennis racket, ballet shoes, or a theme tag) which can be sensed by the doll. The dolls' bodies may be manipulated into appropriate poses, as shown.

The following description relates to a toy, such as a toy doll, that is enabled to communicate with other such toys; the dolls are adapted to coordinate the speech between the dolls. In another embodiment the toy is a tank or another such vehicle; again, the tanks are adapted to communicate wirelessly with other such tanks to coordinate the behaviour of the tanks instead of the speech between the dolls. In general the toys are adapted to appear animate and in particular human, or human controlled. FIG. 1a shows four examples of types of themed toys are: a ballerina doll 10; a tennis playing doll 20; a generic doll 30 walking a dog; and a toy 40 in the form of a tank. The toys are adapted to communicate wirelessly with other such toys within the theme.

FIG. 1 b shows a schematic representation of the known doll, with the hardware components required to allow the doll to communicate, and perform other such tasks. The doll 100, as shown in FIG. 1 b, comprises a processor 102 that includes a wireless module 104. The processor is in communication with memory 106, ROM 108, and RAM 110. An IR/RF transmitter/receiver 112 is connected to the processor/wireless module and is enabled to transmit/receive signals to/from other such dolls. The doll is also connected to a loud speaker 114. A USB controller 116 is used to update the memory 106, and also to charge, via the charger circuitry 118, the battery 120.

The memory 106 stores information relating to conversations that the dolls can have, and is accessed by the processor when it is compiling speech. The ROM 108 is used to store permanent information relating to the doll, such as the doll's name and ID number. This information is used in the initialisation procedure when setting up a network of dolls. The RAM 110 stores information relating to a current conversation and is used in order to produce more realistic conversation by storing information relating to phrases already used in the current conversation for example.

Each doll 100 contains in memory 106: a data set containing the doll's name, and other variables, for example variables defined during a conversation; a set of instructions which produces the conversation; and a set of audio data. The variables defined during the conversation are stored on the controller doll.

The dolls are adapted to download a theme, that is, the theme is typically in the form of an audio data file including expressive responses relating to a particular theme, via a PC from a website, and then converse in that theme with other such dolls.

A USB communications dongle is described in International Patent Publication No. WO2009/010760 (which is hereby incorporated herein in its entirety by reference), that enables a PC to interact wirelessly with a toy. FIG. 2 shows a schematic representation of the USB communications dongle 1600, attached to a PC 122, and in wireless communication with the dolls 100. The dongle contains a wireless module 204, an IR/RF transmitter/receiver 212, and an interface 1602. These components enable the downloading of a theme to a doll. Further, these components, except the interface 1602, are the same as contained within the doll 100, as described above. However, the PC 122 is utilised as the processor 1604, instead of the dongle having an independent processor as the doll 100 has, and so the PC effectively becomes a virtual doll able to communicate with the physical dolls 100. The virtual doll is provided with an animated avatar shown on the PC monitor. The avatar may be similar in appearance to the real doll, and the animation of the avatar may be synchronised with the speech of the doll. In order to run the conversations, the PC has stored in memory 1606 an emulator for emulating the processor of the toy.

A website is arranged to allow the user to download various themes, and also to interact with other users. This enables the users to interact both in the virtual world—via chat rooms, games, competitions, or the like—and in the physical world—by playing with other users with the communicating dolls.

User-Doll Interactions

FIG. 3 shows a conversation flow diagram where a doll interacts directly with a user, allowing the user to influence the doll's subsequent doll-to-doll interactions. In one example, a doll expresses a query, to which the user provides a response, in dependence on which the subsequent dialog between the dolls continues. A doll might for example ask its owner whether or not it should respond in a particular way during a doll-to-doll interaction. This affords advantages in the way in which a user can intervene in a doll-to-doll conversation. A physical button on the doll might be provided to enable a user to interact with, and instruct, the doll.

In FIG. 3, the rectangular shapes indicate phrases expressed by a first doll, and oval dialogue shapes indicate phrases expressed by a second doll. At dialogue block 201 the second doll expresses a query and awaits the user's response, thus allowing the user to influence the course of the conversation with his response. The doll may continue on a default branch of the conversation if no response is received within a given period. If the doll receives a response within the given period then the conversation proceeds along the line determined by the user's response.

In an example of the user influencing doll-to-doll interaction a doll might ask its owner “Shall I accept her invitation to go play tennis?” after another doll has invited her to play tennis. If the user responds with an acceptance, then the doll-to-doll conversation carries on relating to the subject of playing tennis (the doll might subsequently ask its owner “Can I put my tennis kit on now?”). If however the user responds with a refusal then the course of the doll's interactions changes, and the doll-to-doll conversation continues in a new direction that no longer relates to playing tennis.

Other types of user interaction than responding to a doll query are possible. For example, a user may be able to instruct a doll participating in conversation to leave the conversation, and hence cause the doll to conclude the conversation, or excuse itself from the conversation. The user may also be able to instruct a doll to change the theme of a conversation, and hence cause the doll to conclude the conversation in the current theme and change to a conversation on another theme.

The change in the course of the doll's interactions may affect the theme, in particular by changing to a new theme; or it may affect the course of a dialogue within a theme.

FIG. 4 shows an example of user intervention that changes the course of the dialogue, but stays within the same theme (in the illustrated example the theme is ‘walking the dog’). The doll expresses a first query 220. Depending on the user's response (in this case either approve the doll's suggestion with ‘yes’ 224, or disapprove the doll's suggestion with ‘no’ 226), a second query 222 may be expressed by the doll—in the illustrated example the doll reformulates the same suggestion, for the user to either again disapprove, or this time approve. When the end of the dialogue block 230 is reached, a new dialog block may follow, for example within the same theme, or ending the theme to change to another theme.

User-doll interactions may be extended from the simple ‘accept/refuse’ scenario described above to permit more complex responses and dialog options. For example, the user could make a selection from a list of options (“Shall we go do our hair, bake a cake, or read a magazine now?”) to influence the course of the doll's interactions. The input could be effected by (for instance) buttons on the doll, a remote control for the doll, or a computing device with a link to the doll.

For educational purposes a more sophisticated conversation between the doll and a child may provide additional benefits. For example, the doll could encourage the child to recall educational information, and respond with approval if the child provides a correct answer, thus assisting the child in learning the information (“Let's do a quiz game! What's the capital of France? I'll give you a hint: it's also the capital of fashion!”).

Name Files

In one example, it is possible for the owner of a doll to select the doll's name, for instance during the initialisation of the doll. In the course of dialogue, a doll may address other dolls by name. However, a doll only has a limited memory, and hence number of audio phrases available, and in this example is not capable of synthesising the audio data necessary to express another doll's name. If the owner is enabled to select the doll's name from a larger pool of possible names (for example 100 possible doll names), then it may not be efficient for each doll to have the entire selection of name data available. Further, if new names become available in the course of time, and new users start selecting the new names, then the existing users may not have the new names available.

To overcome this problem a doll is enabled to ‘learn’ to say a new doll's name by storing a reference associated with the new doll's name when first coming into contact with the new doll, and then retrieving an audio file associated with the new doll's name when next connecting to a server.

The concept may be extended to other variables that relate to a doll that may be spoken in the course of a conversation; for example pets' names, name of the doll's owner, name of the town or area the doll ‘lives’ in, a place of birth, a home town, a hobby or interest, a favourite colour, a favourite food, or other similar variables.

FIG. 5 illustrates how a doll 100 acquires the ability to refer to (‘speak’, or otherwise express) variables. When a doll 100 is exposed to a variable of another doll (e.g. a doll's name; or a doll's favourite pop star), it receives a signal from the other doll that contains a variable identifier 258. The identifier is compared to existing audio data 105 to determine if the audio data for that identifier is already available. This allows determination of whether the variable is a new, hitherto unfamiliar variable, or if the doll has already been exposed to the variable. If the relevant audio data is already available, then the doll can already refer to the variable in conversation. If the relevant audio data is not already available, then the identifier is stored in a required data identifiers part 107 of the doll's memory for subsequent retrieval of the appropriate audio data.

In the illustrated example, the variable is a name, and the name identifier is of the form ‘Name[ID number]’. Two name audio data files 103 are already available, in addition to the audio data file 101 for the doll's own name. Assuming the received identifier is to a name the doll does not already have, then the identifier is stored in a list 107 with other required data identifiers. The list 107 identifies data that is to be requested from the server 200 when the doll next connects to the server 200.

The user may have the option of selecting audio output settings with which the doll converses. Audio output settings include the voice in which the doll speaks (as is described in more detail below), the accent with which the doll speaks (Scottish, South African, Swiss), or even the language of the doll. The audio output settings are for example selected by the user during the initialisation of the doll. The audio output settings are stored in a doll audio output settings part 256 of the doll's memory. To ensure that the audio data retrieved from the server 200 has the correct audio output settings (e.g. is in the correct voice) for the doll, the doll audio output settings 256 are used.

When the doll next connects to the server 200 (in the illustrated example via a computing device 260 connected to the internet 262) the doll submits its list 107 of required data identifiers. The doll also provides its audio output settings 256. The server 200 has audio data available for the different combinations of identifier and audio output setting. In the illustrated example, the data is shown organised in tables 250 252, where one table 250 contains name audio data, a second table 252 contains other variable audio data (e.g. favourite animal). For each audio output setting (e.g. voice setting) audio data is stored for each possible identifier (e.g. name identifier). In the illustrated example, the audio output setting is specified to be ‘AS02’, and one of the required identifiers is specified as ‘Name04’. The audio data file 254 specified by these constraints is located at the server and provided to the doll.

When the doll next encounters the other doll with Name04, it receives a signal from the other doll that contains the ‘Name04’ identifier. The doll can then use the audio data file 254 to speak (in the correct voice) the other doll's name and thereby refer to the other doll by name in the conversation. If the doll encounters a new doll that happens to have Name04, then the doll can already address the new doll by name, as it already has the appropriate name audio data stored.

Additionally, or alternatively, the server can maintain a record of the doll's audio output settings, and ensure that the audio data provided to the doll is the correct audio data for the specified audio output data.

Additionally, or alternatively, the server can maintain a record of each doll's variables. In this case, when a first doll is exposed to a second doll, the first doll receives a signal from the second doll that contains an identifier that specifies the second doll (e.g. a unique doll-specific identifier). The second doll's identifier is stored at the first doll and submitted by the first doll when it next connects to the server. The server uses the second doll's identifier to retrieve the record for the second doll, and from that record determines the second doll's variables. The server provides to the first doll the audio data for the second doll's variables, according to the first doll's audio output settings. The audio data may be referenced back to the second doll's identifier (e.g. by naming—for instance Doll000022_Name_audio). In this case a set of audio data is stored for each other doll, and some redundancy may occur—if for example there are two other dolls that happen to have the same name, then the same audio data is stored twice under different identifiers. Alternatively, the server may provide—in addition to the audio data—a look-up table or the like for the second doll's variables with which the doll references the audio data (e.g. Doll000022_Name=Name04). In this case when the first doll encounters a third doll (with doll identifier Doll000033) that has the same name as the second doll (Name04) then the first doll does not require downloading of the Name04 audio data again, however upon receipt of the third doll's identification, the first doll cannot speak the third doll's name until it has obtained the look-up table linking the doll identification (Doll000033) to the audio data (Name04).

In conversation, a doll can respond to another doll depending on whether the audio data for a variable is available or not. If the audio data for a variable is not available, then the conversation may for example take a course in which the doll asks questions regarding the variable (e.g. ‘What's your favourite dessert?’). If the audio data for a variable is available, then then the conversation may for example take a course in which the doll refers to the variable in the conversation (e.g. ‘Chocolate cake is your favourite dessert, right? I love baking cakes! Let's bake a chocolate cake!’).

The process allows a doll to acquire the ability to refer to variables in conversation, and in addition ensures that the doll can do so correctly according to the doll's audio output settings. The process allows a large number of possible variables to which dolls can refer, so that the user has great freedom of choice and dolls and their conversation can be tailored to a large degree. By taking audio output settings into account, a variable specific to another doll is tailored according to the doll's own settings. Taking audio output settings into account provides the benefit of allowing the user to influence the doll (e.g. by choice of voice). Storing the audio data at the server and retrieving such audio data as required provides flexibility, which in turn allows the conversations to be updated and adapted frequently. It also allows central storage of the audio data, with only the required data stored at the doll. This minimisation of storage requirements at the doll enables more portable dolls, which is a favourable feature in a toy.

In one example, a name audio data is referred to by identifiers (or references) of the form 0x6nnn, where the nnn is an index to the particular name from a defined selection of names, for example 100 possible doll names. During the running of a conversation a doll may be required to speak a name by receiving a name reference 0x6nnn.

When a doll is required to speak a name, the conversation engine checks the name audio data cache to see if the appropriate name audio data is available. If the name audio data is available then the name is spoken. If the name audio data is unavailable then a record is made of the name reference 0x6nnn in a list of required names (‘required data identifiers’ list). The list of required names is stored in a permanent fashion even if the doll is subsequently switched off.

When the doll next connects to a website or server (via a computing device and the internet) it delivers its list of required names, and receives the name audio data for the required names. The received name audio files are added to the name audio data cache. In an example where the name audio data cache can contain a maximum number, e.g. 10 name audio files, then the name audio data cache is made up of the doll's own name followed by the 9 most recently requested names. If the name audio data cache is already full upon receipt of new names, then the least recently used name audio files are discarded. The processor may for example determine, upon receipt of a name audio file, if the name audio file can be added to the name audio data cache without exceeding the maximum number of name audio files. If it is determined that the maximum number of name audio files the in the name audio data cache would be exceeded, then name audio files are deleted from the name audio data cache until the new name audio file can be added without exceeding the maximum number of name audio files. For example, the least recently used name audio file in the name audio data cache is deleted.

Authoring Tool—General, Environment

The authoring tool is an application which can be used to create conversation themes for multiple dolls. The authoring tool is also described in International Patent Publication No. WO2010/007336 (which is hereby incorporated herein in its entirety by reference). In particular FIG. 11 and the associated description of WO2010/007336 describes various aspects of the authoring tool. Briefly, the creation of conversations requires a significant amount of time due to the large number of potential branches that the conversation might follow. FIG. 6a illustrates an example of a conversation tree. In order to make the process more efficient an authoring tool is provided to aid in this process. A client application runs on a computing device (personal computer, laptop, or the like) with the data stored on a server to allow either multiple users to work on the same theme, or for a single user to work on the same theme from different locations. A web service is provided on the server which provides an interface between the database and the client application. The client application communicates with the server via the internet. The client application formats requests to the web service, and hence the database, using XML, and transmits the data using the SOAP protocol.

The authoring tool (also referred to as the ‘scenario development tool’) permits the creation, development, testing, management and uploading (publishing) of scenarios and associated ancillary data. A scenario is based around a conversation tree as shown in FIG. 6a. A scenario relates to a theme; in FIG. 6a for example the theme is ‘Walking the Dog’. A scenario is composed of (themed) data or content relating to (or within) a particular theme. A multitude of scenarios for the same theme may be available. A scenario may be associated with a single theme, or with more than one theme.

A scenario may be structured, as illustrated schematically in FIG. 6a, in which the oval blocks represent the scene introduction, the rectangular blocks represent the main body of the scenario, and the rounded rectangular blocks represent scene endings. In the conversation tree illustrated in FIG. 6a, a scene introduction is at the beginning of a conversation, then a main body branch follows. At the end of a main body branch the conversation may be looped back to a new main body branch, or (for example based on a probability-weighted selector) progressed to a scene ending. A scenario may also be a scripted dialog, resembling a theatre or film script rather than a conversation tree as illustrated in FIG. 6a.

Scenarios are designed based on a defined number of roles (roles are virtual dolls, like roles in a play are virtual actors). The roles are given nicknames to help the scenario author remember the role's identity while writing a scenario.

Personality Fitting

Dolls as well as roles have a ‘personality’ or ‘character’. A personality value (also referred to as a ‘character’ value) is defined by setting eight personality traits with values between 0 and 15. The personality traits cover a spectrum of what most people consider to be ‘important’ personality traits and so provide a way of characterising the personality of each role.

A doll's personality value may be set by its user or owner. The personality value may be modified by the user, for example via a computing device. The user may be able to select a pre-defined personality value from a list.

The eight personality traits are stored in a 32 bit number; the resulting personality value is stored in the compiled scenario file (for a role) or in the doll data file (for a doll). The personality value of a doll is stored in a permanent fashion in the doll data file, even if the doll is subsequently switched off.

The personality value is not the same as a mood. A mood, unlike a personality value, may vary from conversation to conversation. Moods may for example be stored as attributes. Moods are however not stored in the doll data file. Alternatively, one or multiple of the personality traits may be reserved for mood parameters. Setting and storing of the personality value is described in more detail below.

A doll's personality value can be used in conversations (in particular at the initiation of conversations) so that the doll is able to choose a role such that the role's personality value is closest to the doll's personality value. For example if the user has defined a doll as ‘thoughtful’, then the doll has a tendency to select roles that are ‘thoughtful’.

FIG. 6b is an example of four roles 270 “Mary”, “Alice”, “Evie”, and “Liz”. Each role has a personality value comprising three different personality traits 274 “sporty”, “thoughtful”, and “silly”. Each personality trait has a value between 0 and 15. For example the role “Mary” is quite sporty, whereas the role “Alice” is quite thoughtful. A doll 272, in the illustrated example named “Molly”, also has a personality value comprising the three different personality traits 274. In the illustrated example “Molly” is quite thoughtful. When Molly joins a conversation that is designed with the four illustrated roles, Molly's personality value has a closest match with the “Alice” role, hence Molly's first choice of role is the “Alice” role.

The personality value can also be used to influence the conversation flow. For example a doll might prefer to go to the library instead of play tennis depending on level of sportiness. The use of personality value (or other attributes) for structuring the flow of a conversation is described in more detail below.

A mood value that can be altered during the course of a conversation may be defined as an attribute that persists between conversations. The mood value may be used for conditional conversation flow, allowing selection of conversation branches depending on a current mood value. A mood value may be changed depending on an action or outcome or the course of a conversation.

Voices

Numerous voices are required for the dolls to have individual voices. This is advantageous as it allows the user to customise his or her doll. For example, a user that has two dolls can choose a deep voice for one doll, and a ‘breathless’ voice for the second doll. The choice of voice for a doll is made during the initialisation of a doll, for example when first connecting the doll to a website (via a computing device such as a PC). To accommodate different voices the audio files are available for each voice version, and the doll downloads the appropriate voice version of a scenario.

The dolls may be configured to enable them to say phrases or parts of phrases more or less loudly. This can be controlled for example by a doll attribute, such as a mood attribute. To achieve this meta-data may be associated with the audio file to influence the volume or volume modulation when the doll speaks a phrase. Alternatively, if the doll is not adapted to control volume and volume modulation, a phrase is recorded or synthesised in a variety of versions with different modulations and volumes. The doll can then select the correct phrase to be spoken in dependence on the situation, as parameterised by attributes and conditions.

Scenario Features

Scenarios support the concept of a ‘Golden Phrase’. A ‘Golden Phrase’ is a designated phrase that may be (but need not be) spoken within a scenario. In FIG. 6a the ‘Golden Phrase’ of that scenario, indicated by italic bold font, is at the bottom left of the conversation tree. When a doll speaks the ‘Golden Phrase’ the doll earns a reward. To enable the reward, when a doll speaks the ‘Golden Phrase’ this fact is recorded by the doll. When the doll next connects to the website the doll's record is uploaded, and the appropriate reward is given (for example points for an online doll alias, usable to acquire accessories for the alias). Only the first doll to speak the ‘Golden Phrase’ during a conversation is entitled to the reward and records the event. The doll's record of having spoken a ‘Golden Phrase’ is stored in a permanent fashion, even if the doll is subsequently switched off, until such time as the record is uploaded.

By recording data relating to the conversations, such as the doll having spoken the ‘Golden Phrase’ or the number of conversations a doll has been involved in, when a doll connects to a web site this data can be registered and used to compare and/or reward dolls. For example, a point score table (leader board) can be incorporated in the online environment as a part of an online game.

Scenario development parameters include:

• • The maximum number of supported roles (described above)
  • The maximum number of supported voices
  • The maximum number of supported attributes (attributes are described in more detail below)
  • The maximum number of choices per event (events and choices are described in more detail below)

When a scenario has been created it is given a unique scenario ID. The scenario ID includes a 32 bit number, a scenario name and optionally a scenario description (e.g. a paragraph of text describing the features of the scenario). The scenario description may for example be accessed by and displayed in the website.

Scenario Operations

A scenario can be saved in a (.tmx) file and recovered later for further editing. When a scenario is complete it may be compiled. Compilation, if successful, produces a (.bin) file. If audio recordings or synthesised audio data of the phrases used in the scenario are available then the (.bin) file contains audio data as well as scenario data. If the audio data is not available then the (.bin) file contains just the scenario data.

The (.bin) file can be used with dolls and/or with a simulator (described in more detail below). The simulator can use the (.bin) file with or without audio data files. Dolls require the audio data files to be present. This arrangement allows the testing of scenarios in a pre-audio phase, in the absence of audio data.

Once a scenario has been compiled it can be tested with the simulator part of the authoring tool. Simulators represent dolls and each simulator that is started represents a different doll. Simulators as well as dolls have a doll data file which contains the ‘character’ value (also referred to as the ‘personality’ value), as described above (as well as other data).

The conversation engine is used to run the scenario data in simulators as well as in dolls. The conversation engine is a program that runs in the simulator, and also in the actual dolls. It is responsible for processing the instructions contained in the scenario file that has been loaded. The conversation engine causes the appropriate doll to speak the appropriate audio phrase at the appropriate time.

The conversation engine also maintains a log of the number of times a simulator or doll has joined a conversation. A doll earns rewards in proportion to the number of times it joins a conversation. To enable the reward, when the doll next connects to the website, the doll's conversation log is uploaded and the appropriate reward is given (for example points for an online doll alias, usable to acquire accessories for the alias). In dolls the conversation log is stored in a permanent fashion, even if the doll is subsequently switched off, until such time as the log is uploaded.

When a simulator is started it requests to join the conversation in the scenario being tested. The simulator takes the unassigned role that most closely matches its ‘character’. The first simulator started becomes the ‘Controller’ and has the first choice of role. Subsequent simulators become ‘Clients’ (also referred to as ‘Slaves’). The maximum number of simulators that can join the conversation in the scenario is equal to the number of roles defined for that scenario. During the running of a conversation simulators may be ‘exited’ (simulating the removal of a doll from the conversation) or started up (simulating the arrival of a new doll).

Once sufficient simulators have been started the scenario conversation can be started. The ‘Controller’ simulator then runs the scenario data and simulates the logic of the scenario as designed by the authoring tool. A log of important events is maintained by each simulator outlining what is said, who says it, etc. If audio data is available then the audio data file is played so that the conversation can be followed aurally. Log files of each simulator are stored for subsequent examination, if required.

Following a test run with the simulators the scenario is modified and/or re-tested. The ability to test a scenario in a pre-audio phase prevents committing resources to record or synthesise the audio data until the scenario is satisfactory. When the audio data is available testing with the simulator is repeated with the audio output. When a scenario has passed simulated audio testing the scenario is downloaded to dolls and the scenario is tested with the dolls. When a scenario has passed the testing on dolls, it is ready for submission (for example uploading to a website for distribution).

Tools to support various aspects of scenario development are included in the authoring tool. For example compilation of a scenario produces a ‘Phrases.txt’ file which contains an indexed list of all the phrases used in the scenario. The ‘Phrases.txt’ file can then be used as a cue-sheet for recording the audio data.

The authoring tool allows scenario management, in particular maintaining the local environment to support the development, testing and uploading of scenarios, and the importing of audio files as appropriate. The local environment includes the following folders and files:

• • Base Folder—(with a default name). The following folders are sub-folders to this Base Folder.
  • Names—This contains the file ‘names.txt’ which contains an indexed list of the text of each supported name together with its reference value. The index is of the form A0000n, which is a reference to the audio file containing the name. This folder also contains sub-folders named Voice1, Voice2 etc., which in turn contain the audio data for each supported name recorded or synthesised in the corresponding voice. The name audio files are named A0000n.wav and are referenced in the ‘names.txt’ file.
  • Themes—This contains sub-folders containing scenario data. Each sub-folder is named with the scenario ID of the scenario it contains. Each scenario sub-folder may contain one, some, or all of the following types of file:
    • ‘Phrases.txt’ (containing an indexed list of all the phrases used in the scenario; produced by the tool when saving the scenario and useful for testing and also as a cue sheet for recording)
    • ‘Scenario_Name.tmx’ (a saved version of the scenario suitable for further editing)
    • ‘Scenario_Name.bin’ (containing the compiled scenario data in a pre-audio format, with no audio data, suitable for testing)
    • ‘Scenario_Name_v.bin’ (containing a temporary compiled version of the scenario in a pre-audio format suitable for the appending of compressed audio data files)
    • ‘Scenario_Name_Vn.bin’ (containing the compiled scenario data plus audio data files for voice n; this is the final format that is eventually downloaded to the dolls).

Each scenario sub-folder also contains sub-folders named Voice1, Voice2 etc., which contain the recorded or synthesised phrase audio data in the corresponding voice. These folders are populated with phrase audio data files at such time as phrase audio data files become available.

• • Dolls—This contains sub-folders named Doll_ID (e.g. 32 bit integer in hexadecimal such as 0000001) which in turn contain the doll data file called ‘MyData.txt’, which contains:
    • reference to the doll's name audio file
    • the doll's ‘character’ value, as described above
    • the doll's voice, e.g. Voice1
  • This data is primarily used by the simulator. Actual dolls contain their own doll data file.
  • Voices—This contains sub-folders Voice1, Voice2 etc., which in turn contain the following files:
    • Description.txf (a text description of the voice)
    • ‘Sample.wav’ (a sample recorded or synthesised in the corresponding voice)
  • Stock Phrases—This contains the file ‘Phrases.txt’, which contains an indexed list of the stock phrases. Stock phrases are a set of 5 phrases which are available to the conversation engine independent of any loaded scenario(s). Stock phrases can be used for such things as a “battery low alert” or other error or status conditions. This folder also contains sub-folders Voice1, Voice2 etc., which contain the recorded or synthesised stock phrase audio files in the corresponding voice.

An example of the content of the theme data file (also referred to as a scenario data file) is presented in Appendix A.

The authoring tool also enables scenario uploading, wherein scenario data is uploaded to the website. The scenario data that is uploaded includes:

• • a scenario ID (32 bit number)
  • a scenario name (text)
  • a scenario description (text)
  • a theme and topic category under which the scenario should appear on the website. If the theme and topic category do not exist on the website then they are created.
  • a flag indicating if the scenario is in test mode
  • Scenario_Name_Vn.bin files for each supported voice (Vn indicates Voice1, Voice2 etc.). Each (.bin) file contains the scenario data file to which the compressed audio data of all the scenario's phrases, recorded in the corresponding voice, is appended.

In the conversation engine phrase audio data is referenced in the form 0x5nnn, where the nnn is an index to the actual phrase; the following referencing convention is used:

• • reference 0x5000 is to a null phrase
  • references 0x5001 to 0x5005 are to stock phrases, as described above
  • references 0x5006 onwards are to the scenario phrase audio data. These references are sequential with no numbers missing.

Name files for audio data of other dolls' names may be required within a scenario. Name files (with the audio recording of a name) are not included with the scenario data (as the scenario is operable with an arbitrary set of names). Instead, the name files are accessed by reference to data that is not part of the scenario file. Further detail relating to the way in which other dolls' names are handled has been discussed above.

Attributes assist in sculpting the scenario and the resulting conversation. Attributes can be defined at doll level, scenario level or theme level, or otherwise. For example, a doll attribute may be the colour of the doll's dress; a scenario attribute may be the colour of sandals the doll intends to buy; and a theme attribute may be the doll's favourite retail brand. Dolls can refer to attributes in a conversation. For example, if dolls are playing a game, then they can refer to each other's attributes—“your turn, green!”. Attributes can also be used to direct the flow of the conversation. In the game-playing example, a statement can depend on what occurred in a forgoing round—“oh, bad luck, poor you!”. Attributes can be set in the course of a conversation—for example a mood attribute of a winning doll can be set to ‘happy’, and this in turn may be used to determine the course of the conversation. Attributes may be defined for the sole purpose of controlling the conversation flow, or they may be defined for references within the conversation, or a combination of both.

The ability to perform arithmetic operations (addition, subtraction, multiplication, division) allows sophisticated control of conversation flow. For example, simple addition operations enable the conversation flow to cycle through all dolls that are present, with each doll going through various loops in dependence on the counter. The ability to perform arithmetic operations is also useful to implement scripts such as playing board games, where very often a position is incremented in dependence on a random dice roll.

Attributes, combined with the ability to perform arithmetic operations, allow sophisticated conditional conversation control. Conditional testing for example sets a condition value on the basis of an attribute, such as if the doll's dress is a certain colour. A condition value can be used to determine a conversation branch to pursue. This allows the conversation to flow with more structure and control than if a branch is selected randomly.

The authoring tool enables subroutines wherein the conversation can return to a main routine instead of just branching to a different routine. Different subroutines can be called in a controlled manner. In FIG. 6a for example, at the end of a main body branch and depending on a weighted random factor, the conversation may either be looped back to another main body branch, or progressed to a scene ending.

FIG. 6c shows examples of conditional conversation control (also referred to as conditional branching). Conditions that are tested are indicated by hexagonal shapes; rectangular shapes indicate phrases that a doll can express. In one example of a condition 280 the next phrase to be expressed is chosen in dependence on a personality trait of the doll speaking the next phrase (or the personality trait of the role). In another example of a condition 282 the next phrase to be expressed is chosen in dependence on a random input. In the illustrated example, the selection is biased toward the ‘No’ branch with 80% probability of selection. In another example of a condition 284 the next phrase to be expressed is chosen in dependence on a scenario attribute, in the illustrated example an attribute called ‘weather’ which can have values ‘rainy’, ‘cloudy’, or ‘sunny’. The scenario attribute ‘weather’ may for example have been set in a previous part of the conversation, where a random selection occurs between a group of phrases that express that the weather is either rainy, sunny, or cloudy.

The authoring tool provides checking to ensure that inputs (by importation or via forms) are syntactically correct.

The operation of a doll conversation is summarised as follows:

• 1. The header is read and held in memory=16+n*6 bytes: where n is the number of roles in this theme.
• 2. Processing the conversation consists of the following operations:
  • 2.1. A starting role is chosen and the first context entry for that role is read into memory=12 bytes.
  • 2.2. The information in this context entry is processed.
    • a) The next role is chosen using the specified transition method.
    • b) Attributes are set using the set_attribute_block and the set method described in more detail below.
    • c) The condition_block is processed using the condition method described in more detail below.
    • d) A statement is chosen from the statement_choice_block using the say method described in more detail below.
    • e) A branch point to the next context entry is chosen from the branch_choice_block using the branch method described in more detail below.
    • f) The current role (doll) is told to say the thus chosen statement (phrases).
    • g) The next context entry for the next role is then read into memory and processed depending on the statement mode (timing data).
    • h) This repeats until the conversation ends.

Authoring Tool—Further Details and Examples

The authoring tool (also referred to as theme development tool) is now described in more detail with reference to an exemplary embodiment.

When the authoring tool is first executed the Theme Development graphic user interface (window) 300 shown in FIG. 7 is displayed. The theme data directory 312 indicates the file directory in which the authoring tool operates; it can be selected as required. If a new empty folder is selected as the theme data directory the data structure defined above is created.

The Theme Development window 300 provides menu items “New” 301, “Open” 302, “Append” 303, “Import” 304, “Publish” 305, “Close” 306, “Voices” 307, “Names” 308 and “Stock Phrases” 309. Each of these menu items is now described in further detail.

New 301—This allows a new scenario to be developed from scratch. Upon selection the ‘Theme’ window 400 shown in FIG. 8 is displayed. This window allows the full features of a multi-doll scenario to be developed. Once developed the scenario may be saved, compiled and/or tested. Audio data may be synthesised, or recorded audio files may be imported, and the scenario may be compiled with the audio data for uploading to the website. The functionality of the ‘Theme’ window 400 is described in more detail below.

Open 302—This allows an existing (e.g. previously saved) scenario to be opened for further development, editing etc. Upon selection the ‘Theme’ window 400 opens, with the fields populated as shown in FIG. 9, or a window similar to it (the exact appearance depends on the particular scenario). This window shows the data defining the scenario:

• • Theme 401—The name of the theme to which this scenario belongs (in the illustrated example ‘Shopping’).
  • Topic 402—The name of the topic to which this scenario belongs (in the illustrated example ‘Mall’).
  • Scenario ID 403—The unique identification number of this scenario (in the illustrated example ‘1’). This is a locally defined scenario ID and only needs to be unique in the local environment. When uploaded to the website the scenario ID is changed to match the globally unique ID assigned by the website.
  • Scenario Name 404—The name of the scenario (in the illustrated example ‘Mall Scenario One’).
  • Scenario Description 405—A paragraph of text describing the main features of the scenario for inclusion in the website.
  • Theme Attributes 406—The list of theme attribute names. This form allows the addition or removal of existing theme attributes
  • Phrases 410—The list of phrases the theme may use, which are indexed in the order shown in this list. This form allows the addition, removal or editing of phrases.
  • Golden Phrase 415—specifies one of the phrases as the Golden

Phrase.

• • Roles 429—The list of roles supported by this theme. This shows a role nickname (e.g. “Mary”) followed by the role's personality traits (e.g. 0,0,0,0,0,0,0,0) for each supported role. This form allows the addition, removal or editing of roles.
  • Role Attributes 430—The list of role attribute names. This form allows the addition or removal of existing role attributes.
  • Edit Context for Role 423—This allows the context entries for each role to be edited. The context entries are what define the flow of the theme conversation.

The functions of the items in the ‘Theme’ window 400 are described in more detail below.

Append 303—This allows an existing sub-scenario to be appended to the end of the current scenario. This is useful for re-using useful sub-scenarios in new settings.

Import 304—This allows the creation of a theme from a simple play-like script. A play-like script has some or all of the following formatted text elements:

• • Theme: theme_name (optional)
  • Topic: topic_name (optional)
  • Scenario: scenario_name (optional)
  • Description: description_text (optional)
  • Role: allows the definition of role personality traits (optional, multiple entries possible); the format is: role_name,personality_value.
  • Phrase: phrase_text (optional, multiple entries possible); this allows for the definition of phrases in a pre-defined order.
  • Acts: allows simple conversation branching (optional). This entry allows the definition of acts with alternative scenes so as to control the flow of the scenario. For each act a cluster of possible scenes is defined, and in the conversation one of the scenes is chosen at random. Sequential acts can be listed. If the ‘Acts’ statement is omitted then each scene runs in the written order.
  • Scene: scene_name (optional) allows the scripting of scene subunits within the scenario:
  • Character: statement_text—this allows entry of a statement to be spoken by a character. The full syntax is Character: {modifiers} statement_text alternative_statement_text; various options are described in more detail with reference to the scripting language.

The following is an example of using the scripting language in a simple play-like script:

• • Theme: Shopping
  • Topic: Mall
  • Scenario: Mall Scenario four
  • Acts: (Mall1,Mall2)
  • Mary:
  • Scene: Mall1
  • Mary: Hi—[next.Name] Thanks for coming!
  • Alice: Are you kidding [prev.Name]—I'd never miss a trip to the mall with you guys!
  • Liz: Or a chance to check out the sales!

Evie: I've got all my spending money with me!

• • Liz: This is gonna be super fun!
  • Alice: So what do we hit first—The department stores—Shoe sale or the cosmetic stand?
  • Mary: I don't mind but I can't leave without buying a new glitter gloss.
  • Evie: And I have to check out the new ribbon tie sandals at the shoe boutique!
  • Mary: They would totally go with your boot cut jeans.
  • Evie: Totally.
  • Liz: Oh and I need to check if that pussy bow dress comes in pink yet—They only ever have blah blue!
  • Mary: Are you sure its the dress you wanna check out?
  • Alice: And not the boy working on the coffee counter outside?
  • Evie: Giggles—Totally!
  • Mary: Giggles1.
  • Alice: Giggles2.
  • Liz: No way—That's SO not happening—Its all about the dress!
  • Liz: This is gonna be super fun!
  • Mary: So what are we waiting for?
  • Alice: Let's roll!
  • Evie: Totally!
  • Scene: Mall2
  • Mary: Hey!
  • Liz: Hi!
  • Alice: I finally got here!
  • Evie: Yeah, I thought I was gonna be late.
  • Liz: It looks like we've already shopped. Wanna do something else?
  • Mary: I know, you could stay over at mine!

Liz: A sleep over, I'm there!

• • Alice: I'll bring the sodas.
  • Evie: I'll bring the popcorn.
  • Alice: Sounds like we have everything covered!
  • Evie: Now let's go get ready!
  • Alice: Yes, see you at the sleep over!
  • Liz: Bye bye for now.
  • Mary: Oh and don't forget your PJ's!
  • Liz: X—O—X—O.

When imported, this above script creates a scenario named “Mall Scenario four” within Theme “Shopping”, topic “Mall” containing 4 roles with nicknames Mary, Alice, Liz and Evie. The scenes are organised so that when run it makes a random choice of running Mall1 or Mall2. Importation of the above script causes the window shown in FIG. 9 to be displayed.

Importation of a script is a simple way to begin a new scenario. The play-like script format is straightforward and intuitive and once imported provides a complete but simple scenario. This format provides a basis for simplified scenario authoring, allowing users to create their own scenarios. A simplified authoring tool is described in more detail in the Simplified Authoring Tool section below. This type of scenario is simple in the sense that it is completely deterministic as regards which doll says what and when it speaks. For more sophisticated scenarios an imported scenario can be developed further with the authoring tool to add any of the supported features such as attributes, random alternative statements, numeric logic, conditional branching and the like. Alternatively, the use of keywords in the script allows the definition of sophisticated scenarios within the script; this is described in more detail in the Scripting Language section below.

Publish 305—This allows interaction with the website to allow uploading of scenarios, voices and names. Upon selection of the ‘Publish’ menu item 305 the ‘Publish’ form 800 is displayed, as shown in FIG. 10. The ‘Publish’ form 800 is described in more detail below.

Close 306—This allows the currently active scenario to be closed.

Voices 307—This allows operations relating to the definition a synthetic voice for each supported voice in order to be able to synthesise phrases. Upon selection of the ‘Voices’ menu item 307 the ‘Voice Maintenance’ form 820 is displayed, as shown in FIG. 11. The ‘Voice Maintenance’ form 820 is described in more detail below.

Names 308—This allows operations relating to the definition of supported names and corresponding name audio files. Upon selection of the ‘Names’ menu item 308 the ‘Names Maintenance’ form 810 is displayed, as shown in FIG. 12. The ‘Names Maintenance’ form 810 is described in more detail below.

Stock Phrases 309—This allows definition and editing of stock phrases. Upon selection of the ‘Stock Phrases’ menu item 309 the ‘Stock Phrase Maintenance’ form 830 is displayed, as shown in FIG. 13. The ‘Stock Phrase Maintenance’ form 830 is described in more detail below.

Scripting Language

The scripting language and the commands supported by the authoring tool are now described in more detail.

The scripting language allows the complete specification of a scenario in a text form which can be imported into the authoring tool for further processing. The syntax of the imported script is checked during the import process. Importation is terminated on detection of a syntax error. Textual information is provided to detail the type and location of the error.

The scripting language provides an intuitive way to construct simple play-like scenarios, but it can also include more advanced features for the development of more complicated scenarios.

The scripting language consists of formatted statements of the following form:

• • Keyword: text—This is an active script element
  • // comment_text—This allows the inclusion of explanatory comments within the script. These are ignored during the import process.

Because they are used by the script syntax the characters & |: ( ) [ ] should be avoided for uses other than giving the prescribed script syntax, in particular in statement text.

The following keywords and scripting commands are available (as also described above with reference to the ‘Import’ 304 function):

• • Theme: theme_name (optional, no more than one entry per scenario)
  • Topic: topic_name (optional, no more than one entry per scenario)
  • Scenario: scenario_name (optional, no more than one entry per scenario)
  • Description: description_text
  • ID: scenario_ID, integer value (optional, no more than one entry per scenario)
  • Role: role_name,personality_traits—this allows the definition of role personality traits (optional, multiple entries possible). As described above the personality value is composed of 8 personality traits, each having an integer value from 0 to 15; personality traits are input in the form trait1,trait2,trait3,trait4,trait5,trait6,trait7,trait8.
  • Acts: act_scene_group, act_scene_group, . . . —this command allows simple conversation branching (optional). A list of act specifications is separated by commas. An act specification is a list, enclosed in brackets, of scene names separated by commas. The scene names must be those introduced by the ‘Scene:’ keyword described below. This entry allows the grouping of scenes into acts so as to control the flow of the scenario. If the ‘Acts’ statement is omitted then the scenes run in the sequence in which the scenes are written. For example, a script has scenes “Start1”, “Start2”, “Start3”, “Middle1”, “Middle2”, “Middle3”, “End1”, “End2”, “End3”. The statement: Acts:(Start1,Start2,Start3),(Middle1,Middle2,Middle3),(End1,End2,End 3)
  • organises the script such that the resulting conversation makes a random choice of “Start1” or “Start2” or “Start3”, followed by a random choice of “Middle1” or “Middle2” or “Middle3”, followed by a random choice of “End1” or “End2” or “End3”. 27 (i.e. 3x3x3) different conversations are possible.
  • Scene: scene_name (optional, multiple entries possible) allows the scripting of scene subunits within the scenario. Different sections of the scenario are appropriately labelled. If it is omitted the whole scenario is labelled “start, start:1, start:2 etc”.

In the simplest form, as seen in the example above, the syntax ‘Character: statement_text’ allows entry of a statement to be spoken by a character. Phrases that make up the conversation content follow the syntax: Role Specifier: {modifiers} spoken_text_custom_spoken_text

This defines a context element, as used in the authoring tool once the script is imported. Generally multiple context elements together specify the complete behaviour of the scenario. When imported, context elements are generated, and each newly generated context element is labelled. The first context element after a ‘Scene: scene_name’ statement is labelled with scene_name, the second context element with scene_name1, the following context element with scene_name:2 and so on.

Role Specifier: introduces the next active role. It can take the following values:

• • Me:—This selects the current active role as the next active role
  • NotMe:—This randomly selects any present role except the current active role as the next active role
  • Any:—This randomly selects any present role as the next active role
  • Prev:—This selects the previous active role as the next active role
  • Next:—This selects the next role to the current active role, in the order in which they joined the conversation, as the next active role. It selects the controller role after the last present role.
  • Transition:—This selects the role indexed by the numeric value stored in an attribute called ‘theme.Transition’ as the next active role
  • Role_name:—This selects the role defined by role-name as the next active role. If role_name has not already been defined by a ‘Role:’ statement then it is implicitly defined with traits=0,0,0,0,0,0,0,0

Modifiers (optional): contains advanced features used to modify the default behaviour of the scenario and allows for the complete control of the script logic, for example by setting the values of attributes, testing attribute values, changing the default behaviour of saying statements, branching and transitioning. This is described in more detail below.

Spoken_text and custom_spoken_text: defines the statements to be spoken. The spoken_text part may be omitted if nothing needs to be said in the context element, but if it is omitted then so must any custom_spoken_text.

The custom_spoken_text part is optional and takes the form: (role_name) spoken_text. The custom_spoken_text part allows the specification of customised statements for the specified role only. The role should be defined before use in any custom_spoken_text. custom_spoken_text may be repeated in a context element for as many roles as required.

The spoken_text part can consist of a choice of statements and/or other statement options as follows:

• • Random choice of statement with ‘|’: Statement1|Statement2|Statement3 etc.—This defines a list of statements with equal weighting.
  • Random weighted choice of statement with ‘|’: |n1 Statement1|n2 Statement2|n3 Statement3 etc.—This defines a list of statements where Statement1 has weighting n1, Statement2 has weighting n2 etc. (where the n1, n2 etc. are the integer values of the weightings)
  • Phrase concatenation with ‘&’: Phrase1&Phrase2&Phrase3 etc.—each statement itself may consist of concatenated phrases
  • Reference to attribute: Phrase1 [attribute1] Phrase2 [attribute2] etc.—this allows a statement to contain phrases and references to attributes so that a doll can say variable things such as the name of the doll that is taking the part of a role, e.g. [me.Name], [prev.Name] or [next.Name].

As seen in the simple example script above play-like scenarios are constructed without any modifiers. The behaviour of some of the features of the example script above are:

• • Acts: (Mall1,Mall2)—organises act1 to consist of either Mall1 or Mall2; when run it makes a random choice of running Mall1 or Mall2
  • Me:—in the fifth line of the example script an empty context element is used to ensure that Mary starts the scenario irrespective of who the controller is.
  • Scene: Mall1—defines scene Mall1
  • Mary: Hi—[next.Name] Thanks for coming!—the context element is labelled as Mall1; the following context elements Mall1:1, Mall1:2 etc. until the next ‘Scene:’ statement.
  • When run:
  • 1) the specified role says the associated statement or it chooses and says one of the statements if a choice is specified with the ‘I’ character;
  • 2) control then passes to the next context element; and
  • 3) the scenario ends after the last context element.

Modifiers

Modifiers (optional) are used to change the default behaviour of the context elements. The syntax for using modifiers is:

Role_specifier: {modifiers} spoken_text_custom_spoken_text

Modifiers can consist of one or more of the following elements, separated by commas where there is more than one modifier. The types of modifier are:

• • Set modifier—this is used to set values to attributes.
  • Condition modifier—this is used to test the value of an attribute and to store a condition value which can be used to modify the subsequent behaviour of the scenario.
  • Say modifier—this is used to modify the default speaking behaviour of the scenario.
  • Branch modifier—this is used to modify the flow of the scenario.
  • Transition modifier—this is used to modify the selection of the next speaker.

The different types of modifier are now described in more detail.

Set modifier—this is used to set values to attributes. It consists of the following text: Set<SetMode,SetList>.

SetMode is one of the following keywords:

• • Random—the selection of values is a random choice.
  • Unique—the selection of values is a random choice with ensured uniqueness.
  • Condition—the selection of values is based on the previous condition value.

SetList is a list of one or more SetStatments separated by commas. A SetStatement consists of the following text:

‘Attribute’ ‘Assignment’ [‘ValueChoice’].

• • ‘Attribute’ is an attribute specification
  • ‘Assignment’ is one of the following:
    • ‘=’ the attribute is set to the choice of value
    • ‘?’ the attribute is set to the choice of value if it is not already set
    • ‘+’ the attribute has the choice of value added to its current value
    • ‘−’ the attribute has the choice of value subtracted from its current value
    • ‘*’ the attribute has the choice of value multiplied by its current value
    • ‘/’ the attribute has its current value divided by the choice of value

‘&’ the attribute has the choice of value added to its current value modulo the number of active dolls.

• • ‘ValueChoice’ consists of a list of one or more ValueSpecifiers separated by commas, where a ValueSpecifier consists of (weight,Value) where
    • weight is an integer used in making random choices and
    • Value can be an attribute, a ‘phrase’ or an integer value.

The following are some examples of Set modifiers:

EXAMPLE 1

• • {Set<Random,
    • theme.dice=[(1,1),(1,2),(1,3),(1,4),(1,5),(1,6)],
    • thene.dicephrase=[(1,‘0’)],
    • theme.dicephrase+[(1,theme.dice)]
  • >}

This causes first a random choice of a value between 1 and 6; then the chosen value is used to specify an appropriate phrase for the chosen value.

EXAMPLE 2

• • {Set<Condition,
    • me.position=[(1,me.position),(1,theme.snake1bottom),
      • (1,theme.snake2bottom),(1,theme.snake3bottom),
      • (1,theme.snake4bottom),(1,theme.snake5bottom)]
  • >}

This causes the me.position attribute to be set to one of the listed values, depending on the current condition value (set by a forgoing condition modifier). For example, if the condition value happens to be 4, then me.position is set to theme.snake4bottom. If the condition value happens to be 0, then me.position is set to me.position, that is, it remains the same.

Condition modifier—this is used to test the value of an attribute and to store a condition value which can be used to modify the subsequent behaviour of the scenario. It consists of the following text: If<‘Attribute’ ‘operator’[‘value list’]>, where

• • ‘Attribute’ is an attribute specification
  • ‘Value list’ is a list of at least one value separated by commas; a value can be a ‘phrase’, an attribute or an integer value
  • ‘Operator’ is one of the following comparison operators:
    • ‘=’ sets the condition value to the index of the first element in the value list which equals the specified attribute (elements are counted starting from 1)
    • ‘<’ sets the condition value to the index of the first element in the value list which is greater than or equal to the specified attribute (elements are counted starting from 1)
    • ‘>’ sets the condition value to the index of the first element in the value list which is less than or equal to the specified attribute (elements are counted starting from 1)
    • ‘#’ sets the condition value to the index of the first element in the value list which is not equal to the specified attribute (elements are counted starting from 1)

If no elements match the condition then the condition operator is set to zero.

The following is an example of a condition modifier:

• • {If<me.position=[theme.snake1top,theme.snake2top,
  • theme.snake3top,theme.snake4top,theme.snake5top]>}

This causes the condition value to be set depending on what the me.position attribute happens to be; for example, if me.position is currently theme.snake4top, then the condition value is set to 4.

Say modifier—this is used to modify the default speaking behaviour of the scenario. It consists of the following text: Say<‘SayMode’,‘Timing’> where:

• • ‘SayMode’ is one of the following keywords:
    • Random—the selection of statements from the spoken text is a random choice.
    • Condition—the selection of statements from the spoken text is based on the previous condition value.
  • ‘Timing’ specifies the timing of the statement choice as follows:
    • 0—the chosen statement is spoken when the current statement has completed.
    • N—the chosen statement starts n/100 of a second after the current statement has started.
    • -N—the chosen statement starts n/100 of a second before the current statement completes.

The default Say behaviour, if no Say modifier is present, is equivalent to Say<Random,0>.

Branch modifier—this is used to modify the flow of the scenario. It consists of the following text: ‘BranchSpecifier’<‘BranchMode’,[‘BranchList’]> where

• • ‘BranchSpecifier’ is one of the following keywords:
    • Goto—Specifies a branch to a label chosen from the BranchList, based on the BranchMode.
    • GoSub—Specifies a branch to a subroutine chosen from the Branchlist, based on the BranchMode.
  • ‘BranchMode’ is one of the following keywords:
    • Random—the selection of labels/subroutines is a random choice.
    • SayChoice—the selection of labels/subroutines is based on the choice made in selecting the statement to say.
    • Condition—the selection of labels/subroutines is based on the existing condition value.
  • ‘BranchList’ is a list of one or more LabelChoices separated by commas. A LabelChoice consists of the following text: (‘eight’,‘label’) where
    • ‘weightw is an integer used in making random choices and
    • ‘label’ is a valid label of a context element or one of the following keywords:
      • Return—specifies a return from a subroutine.
      • End—specifies the termination of the scenario.

For a Goto branch the BranchList is as follows:

[LabelChoice0,LabelChoice1,LabelChoice2,etc.].

For a GoSub branch the BranchList is as follows:

[Return Label,LabelChoice0,LabelChoice1,LabelChoice2,etc.].

Transition modifier—this is used to modify the selection of the next speaker. It consists of one of the following keywords:

• • Me—selects the current active role as the next active role
  • NotMe—randomly selects any present role but the current active role as the next active role
  • Any—randomly selects any present role as the next active role
  • Prev—selects the previous active role as the next active role
  • Next—selects the next role to the current active role, in the order in which they joined the conversation, as the next active role. The controller role is selected after the last present role.
  • Transition—selects the role indexed by the numeric value stored in the attribute called ‘theme.Transition’ as the next active role.
  • Role Name—selects the role defined by Role Name as the next active role.

The default transition behaviour is to use the Role_specifier of the following context element. However, if a branch modifier has been used then the flow does not necessarily continue to the following context element, so it is useful in this circumstance to be able to explicitly set the transition using a transition modifier.

When used together the modifiers must be enclosed in { } and separated by commas.

The following is an example of a Set modifier and a condition modifier used together:

• • {Set<Random,theme.dollcount+[(1,1)]>,
  • If<theme.dollcount>[dolls.Count]>,
  • GoTo<Condition,[(1,setup:4),(1,main)]>}

This causes the dollcount attribute to be increased by one, the condition value to be set in dependence on the dollcount attribute, and then proceed to a context entry (setup:4 or main) in dependence on the condition value.

An example of a script with modifiers and custom_spoken_text that produces a scenario of playing snakes and ladders is presented in Appendix B. When imported this script produces a full snakes and ladders playing scenario for up to 6 roles.

Theme Development

The development features provided in the authoring tool are now described in more detail.

Defining scenario data: the ‘Theme’ form 400 is shown in FIGS. 8 (blank version of form) and 9 (form populated with data). The ‘Theme’ form 400 is used to define, edit and/or remove scenario data.

Defining the theme: to enter a theme the appropriate text is entered in the ‘Theme’ 401 text field.

Defining the topic: to enter a topic the appropriate text is entered in the ‘Topic’ 402 text field.

Defining the scenario ID: to enter a scenario ID (which must be a locally unique integer in the range 1 to 0xffffffff) the locally unique number is entered in the ‘Scenario ID’ 403 text field.

Defining the scenario name: to enter a scenario name the appropriate text is entered in the ‘Scenario Name’ 404 text field.

Defining the scenario description: to enter a scenario description the appropriate text is entered in the ‘Scenario Description’ 405 text field.

Defining theme attributes: the ‘Theme Attribute’ section 406 of the ‘Theme’ form 400. Theme attributes are variables defined at the scenario level. Theme attributes can be used to store information such as phrases or numeric values to aid control over the scenario flow.

• • There are two pre-set theme attributes for every scenario: ‘Name’ and ‘Transition’. These two pre-set theme attributes have special functions, as described in more detail below. User defined theme attributes may be added or removed as follows:
  • Adding theme attributes: to add a theme attribute the ‘Add’ button 407 is selected. This results in the ‘Add Attribute’ form 406a shown in FIG. 14 being displayed. By selecting in the ‘Attribute Name’ text field 406b the name of the attribute is entered. By then selecting the ‘Done’ button 406c the new name is displayed in the ‘Theme Attribute’ list 408. It is not necessary to define the theme attributes at this stage as they can be defined as needed during the context event entries.
  • Removing theme attributes: the attribute to be removed is selected in the ‘Theme Attribute’ list 408. Then the ‘Remove’ button 409 is selected.

Defining Phrases: the ‘Phrases’ section 410 of the ‘Theme’ form 400. Phrases may be defined here at this stage or they may be defined as needed during the context event entries. One advantage of entering phrases at this stage is that it allows control over the order of the phrases. The order of the phrases determines the index used to reference the phrase in the simulator and in the actual doll. Some advanced features require that some phrases must be in a certain order. For example if counting is required in a conversation it is helpful to have the phrases for the integers 1, 2, 3 etc to be in the order N,N+1,N+2, etc

• • Adding phrases: to add phrases the ‘Add’ button 411 is selected. This results in the ‘Add Phrases’ form 410a shown in FIG. 16 being displayed. Phrases may be entered as text with each phrase terminated by a carriage return character. When all the required phrases have been entered the ‘Done’ button 410b is selected. The phrases then are displayed appended to the ‘Phrases’ list 414.
  • Editing phrases: To edit phrases the ‘Edit’ button 412 is selected. This result in the ‘Edit Phrases’ form 412a shown in FIG. 17 being displayed. Phrases may be edited as required. When all the required phrases have been edited the ‘Done’ button 412b is selected. The phrases then are displayed appended to the ‘Phrases’ list 414.
  • Removing phrases: To remove a phrase the phrase is selected in the ‘Phrases’ list 414 and the ‘Remove’ button 413 is selected.
  • Defining the Golden Phrase: To define the Golden Phrase the pull-down arrow is selected in the ‘Golden Phrase’ 415 field, resulting in display of a list of all available phrases and allowing selection of the phrase desired for the Golden Phrase.

Defining roles: the ‘Roles’ section 429 of the ‘Theme’ form 400. Roles are like the virtual characters in a play. All scenarios are developed around a set of characters (roles), where each character plays the part of a defined role in the scenario. Each role can be given a nickname and a representative personality.

• • Adding a role: to add a role the ‘Add’ button 417 is selected and the ‘Add Role’ form 417a, shown in FIG. 18, is displayed. The ‘Description’ text box 417b contains a new default role number. The default role number may be edited to give the new role a nickname; eligible role names are not only numbers, but also text—any name can be used. Defining role nicknames is helpful for a scenario developer as it makes it easier to remember the personality of a named role. The new role can also have a personality set by setting values for each of 8 personality traits 417c. The personality trait values can range from 0 to 15. Each trait represents a different aspect of personality, e.g. introvert/extrovert, funny/serious, talkative/thoughtful etc. Once the role data has been entered the ‘Done’ button 417d is selected.
  • Editing a role: to edit a role the role to be edited is selected in the ‘Roles’ list 416 and the ‘Edit’ button 418 is selected. The ‘Edit Role’ form is displayed. The ‘Edit Role’ form displays the same features as the ‘Add Role’ form 417a, shown in FIG. 18. The role's nickname is displayed in the ‘Description’ field 417b. The role's personality traits 417c are also displayed. The role name as well as the role personality traits may be edited. The ‘Done’ button 417d is selected when all changes have been made.
  • Removing a role: to remove a role the role is selected in the ‘Roles’ list 416 and the ‘Remove’ button 419 is selected.

Defining role attributes: the ‘Role Attributes’ section 430 of the ‘Theme’ form 400. Role attributes are variables defined at the role level. They can be used to store information such as phrases or numeric values to aid the control of the scenario flow.

• • Each role has one pre-set attribute: ‘Name’. This attribute contains a reference to the name of the doll playing this role in a particular instance of the scenario.
  • Adding a role attribute: to add a role attribute the ‘Add’ button 421 is selected. The ‘Add Attribute’ form 406a as shown in FIG. 14 is displayed. The name of the new role attribute is entered in the ‘Attribute Name’ text field 406b and the ‘Done’ button 406c is selected.
  • Removing a role attribute: To remove a role attribute the attribute is selected in the ‘Role Attributes’ list 420 and the ‘Remove’ button 422 is selected.
  • Editing a context list: The actual control of the conversation is handled in the role context entries. Role context entries are accessed with the ‘Edit Context for Role’ field 423. Upon selection of the drop-down arrow, a list of available roles is displayed; upon selection of one of the available roles the so-called context list 500 for that role is displayed, as shown in FIG. 15. The context list 500 is described in more detail below.

Saving a scenario: to save a scenario the “Save” button 424 on the ‘Theme’ form 400 is selected. The scenario must have a valid ID before it can be saved.

Compiling a scenario: to compile a scenario the “Compile” button 425 on the ‘Theme’ form 400 is selected. The scenario must have a valid ID before it can be compiled. The compiler conducts several checks on the context entries before performing the actual compilation, including checks to ensure:

• • all label references are satisfied
  • all attribute references have been defined
  • all phrase references have been defined
  • all branch statements have the required minimum number of values

If any of the above checks fail then an error form is displayed and compilation is aborted. If the compilation succeeds then a “scenario name”.bin file is produced which contains the compiled scenario without any audio data, which is suitable for testing in the simulation tool as described below.

Creating audio data: to create synthesised audio for the scenario the “Create Audio” button 426 on the ‘Theme’ form 400 is selected. This synthesises audio data for all the scenario phrases in each supported voice. Each supported voice must have an associated synthetic voice defined. For audio synthesis conventional audio synthesis software can be used.

Importing audio data: to import recorded audio data for the scenario the “Import Audio” button 427 on the ‘Theme’ form 400 is selected. This opens the ‘Import Audio’ form 427a shown in FIG. 19. The ‘Import Audio’ form 427a facilitates the importing of recorded audio data for the specified voice from a folder specified by the user in the ‘From Folder’ field 427b. The user specified folder must contain the audio files A00006.wav upwards, which represent the audio rendering of each phrase specified in the scenario and listed in the phrases.txt file.

Compiling a scenario with audio data: When testing in the absence of audio data is complete and after the audio data has been either created or imported from recordings and tested in the simulator then the scenario can be compiled with audio data by selecting the “Compile+Audio” button 428. This runs the compiler as described above but producing a “scenario name_v”.bin file. Then it checks that all the audio files defined in the scenario are present for each defined voice. It then compresses all the audio data producing a “audio_vn.bin” file for each voice and then appends the compressed audio data for each voice to the “scenario name_v”.bin file producing a “scenario name_vn”.bin file for each voice n. These files are then available for uploading to the website for subsequent delivery to the dolls.

Context List

The context list for each role is the way in which the logic flow of the scenario is defined. A context list is accessed with the ‘Edit Context for Role’ field 423 of the ‘Theme’ form 400, as described above. A list of available roles is displayed; upon selection of one of the available roles the context list 500 for that role 509 is displayed, as shown in FIG. 15.

By default when a new context entry is entered for any one role it is propagated to all other roles. So by default all roles start with exactly the same entries in their context lists. This is so that scenarios may still function even though some roles are not filled in a particular situation. In this case the existing role players take the part of any missing role at random as required during the flow through the scenario. It is therefore essential that all roles have context entries for the whole scenario even though they are ordinarily not intended to be involved at a particular context entry. For the same reason it is important that all phrases are recorded in all supported voices even though a particular role may not ordinarily be intended to speak a particular phrase.

Given a role with a context list that is populated with context event entries, it is possible to edit the existing context entries. In particular it is possible to program a different response for each role for the same context event entry, thus producing much more interesting and varied results.

The context list 500 consists of a series of context events 507 508. A context event can have entries in one, some, or all of the following fields (corresponding to column headings):

• • Label 501—This is text which defines a label for the context entry. This is mainly used in the branch field. If available the ‘Scene’ name entry is used as the base of the labels for the appropriate entries. If no ‘Scene’ name entry is specified then ‘Start’ is the base text of the labels.
  • Set Attributes 502—This allows a set of attributes (theme or role) to be allocated values according to various rules.
  • Conditions 503—This allows an attribute (theme or role) to be tested for various values and for the resulting condition to influence subsequent actions.
  • Say 504—This is where a choice of statements to be spoke can be specified.
  • Branch 505—This is where the choice of a branch to a new context entry can be specified.
  • Transition 506—This is where the next active doll is chosen.

The function of the different fields of the context events is now described in more detail.

Labels 501: when a new theme is started the context entry for each role begins with the label ‘Start’ 507. As new context entries are added they automatically get the labels ‘Start:1’, ‘Start:2’, etc. The final context entry in the list has the label ‘End’. At any point, for example at label ‘Start:10’, it is possible to change the label. This enables sections to have meaningful labels throughout the theme. If the label ‘Start:10’ is changed to ‘NewLabel’ then as subsequent context entries are added they automatically receive the labels ‘NewLabel:1’, ‘NewLabel:2’, etc.

• • Changing a label: to change a label the ‘Label’ field at the appropriate entry is double-clicked, whereupon the ‘Set Label’ Form 501a shown in FIG. 20 is displayed. The new label is entered in the ‘New Label’ text field 501b and the ‘Save Label’ button 501c is selected.

Set Attributes 502: the ‘Set Attributes’ field for each context entry allows the storing of values to any of the defined attributes. It is also possible to add new attributes at this stage. Attributes may be added at the theme or role level as required. To add, edit, or delete set attributes the ‘Set Attributes’ field of the chosen context entry is double-clicked, whereupon the ‘Set Attributes’ Form 502a shown in FIG. 21 is displayed.

• • Selecting attribute role/theme: the role (or theme) to which the attribute relates is selected by means of the drop-down arrow in the first text box 502c in the ‘Attribute’ section 502b. In the example scenario illustrated in FIG. 9 the following roles (or theme) attributes are available to set:
    • ‘theme’—this indicates that a theme attribute is set
    • ‘me’—this indicates that a role attribute belonging to the current active role is set.
    • ‘prev’—this indicates that a role attribute belonging to the previous active role is set.
    • ‘next’—this indicates that a role attribute belonging to the next active role is set.
    • ‘each’—this indicates that the attribute for each present role is set.
    • ‘all’—this indicates that the attribute for all the roles is set.
    • ‘Mary’—this indicates that a role attribute belonging to the role nicknamed Mary is set.
    • ‘Alice’—this indicates that a role attribute belonging to the role nicknamed Alice is set.
    • ‘Liz’—this indicates that a role attribute belonging to the role nicknamed Liz is set.
    • ‘Evie’—this indicates that a role attribute belonging to the role nicknamed Evie is set.
  • In an illustrative example ‘me’ is selected.
  • Selecting attribute: the attribute is selected by means of the drop-down arrow in the second text box 502d in the ‘Attribute’ section 502b. A list containing the currently available attributes for the role/theme selection is shown. The currently available attributes may include only pre-set attributes such as the ‘Name’ attribute. If it is desirable to create a new attribute the name of the desired attribute can be typed into the second text box 502d. In an illustrative example a role attribute called ‘pet’ is entered. When entry of the set attribute data is completed a new role attribute called ‘pet’ is added to the ‘Role Attributes’ list 420 in the ‘Theme’ form 400.
  • Selecting assignment operator: the assignment operator is selected by means of the drop-down arrow in the ‘Assignment’ text box 502e. The following assignment operators are available to set:
    • ‘?’ sets the value of the attribute to the new value if it is not already set.
    • ‘=’ sets the value of the attribute to the new value irrespective of its current value.
    • ‘+’ adds the new value to the current value of the attribute.
    • ‘−’ subtracts the new value from the current value of the attribute.
    • ‘*’ multiplies the current value of the attribute by the new value.
    • ‘/’ divides the current value of the attribute by the new value.
    • ‘&’ adds the new value to the current value of the attribute modulo the number of present dolls.
  • In an illustrative example ‘=’ is selected.
  • Selecting assignment value: the new value is defined in the ‘Value’ section 502m of the ‘Set Attributes’ Form 502a. The assignment value type is selected by means of the drop-down arrow in the ‘Value’ text box 502f. The following assignment value types can be selected:

phrase    for a phrase reference.
attribute for a new value that is the same as another
          attribute.
numeric   for an arithmetic value in the range 0 to 0xfff.
dolls     for information concerning the present dolls.
null      for the null reference (0x5000).

• • Once the value type is specified, the value is entered by means of a form particular to each type of value. The entry of different types of values is described in more detail below. A weight can be associated with a value by means of the ‘Weight’ field 502i. After the value has been entered it is shown in the ‘Values’ list 502g. As shown in FIG. 21, more than one value can be entered; in the example, the values ‘dog’, ‘cat’, ‘bunnie’, and ‘gerbil’ have been entered.
  • Selecting assignment method: if more than one value has been entered, then one of them is chosen for assignment. The method of choosing is selected by means of the drop-down arrow in the ‘Method’ text box 502h. The following methods are available to set:
    • Condition: the choice of values for all the set attribute entries is based on the previous context entry's conditions. This is described in more detail below, but briefly the conditions sets a condition value as follows:
      • 0 if none of the conditions are met
      • 1 if the first condition is met
      • 2 if the second condition is met
      • . . . and so on
    • If the method is set to Condition then the choice of value is the first value if condition=0, the second value if condition=1, and so on. The weights are ignored by the condition method.
    • Random: the choice of values for all the set attribute entries is the weighted random choice from the value list provided for each set attribute entry. The default weight value is 1 (causing all values to be equally weighted by default) and can be changed with the ‘Weight’ field 502i.
    • Unique: the choice of values for all the set attribute entries are randomly selected as above, but are constrained so that each role receives a unique value.
  • Adding set attribute: once the list of values with weights in the ‘Values’ list 502g is complete and the required data has been specified, the “Add Set Attribute” button 502j in the Set Attributes section is selected to add the set attribute. The new set attribute is shown in the ‘Set Attributes’ list 502k, and the upper part of the form is returned to its default without previous entries being shown. In the illustrated example the new set attribute entry is: “me.pet=[(1,‘dog’),(1, ‘cat’),(1,‘bunnie’),(1,‘gerbil’),]” meaning that me.pet receives an assignment by random choice from ‘dog’, ‘cat’, ‘bunnie’ or ‘gerbil’.
  • Saving set attribute: once all set attribute entries have been made the ‘Save Set Attributes’ button 502l is selected. The display then returns to the context entry list 500 where the updated set attributes entries are shown. FIG. 22 shows for the illustrative example described above the updated ‘Set Attributes’ field 510 for the context entry.

Conditions 503: the ‘Conditions’ field 503 in the context entry list enables testing of the value of a chosen attribute by comparing it in various ways to a set of other values. This allows changes to the subsequent flow of the theme in dependence on the value of any attribute. When a context entry is processed the ‘Conditions’ field causes a condition variable to be set as follows:

• • 0 if no conditions are met
  • 1 if the first condition is met
  • 2 if the second condition is met and no previous condition is met
  • . . . and so on.

The value of the condition variable can be used in the ‘Say’ field, in the ‘Branch’ field and in subsequent ‘Set Attribute’ fields to determine the outcome. To add, edit, or delete conditions the ‘Conditions’ field of the chosen context entry is double-clicked, whereupon the ‘Conditions’ form 503a shown in FIG. 23 is displayed.

• • Selecting condition attribute: an attribute is specified using the drop-down lists and the text boxes in the ‘Attribute’ section 503b, as per the ‘Set Attribute’ form 502a described above.
  • If the ‘each’ type attribute has been selected then the attribute for each present role is tested against the first value specified and the condition value is set as follows:
    • 0—if the comparison fails for every present role.
    • 1—if the comparison succeeds for role0.
    • 2—if the comparison succeeds for role1
    • . . . and so on.
  • If the ‘all’ type attribute has been selected then the attribute for each role, whether present or not, is tested against the first value specified and the condition value is set as follows:
    • 0—if the comparison fails for every role.
    • 1—if the comparison succeeds for role0.
    • 2—if the comparison succeeds for role1
    • . . . and so on.
  • Selecting condition type: the assignment method is selected by means of the drop-down arrow in the ‘Assignment’ text box 503f. The following assignment methods are available to set:
    • ‘=’ means that the selected attribute is tested for equality against the list of values.
    • ‘#’ means that the selected attribute is tested for inequality against the list of values.
    • ‘<’ means that the selected attribute is tested as being less than the list of values.
    • ‘>’ means that the selected attribute is tested as being greater than the list of values.
  • The list of values used for comparison is built by means of selecting the value drop-down arrow.
  • Selecting condition value: the condition value type is selected by means of the drop-down arrow in the ‘Value’ text box 503c. The following condition value types can be selected:

phrase    for a phrase reference.
attribute for a new value that is the same as another
          attribute.
numeric   for an arithmetic value in the range 0 to 0xfff.
dolls     for information concerning the present dolls.

• • Once the condition value type is specified, the condition value is entered by means of a form particular to each type of value, same as selection of a value in the ‘Value’ section 502m of the ‘Set Attribute’ form 502a described above. After the condition value has been entered it is shown in the ‘Values’ list 503d.
  • Saving condition: when all condition data has been entered the ‘Save Condition’ button 503e is selected. The display then returns to the context entry list 500 where the updated condition is shown.

Say 504: the ‘Say’ field 504 in the context entry list 500 enables specification of a list of statements that may be spoken by the active doll at a specific context entry. To add or edit statements the ‘Say’ field of the chosen context entry is double-clicked, whereupon the ‘Say’ form 504a shown in FIG. 24 is displayed.

• • Selecting statement method: a method is specified according to which a particular statement to be spoken is selected from a list of statements. The available methods are ‘Random’ and ‘Condition’. The method is chosen by means of the ‘Method’ drop-down arrow 504b. If the method is ‘Random’ then the statement is selected as a weighted random choice from the list of statements. If the method is ‘Condition’ then the statement is selected according to the condition variable set by the ‘Conditions’ field. Weight values can be allocated to phrases with the ‘Weight’ field 504c.
  • Selecting statement phrases: Each statement can consist of a list of phrases. Phrases are added to a statement by selecting the ‘Phrase’ drop-down arrow 504d. The following phrase types can be selected:

phrase    for a phrase
attribute for an indirectly reference to a phrase that has
          previously been stored in an attribute.
numeric   for specification of a period of silence as a
          phrase. A value of n means a silence of n/100 seconds.

• • Once the phrase type is specified, the phrase is entered by means of a form particular to each phrase type. The entry of different phrase types is described in more detail below (the same entry forms are used as for specifying an assignment value in dependence on the value type 502f in the ‘Set Attribute’ form 502a described above). After the phrase has been entered it is shown in the ‘Values’ list 504e. Further phrases may be entered by the same procedure. When all the phrases needed for a particular statement have been entered then the ‘Add Statement’ button 504f may be selected to add the statement (with the weight if applicable) into the ‘Statements’ list 504i. The above may be repeated to add more statements to the ‘Statements’ list 504i.
  • Selecting statement timing: control of the timing of spoken statements is enabled by the ‘Timings’ field 504g. A timing value of 0 indicates a follow-on event, wherein the spoken statement starts when the previous spoken statement finishes. A positive timing value of n means that the spoken statement starts n/100 seconds after the previous spoken statement starts. A negative timing value of n means that the spoken statement starts n/100 seconds before the previous spoken statement finishes.
  • Saving statement: when all statements and statement data have been entered the ‘Save Statement’ button 504h is selected. The display then returns to the context entry list 500 where the updated ‘Say’ data is shown.

Branch 505: the ‘Branch’ field 505 in the context entry list 500 allows specification of a list of possible context entries for the scenario control to pass to. For ease of analysing the scenario flow a branch highlighting function is provided. Upon selection of a context entry all other context entries that correspond to each of the defined branch labels are highlighted. This is useful for finding the location of the target of branches when editing a complete scenario. To add or edit branch data the ‘Branch’ field 505 of the chosen context entry is double-clicked, whereupon the ‘Branch’ form 505a shown in FIG. 25 is displayed.

• • Branch type selection: the branch type is selected by means of the drop-down arrow in the ‘Branch Type’ field 505b. There are two types of branch:
    • Goto: the Scenario flow jumps to a new location (chosen from the list of locations) based on the chosen method.
    • Gosub: the Scenario flow remembers a return location, specified by the first location in the list, and jumps to a new location (chosen from the remaining locations in the list of locations) based on the chosen method.
  • Branch method selection: the branch method is selected by means of the drop-down arrow in the ‘Branch Method’ field 505c. There are three methods for choosing a new location from the list of locations:
    • Random: the new location is chosen as a weighted random choice from the available list of locations (the complete list for Goto, the complete list except the first entry for Gosub). Weight values can be allocated to branches with the ‘Weight’ field 505d.
    • SayChoice: the new location is chosen based on the choice made for the ‘Say’ field 504 in the context entry list 500. For example if the ‘Say’ field 504 has selected the third statement of its statements list, then the new location to which the conversation is branched is the third entry in the location list for a Goto or the fourth (3+1) entry for a Gosub.
    • Condition: the new location is chosen based on the condition variable as set by the ‘Conditions’ field 503 in the context entry list 500. For example if the conditions variable=n then the new location is the (n+1)th entry in the list for a Goto or (n+2)th list entry for a Gosub.
  • Branch location selection: possible locations to which the branching may occur are selected by means of the drop-down arrow of the ‘Branch’ field 505e. All available existing labels are subsequently shown for selection in the drop-down list. Also, a ‘Return’ location is available for selection; this causes the branch to pass (back) to the return location stored when a Gosub branch is active. Further, it is possible to add a new label by entering it into the text box of the ‘Branch’ field 505e, however the appropriately labelled Context entry must be added manually (the compiler otherwise provides warnings of any unsatisfied branch locations at compilation time). After the branch information has been entered the ‘Add Branch’ button 505f is selected whereupon the new branch is shown in the ‘Values’ list 505h.
  • Saving branch: when the complete list of possible branch locations has been entered and all branch data has been specified the ‘Save Branch’ button 505g is selected. The display then returns to the context entry list 500 where the updated branch data is shown in the ‘Branch’ field 505.

Transition 506: the transition field 506 in the context entry list 500 allows specification of how the next active doll is chosen. To add or edit a transition the ‘Transition’ field of the chosen context entry is double-clicked, whereupon the ‘Transition’ form 506a shown in FIG. 26 is displayed. The following choices are available:

• • Me: the next active doll remains the same as the current active doll.
  • Prev: the next active doll is the same as the previous active doll.
    • NotMe: the next active doll is chosen at random from all present dolls except the current active doll (Me).
    • Any: the next active doll is chosen at random from all present dolls.
    • Next: the next active doll is the doll with the next index in the list of present dolls. When the end of the list of present dolls is reached it starts again from the beginning.
    • Transition: the next active doll is the doll corresponding to the index into the list of present dolls stored in the Theme.transition attribute.
    • (in the example illustrated above) Mary: the next active doll is the doll playing the role nicknamed Mary.
    • (in the example illustrated above) Alice: the next active doll is the doll playing the role nicknamed Alice.
    • (in the example illustrated above) Liz: the next active doll is the doll playing the role nicknamed Liz.
    • (in the example illustrated above) Evie: the next active doll is the doll playing the role nicknamed Evie.

Once a selection has been made the transition is automatically saved in the ‘Transition’ field 506 of the context entry.

In the simulations and in the actual doll the fields of the context event entries are processed in the following order: Transition, Set Attributes, Conditions, Say, and Branch.

In the exemplary context list 500 shown in FIG. 15 the first context entry 507, labelled ‘Start’, is processed as follows:

• • Transition—Mary—This chooses the role nicknamed Mary as the next active doll.
  • Set Attributes—null—No action.
  • Conditions—null—No action.
  • Say—null—No action.
  • Branch—Goto<Random,[(1,Mall1),(1,Mall2)]>—This means that control passes to the context entry labelled ‘Mall1’ or ‘Mall2’ chosen randomly according to the list of weights and labels inside the bracketed expression.

The result of processing context entry ‘Start’ 507 is to select the role nicknamed Mary as the active doll and then branch to context entry labelled either Mall1 or Mall2. The purpose of this context entry ‘Start’ 507 is to make sure that the conversation always begins with the role nicknamed Mary. In the real situation with actual dolls the controller doll starts the conversation and any of the dolls may be the controller—and the controller doll may assume another role than the role nicknamed Mary. This first entry, where no say statement occurs, silently changes the active doll (the default active doll at conversation initialisation being the controller doll) to the role nicknamed Mary, regardless of which role the controller doll has assumed.

In the above example the second context entry 508, labelled ‘Mall1’, is processed as follows:

• • Transition—Alice—This chooses the role nicknamed Alice as the next active doll.
  • Set Attributes—null—No action.
  • Conditions—null—No action.
  • Say—Say<Random,0,[(1,” hi—“,next.Name,” thanks for coming!”)]>—This means that the statement consisting of the phrases “hi—”, the next active doll's name (in this case the name of the doll taking the role nicknamed Alice), “thanks for coming!” is spoken by the doll taking the part of the role nicknamed Mary. The ,0, after the word Random indicates that this is a “Follow-On” event so that the statement is spoken at the end of any previous statement.
  • Branch—Goto<Random,[(1,Mall1:1)]>—This means that control passes to the context entry labelled Mall1:1.

The result of processing context entry ‘Mall1’ is to:

• • 1. select the doll playing the role nicknamed Alice as the next active doll,
  • 2. use the doll playing the role nicknamed Mary to speak the statement “hi—“,The name of the doll playing the role nicknamed Alice,” thanks for coming!”,
  • 3. branch to context entry labelled Mall1:1.

The process continues processing the appropriate context entries for each active doll at the chosen labels until it reaches the end.

Context List Menu

The context list form 500 as shown in FIG. 15 provides a menu 511 with various operations pertaining to the context list 500. The following operations are available:

• • Clear Field: replaces a chosen field with null
  • Copy Field to All Roles: copies the data in a chosen field to the equivalent field in all the other roles' context list.
  • Insert Row: inserts a new row at the chosen location.
  • Remove Row: removes a selected row.
  • Copy Selected Rows: makes a copy of selected rows in a clipboard.
  • Cut Selected Rows: makes a copy of selected rows in a clipboard and remove them from the context list.
  • Paste Rows: inserts the rows on the clipboard into the context list at the chosen location.
  • Find text in cells: opens a search form that allows the searching of the context entries for any chosen text. The search may be specified as progressing forwards or backwards through the list starting from the currently selected cell. This operation can be useful for editing completed scenarios.

Input Forms

The input forms for the different types of entries (phrase, attribute, numeric, dolls, null) are now described in more detail.

Input Form: Phrase

Phrases are added with the ‘Choose Phrase’ form, as shown in FIG. 27. Selecting the drop-down arrow in the ‘Phrase’ field 600 causes a drop-down list to be shown with the already defined phrases. Instead of selecting one of these, a new phrase may be entering by typing the phrase into the text box of the ‘Phrase’ field 600 and then selecting a ‘Save Phrase Choice’ button (not shown).

Input Form: Attributes

Attributes are added with the ‘Choose Attribute’ form, as seen in FIG. 28. Selecting the drop-down arrow in the first ‘Attribute’ field 601 causes a drop-down list to be shown with a list of available roles/themes:

• • Theme: a theme attribute value is used
  • Me: a role attribute value belonging to the current active role is used
  • Prev: a role attribute value belonging to the previous active role is used
  • Next: a role attribute value belonging to the next active role is used
  • (in the example illustrated above) Mary: a role attribute value belonging to the role nicknamed Mary is used
  • (in the example illustrated above) Alice: a role attribute value belonging to the role nicknamed Alice is used
  • (in the example illustrated above) Liz: a role attribute value belonging to the role nicknamed Liz is used
  • (in the example illustrated above) Evie: a role attribute value belonging to the role nicknamed Evie is used

Selecting the drop-down arrow in the second ‘Attribute’ field 602 causes a drop-down list to be shown with a list of available attributes for the selected role/theme. As an example if in the first ‘Attribute’ text box 601 ‘Theme’ is selected, the second ‘Attribute’ text box 602 shows the following choices:—

• • Name
  • Transition
  • Test

These three attributes are the existing defined theme attributes in this example.

Instead of selecting attributes from a drop-down list, a new attribute may be entering by typing the attribute name into the text box of the second ‘Attribute’ field 602.

When the desired theme attribute has been specified the “Save Attribute Choice” button 603 is selected, causing the ‘Choose Attribute’ form to close and returns to the previous form where the chosen attribute is now listed.

Input Form: Numeric Values

Numeric Values are added with the ‘Choose Numeric’ form, as shown in FIG. 29. Numeric values in the range 0 to 0xfff can be entered in or selected with the arrows of the ‘Set Value’ field 604. When the desired value has been specified, selecting the “Save Value” button 605 causes the ‘Choose Numeric’ form to close and returns to the previous form where the chosen numeric values is now listed.

Input Form: Doll Data

Information relating to present dolls is added with the ‘Choose Dolls Data’ form, as shown in FIG. 30. The ‘Choose Dolls Data’ field 606 provides a list of doll information, such as:

• • Count: a numeric value equal to the number of present dolls.
  • Me: a numeric value equal to the index of the current active doll.
  • Prev: a numeric value equal to the index of the previous active doll.
  • Next: a numeric value equal to the index of the next active doll.

When the desired doll data has been specified, selecting a “Save Dolls Data” button (not shown) causes the ‘Choose Dolls Data’ form to close and returns to the previous form where the chosen doll data is now listed.

Theme Testing

Once a scenario has been compiled it can be tested on a computing device. This can be done both before and after audio data is available. If testing is done before any audio data is available then the test simulator prints (or otherwise displays) the text that would be spoken. If testing is done after audio data is made available then the test simulators speak the phrases as well as printing/displaying the text.

Testing a scenario (after compiling) starts in the main ‘Theme Development’ window 300 shown in FIG. 7. Selecting the drop down arrow of the ‘Choose a Toy to Start—ID’ text box 311 in the ‘Theme—testing’ section 310 causes a list of doll ID numbers to be displayed. The number of ID entries in the list is the same as the number of roles defined in the scenario.

The doll IDs displayed refer to the Dolls folder in the Theme Data Directory.

There are sub-folders for each Doll ID and these sub-folders each contain a doll data file named ‘MyData.txt’. The doll data file contains the following data:

The doll's name in text          e.g. Allison
The audio reference to the doll's name as a hex string e.g. 6002
The doll's personality as a hex string e.g. 1
The name of the doll's voice in text e.g. Voice1
The count of the number of conversations entered e.g. 450

The doll data file allows the simulator connected to a chosen doll ID to be able to display meaningful information.

If Doll ID 00000001 is selected then in an illustrative example the simulation window shown in FIG. 31 is displayed. This example shows a simulation window for a doll called Allison, and as this is the first doll started it is the Controller, as also displayed in FIG. 31. Also shown is the fact that Allison has taken role 0 and her name audio reference number is 6002. Each entry is time stamped from the start of the particular simulator.

If now Doll ID 00000002 is selected then in the illustrative example the simulation window shown in FIG. 32 is displayed. This example shows a simulation window for a doll called Courtney, and as this is not the first doll started it is the client, as also displayed in FIG. 32. Also shown is the fact that Courtney successfully takes role 1 and her name audio reference number is 6003.

When a second simulator is started, a line in the controller simulation is added indicating that an active doll has joined the conversation and has taken role 1 and its name audio reference is 6003.

Further doll simulations can be added up to the total number of roles supported in the scenario. The scenario can also be simulated with only some roles taken. The conversation can be started and dolls added while it is running; dolls can also be removed while the simulation is running. This allows a thorough test of all the events that might happen with real dolls.

The conversation is started by selecting the “Start” button 701 in any of the simulation windows.

The conversation proceeds and the controller window (Allison in our example) displays text as shown in FIG. 33. The conversation start is indicated with an entry “Chat init” 702. Diagnostic messages 703 follow, in the illustrated example pending phrase data and duration data. The statements 704 follow, including display of information regarding what is spoken and who speaks it.

The client simulation (Courtney) displays an output similar to the output on the Controller simulation, but only shows the text for what Courtney says.

The conversation may be paused and continued by selecting the “Start” button 701. It can be stopped by selecting the “Stop” button 705 and re-started by selecting the “Start” button 701.

A client doll may be removed from the conversation by selecting the “Exit” button 706 in its simulation window. If the controller “Exit” button is selected then the test is terminated and all simulation windows are closed.

After a scenario is tested log files of the simulation output for each doll are stored in the Theme folder for subsequent study.

This simulation testing allows rapid testing of a scenario followed by direct editing to correct any problems followed by re-testing until the scenario produces the desired results.

Theme Publishing

This allows interaction with the website to allow uploading of scenarios, voices and names. When the ‘Publish’ menu item 305 in the main ‘Theme Development’ window 300 shown in FIG. 7 (as described above with reference to FIG. 7) is selected the ‘Publish’ form 800, as seen in FIG. 10, is displayed. The ‘Publish’ form contains the following controls:

• • Scenarios 801: Lists the Themes/Topics/Scenarios stored on the website.
  • Voices 805: Lists the Voices stored on the website.
  • Names 806: Lists the Names stored on the website.
  • Upload Scenario 807: Uploads the currently opened scenario to the website.
  • Upload Voice 808: Uploads the selected voice to the website.
  • Upload Name 809: Uploads the selected name to the website.

These functions are described in more detail below.

Scenarios

When the ‘Scenarios’ button 801 is selected a request is sent to the website to retrieve all Theme/Topic/Scenario information. If a connection to the website has not already been made then a login prompt is displayed first.

Once retrieved, the ‘Publish’ form shows the Theme/Topic/Scenario information, as shown in FIG. 34. The Theme/Topic/Scenario information is displayed in a tree structure with the following hierarchy:

• • theme name (ThemeID)
    • topic name (TopicID)
      • scenario data
        • scenario name
        • scenario description
        • Golden Phrase
        • whether the scenario is in test mode

Scenarios, topics and themes may be edited or deleted by first selecting the required theme, topic or scenario name, then selecting the ‘Delete’ button 802 or the ‘Edit’ button 803.

Editing a Scenario: when the ‘Edit’ button 803 is selected with a scenario selected the ‘Edit Scenario Text’ form shown in FIG. 35 is displayed. Fields are provided that allow modification of the name, description, topicID and/or development status of the scenario. When the ‘OK’ button is selected changes are sent to the website and the display updated accordingly.

Deleting a Scenario: when the ‘Delete’ button 802 is selected with a scenario selected then the scenario is deleted from the website.

Editing a Topic: when the ‘Edit’ button 803 is selected with a topic selected the ‘Edit Topic Text’ form seen in FIG. 36 is displayed. Fields are provided that allow modification of the name, description and/or themeID of the topic. When the ‘OK’ button is selected any changes are sent to the website and the display updated accordingly.

Deleting a Topic: when the ‘Delete’ button 802 is selected with a topic selected then the topic is deleted from the website, provided that it contains no scenarios. If it contains scenarios a message is displayed informing the user to delete the scenarios before deleting the topic.

Editing a Theme: when the ‘Edit’ button 803 is selected with a theme selected the ‘Edit Theme Text’ form seen in FIG. 37 is displayed. Fields are provided that allow modification of the name and/or description of the theme. When the ‘OK’ button is selected any changes are sent to the website and the display updated accordingly.

Deleting a Theme: when the ‘Delete’ button 802 is selected with a theme selected then the theme is deleted from the website, provided that it contains no topics. If it contains topics a message is displayed informing the user to delete the topics before deleting the theme.

Voices

When the ‘Voices’ button 805 is selected a request is sent to the website to recover all the voice information. If a connection to the website has not already been made then a login prompt is displayed. The voice information is displayed in the ‘Publish’ form as illustrated in FIG. 38.

Editing a Voice: when the ‘Edit’ button 803 is selected with a voice specified the ‘Edit Voice Text’ form shown in FIG. 39 is displayed. A field is provided that allows modification of the voice description. When the ‘OK’ button is selected any changes are sent to the website and the display updated accordingly.

Deleting a Voice: when the ‘Delete’ button 802 is selected with a voice specified then the voice is deleted from the web-site.

Names

When the ‘Names’ button 806 is selected a request is sent to the website to recover all the name information. If a connection to the website has not already been made then a login prompt is displayed. The name information is displayed in the ‘Publish’ form as illustrated in FIG. 40.

Editing a Name: when the ‘Edit’ button 803 is selected with a voice specified the ‘Edit Name Text’ form shown in FIG. 41 is displayed. A field is provided that allows modification of the name. When the ‘OK’ button is selected any changes are sent to the website and the display updated accordingly.

Deleting a Name: when the ‘Delete’ button 802 is selected with a name specified then the name is deleted from the website.

Upload Scenario

When the ‘Upload Scenario’ button 807 is selected requests are sent to the web-site in order to upload the currently opened scenario data. If no scenario is currently open then a message is displayed informing the user to open a scenario first. A check is made to determine if a scenario with the current scenario name in the current theme and topic already exists on the website. If it does not then the scenario is created on the website. The theme and topic are also created on the website if they do not already exist. Then the scenario binary files for each supported voice are uploaded to the website. If the theme/topic/scenario already exists on the website then a request is displayed asking the user if they wish to modify the existing scenario. If the user selects ‘yes’ then a query is displayed asking the user if they wish to upload new binary files. If the user selects ‘yes’ to this query then any changes to the scenario description, golden phrase and test status are uploaded to the website followed by the new binary files. If the user selects ‘no’ then only the changes to the description, golden phrase and test status are uploaded.

Upload Voice

When the ‘Upload Voice’ drop down arrow 808 is selected a list of supported voices is displayed. If a voice is selected then requests are sent to the website in order to upload the voice. A check is made to determine if the voice currently exists on the website. If it does not then the voice is created and the sample audio file is uploaded to the website. If the voice currently exists on the website then a request is displayed asking the user if they wish to change the sample file. If the user selects ‘yes’ then the new sample file is uploaded.

Upload Name

When the ‘Upload Name’ drop down arrow 809 is selected a list of supported names is displayed. If a name is selected then requests are sent to the website in order to upload the name and its audio representation in each supported voice. A check is made to determine if the name currently exists on the website. If it does not then the name is created and the audio representation file in each supported voice is uploaded to the website. If the name currently exists on the website then a request is displayed asking the user if they wish to change the audio representation files. If the user selects ‘yes’ then the new audio representation files are uploaded.

Log

When the ‘Log’ button 804 is selected a log of the website communication is displayed in the ‘Publish’ form as illustrated in FIG. 42. The log display can be hidden by selecting the ‘Log’ button 804 again or by selecting the ‘Scenarios’ button 801, the ‘Voices’ button 805 or the ‘Names’ button 806.

Theme Voice Maintenance

This allows the maintenance of the voices supported by the development tool. When the ‘Voices’ menu item 307 in the main ‘Theme Development’ window 300 shown in FIG. 7 (as described above with reference to FIG. 7) is selected the ‘Voice Maintenance’ form 820 is displayed, as illustrated in FIG. 11.

The ‘Voice Maintenance’ form 820 allows voices to be added or deleted. The Description field 824 for each voice can be entered and modified. The voice can support audio synthesis if a text-to-speech voice is specified. If audio synthesis is supported the audio sample may be created with the “Create” button 823. In this case the audio sample created is the audio synthesis of the text in the voice description field 824 (e.g. in the illustrated example the audio sample would speak the phrase “Fruity and yet quite smooth but not too”). Alternatively a recording of sample audio data can be indicated so that it can be copied into the development system. When a voice is added it is given the name “VoiceN” where N is the next available number, making sure any gaps are filled. The “Browse” button 821 allows the sample audio data to be located anywhere on the computer and the “Sample” button 822 allows the selected audio data to be heard as a check that it is the correct audio data.

Theme Name Maintenance

This allows the maintenance of the names supported by the development tool. When the ‘Names’ menu item 308 in the main ‘Theme Development’ window 300 shown in FIG. 7 (as described above with reference to FIG. 7) is selected the ‘Names Maintenance’ form 810 is displayed, as illustrated in FIG. 12.

The ‘Names Maintenance’ form 810 allows names to be added (with the ‘Add Name’ button 817) or deleted (with the ‘Delete’ button 818). If the chosen voice supports audio synthesis then the audio data for the name can be created and compressed either for each supported voice or for all supported voices. Alternatively a recording of the name in the selected voice can be indicated so that it can be copied into the development system and compressed appropriately. The ‘Browse’ button 815 allows the audio representation to be located anywhere on the computer and the ‘Sample’ button 816 allows the selected audio data to be heard as a check that it is the correct audio data. When the ‘Add Name’ button 817 is selected a form is displayed in which a name can be entered. A new name is entered in the following format ‘n: name_text’ where n is the index that is used to reference the name, and name_text is the actual name. The n index should start at 1 and it must be unique; gaps are allowed but serve no useful purpose.

Stock Phrase Maintenance

This allows the maintenance of the stock phrases supported by the development tool. When the ‘Stock Phrases’ menu item 309 is selected the ‘Stock Phrase Maintenance’ form 830 is displayed, as illustrated in FIG. 13.

The ‘Stock Phrase Maintenance’ form 830 allows stock phrases to entered or modified in the ‘Phrase’ field 832. The ‘Event’ field 831 allows selection of dolls for which the stock phrases are to be modified, in the illustrated example for only one doll. If the chosen voice supports audio synthesis then the audio data for the stock phrase can be created and compressed either for each supported voice or for all supported voices. Alternatively a recording of the stock phrase in the selected voice can be indicated so that it can be copied into the development system and compressed appropriately. The ‘Browse’ button 833 allows the audio representation to be located anywhere on the computer and the ‘Sample’ button 834 allows the selected audio data to be heard as a check that it is the correct audio data.

An example of development of a board game scenario with the authoring tool is presented in Appendix C.

Simplified Authoring Tool

A simplified authoring tool provided to a user enables the user to generate personalised scenarios. The user writes a scenario with a simple scripting language. In one example, the scenario is written like a play. The user can also be provided with more advanced functionality in which the user can specify particular phrases for a character. The script is imported and the scenario data is generated by the authoring tool as described above.

The simplified authoring tool can also provide facilities for generating the audio file. The user may be provided with the option of recording the phrases, for instance with a microphone connected to a computing device. The simplified authoring tool can provide prompts and instructions for the recording of phrases. If different voices are required for different dolls, then it may be necessary to record the dialogue phrases in more than one voice.

Instead of recording phrases, the simplified authoring tool can provide facilities for synthesising audio data. If audio files are required for multiple voices this may be more efficient than recording. Audio synthesis can be performed for preset voices with no further user involvement. Alternatively, the voice for which the audio data is to be synthesised can be specified by the user, or the user can select predefined voices from a list. For example, the user might choose to create a scenario with the roles of The Simpsons™, to be played with The Simpsons™ dolls, in which case the appropriate voices of the characters in The Simpsons™ would be used.

Templates may be provided to facilitate the scripting of scenarios. A template is a predefined skeleton scenario, where the user is prompted to fill in information to create the complete scenario. The skeleton scenario can be structured such that conversation branching in supported, to give the impression of randomness.

To guide the user the template can provide a variety of pre-prepared options, for example a selection of possible phrases from which the user can choose a desired sub-set of phrases. Selection can occur by providing a graphical user interface that allows a user to visually select desired phrases, for example, by dragging and dropping, by marking a radio button, by selecting a button, or by other means. The sequence of speakers can follow a regular and predetermined pattern, such as A-B-A-B. This allows a simple but efficient text-based graphic user interface, where the user only needs to select the next phrase to be spoken from a pool of possible phrases.

By providing users, particularly children, with the ability to prepare their own scenarios, the doll can become more attractive and fun to play with, and provide a more engaging and exciting experience for users. Furthermore, as users have a creative hand in making their own stories the educational value is also enhanced.

The ‘Story Creator’ utility or tool takes the form of a graphic authoring tool. Users can create their own stories using a combination of setting options, text, and selections. A graphical user interface, comprising a storyboard or comic strip is provided for receiving input from a user, and providing guidance and options to the user for user selection. FIGS. 43a and 43b illustrate the storyboard with comic strip-like representation of conversation elements. A storyboard is composed of a number of panels, with each panel defining a small section of a scenario. A storyboard represents a scenario in its entirety.

The comic strip-like representation provides an easy to understand interface that allows the user to graphically set parts of the scenario, such as speaker sequence and theme. The storyboard also provides the user with an intuitive representation of the user's choices and settings, and also of the scenario itself as it develops. The Story Creator tool enables the user to produce data that can be converted and imported to a doll, without requiring specialist knowledge of the system. The limited nature of the storyboard also enables the length and complexity of a scenario to be regulated so as to comply with limitations of the dolls.

The stories can be stored and shared with other users, which adds additional value for a user. The stories a user creates can be entered into a monthly competition to win story of the month. An incentive can be awarded for completing and creating a new scenario.

The Story Creator tool is an online utility that is part of a larger interactive doll website accessible by users via a computing device. When a user accesses a particular area of the website, a map is displayed providing a number of possible locations, such as an ice cream parlour, a beach, and a pony stable. A user accesses the tool by selecting a location on the map. This enables pre-selection of a setting, corresponding to the theme of the scenario, for example, an ice cream parlour, the beach, or pony stables.

The Story Creator may provide the option of defining an element of the ‘plot’, corresponding to a topic, for example: ‘having a talent competition’; ‘finding a surprise’; or ‘having a snack’. A choice of setting (and possibly plot) can inspire the user, and it also enables the Story Creator tool to filter the panels and phrases that are available to the user, thus making the tool more easy to use. A pre-defined story template may also be provided, with the scenario only partially incomplete.

Selection of a setting causes the Story Creator tool to load. The Story Creator tool contains any previously saved scenarios and the option to create a new scenario. Once the setting (and optionally the plot) has been set, the Story Creator tool displays panels with characters (corresponding to roles in the scenario) in the selected setting (corresponding to the theme or topic of the scenario). A storyboard can include for example 20 panels as a default, with the option of adding further panels if required. In FIG. 43a, a storyboard view 2000 displays three panels 2002, with each panel 2002 showing two characters 2008 that represent roles that can be played by the dolls. The user can navigate through the whole storyboard with next/previous buttons 2010.

The user is able to select from different panels types. This allows the user to choose how many characters participate in the conversation; whether they are speaking at the same time or one after the other; and the order in which they talking. The panel that the user chooses in one section may restrict the panels they can choose subsequently so that the story flows correctly. Optionally, the Story Creator tool provides resources for the user to generate, modify, and save personalised panels.

The background image 2006 of the panels 2002 represents the setting that is representative of the theme, in the illustrated example ‘at the beach’. Optionally, a choice of setting can cause a menu of sub-options (or topics) to become available for selection; for example, if the setting ‘at the mall’ is selected, then the options ‘In a clothes shop’, ‘At the ice-cream parlour’, and ‘In the car park’ are made available.

The characters 2008 depicted in the panels 2002 can be selected by a user and later adapted using a menu. This allows the user to choose a representation that matches a particular doll. Options include for example the user's avatar, a friend's avatar, and a mentor. Optionally, if a friend's avatar is selected, the user can invite the friend to co-create the scenario. Contextual information can be used to adapt the character to a user's own doll or avatar. The characters that appear in each panel can be modified by the user.

Optionally, if a scenario is co-created by more than one single user, each editor retains control over their own doll(s). Alternatively one editor at a time can control the progress of the storyboard, with control being handed over between editors. Notification can be provided when a co-editor is editing the scenario. A communication panel may be provided between the co-editors.

The user is also able to create monologues or ‘diary entries’, which are scenarios played out by a single character. Monologues can be played back on dolls without other participating dolls.

Initially, inside the panels 2002 there are empty speech bubbles 2004 into which users can enter phrases to create the scenario. Each panel can contain a number of speech bubbles, depending on the context of the panel and the number of characters.

For editing the user selects panels one at a time and edits them via an editing view 2020 of the Story Creator tool, as shown in FIG. 43b. The user can return to the storyboard view 2000 to review the whole story as a continuous comic strip.

In the editing view 2020 the selected panel 2002 is displayed along with a number of speech balloons 2022 that represent available phrases. Phrases represent one or two lines of dialogue by a particular doll. The user selects a speech balloon 2022 with an available phrase and inserts it in place of an empty speech balloon 2004 by dragging and dropping into the panel 2002 to form a conversation. The user can navigate through all available speech balloons 2022 with suitable buttons 2024. Optionally, the user can type text into an empty speech balloon 2004, thus defining a new phrase.

The selection of phrases can be limited by the choice of setting or plot. A subgroup of ‘recommended’ phrases can be shown at the top of the list, with less suitable phrases following. A user can scroll through the balloons until a desired phrase is found. Optionally a searching resource can be provided so as to search within the available phrases. A user can select a phrase by dragging a balloon to a character. A user's choice of phrase can change the phrases that are available for another character, or it can change the options available in the next panel, or it can cause the Story Creator tool to suggest some relevant phrases (the user can of course ignore the suggestions and instead choose other items if desired).

Optionally a phrase can only be used in certain types of panel. A context tag can be associated with phrases to identify suitable phrases for a chosen panel. For example, a laughter phrase is only used in a panel where phrases are spoken simultaneously, so that while a doll says something funny another doll laughs.

Once a panel is completed the user can proceed to the next panel, or review completed panel(s). A pre-set number of panels can be available (for example 20 or 30 panels). Panels can be added as the user proceeds until the scenario is finished. The maximum number of panels that can be added can be limited, for example to 100 panels. The limit can be based on the number of phrases in the panels the user has selected. The Story Creator tool also provides the option of deleting or modifying panels.

Optionally, the phrases the Story Creator tool provides can be adapted to a particular user. For instance, the Story Creator tool may request information from a user before the user can start assembling a scenario—such as the user's doll's name, friend's doll's name, pet, favourite colour etc. When the phrases are presented to the user, certain balloons will have been customised to contain this personalised text, for example “I want to buy a lilac dress, because that's my favourite colour!”. Additionally or alternatively doll settings and/or the doll personality and other parameters can be used to adapt the phrases.

The Story Creator tool provides the option of saving the scenario while it is being created, and once it is complete. The Story Creator tool also permits the user to edit or delete a previously generated scenario. The Story Creator tool can provide an option to enter a newly-created scenario into a monthly competition, and/or to start again with a new, blank, storyboard.

The Story Creator tool can provide an option to play back a scenario so that the user can listen to the conversation online as they are editing a scenario to ensure that the scenario makes sense. A ‘karaoke style’ visual read-through with text display and cues may also be provided. The user can determine a starting point, so as to listen to a subset of the panels.

When the storyboard is completed the Story Creator tool provides an option for the user to compile (and thereby prepare for download) the newly-created scenario. The Story Creator tool uses a scripting engine to compile scenario data from the phrases selected by the user. The compilation includes obtaining audio data for the dolls to play, and creating instructions for the dolls to follow so that they can play the audio data in the right order. The audio data corresponds to the selected phrases. The audio data is provided in multiple voices so that scenario can be played on different dolls. The audio data can be synthesised on demand and as required (for example for personalised phrases, or for phrases the user has generated), as described above, or it can be made available as pre-recorded data. Optionally a phrase can be spoken in various ways, for example with different inflection or tone. By providing variations within phrases the scenario can be different every time it is played.

The user is notified when their scenario is compiled and ready to download. Additionally, friends of the user can be notified too. Previously-created, saved scenarios can also be viewed and downloaded. Generally scenarios can be made available to other users, both for viewing and for downloading. Once a scenario has been downloaded to dolls, it can be selected to be used as a conversation like any other scenario.

The Story Creator tool can be updated by adding new locations or settings and new plots, as well as new phrases. This can enable the Story Creator tool to remain engaging even to frequent users.

FIG. 44 shows a schematic block diagram of an apparatus or computing device 2100 that is adapted to provide the Story Creator tool functionality. The computing device 2100 might also be adapted to provide certain aspects of the functionality of the Authoring Tool as described above. The computing device 2100 comprises a processor 2102, a memory 2104 and a database 2106. A graphical user interface module 2108 provides the authoring interface to a display device 2114, and receives user input from an input device 2116. The graphical user interface module 2108 can provide the user input (in suitable form) to a conversation engine 2110 which can generate suitable conversation data. If speech synthesis is required, a speech synthesis module 2112 is provided. Conversation data can be output to an audio output device 2118.

Communication Interface

As illustrated in FIG. 5, a doll 100 connects to a server 200 via a computing device 260 connected to the internet 262. When a doll connects to a computer, the communication interface software detects the doll, accesses its Unique Identifier (UUID) and send this information to the server to check:

1. The doll is a legitimate doll (the UUID exists)
2. If the doll has been registered yet
3. The doll is registered to the current logged in user
4. What personality traits and other settings are attached to the doll

If either of 1 or 3 are not true, then a message is displayed by the communication interface software, for example stating “The doll you have plugged in belongs to a different account. To continue with this doll, please log into the correct account.”.

If the doll has not been registered before (step 2), initialisation of the doll starts. In the course of initialisation the user selects for the doll:

• • a name
  • a personality
  • a voice
  • other customisable information—doll's pet, doll's pet's name, where doll ‘lives’, etc.

After selection this information is saved to the doll and also sent to the website.

For initialisation the software may obtain information from the server, such as:

• • A list of available doll names
  • A list of pre-set personalities and their corresponding traits
  • A list of voices (and samples)

On subsequent connections the software may

• • inform the website that it has spoken the golden phrase.
  • inform the website that its count of the number of conversations it has been involved in has changed.
  • inform the website of how many conversations it has been involved in.
  • request the download of a number of Doll Name Audio files in its chosen voice (as described in more detail above with reference to FIG. 5).
  • request the download of a new theme. This would entail downloading the theme definition file in the doll's chosen voice.

An example of the communication interface, the so-called ‘Air app’, for enabling connection and synchronisation, is now described.

A doll cannot connect to a server and/or website directly. Instead, the communication interface acts as a connector between the server/website and a doll. In operation the communication interface is—at the same time—connected to the server/website, and also to the doll. It synchronises the data on the doll(s) with the data on the server/website. If a user changes the scenario, name or attributes for the doll on the server/website then the doll's contents (such as the doll data file residing in the doll) are changed by the communication interface. The doll's statistics such as usage counters, names encountered and other details are transmitted through the communication interface to the server/website. The communication interface may additionally act as a basic maintenance tool for the doll and to a certain extent can repair broken dolls automatically.

FIGS. 45a, 45b and 45c illustrate some exemplary screen shots of different messages and user input requests of the communication interface. In particular the interface is very simple since it is intended to be used by children.

Doll Detection/Registration: the communication interface is in the form of software on the doll owner's computing device (e.g. PC, laptop, tablet) in the user's system tray waiting for a doll to be connected. The communication interface expects a flash drive with the name “I_AM_A_TOY”. When such a drive is detected the communication interface begins synchronisation with the server. FIG. 45a shows a message requesting a doll to be connected. FIG. 45b shows user input fields for the user to sign into his account with the server.

Once the doll is connected, the communication interface then checks to see if the doll is registered to the current user's account. If the communication interface determines that the doll is already registered, but to a different user's account, then a message such as: “The doll you have plugged in belongs to a different account. To continue with this doll, please log into the correct account.” is displayed. If the doll is not registered to an account yet, then the user is asked to register the doll with the website, as illustrated in FIG. 45c.

Scenario Synchronisation: a scenario that is available on the website can be selected by the user. When a scenario is selected it is queued for download. Upon synchronisation with a doll the communication interface checks to see if the scenario that is on the doll matches the one that is selected on the website. If a different scenario is selected then the communication interface downloads the scenario from the website and then transfers it to the flash storage on the doll. If the doll does not have a scenario loaded onto it then the selected one on the website is downloaded even if it is not queued.

Name Synchronisation (as described above with reference to FIG. 5): the name data of the doll (it's own name as well as the names of other dolls) comes in two parts:

• • a name identifier: a file which specifies the name(s) (for example in text format, or as a reference such as a name ID number); and
  • audio data: file(s) of the voice recordings of name(s).

The communication interface checks for the following name changes as part of the synchronisation:

• • if the user changes the name of the doll on the website then this name is downloaded and transferred to the doll through the communication interface.
  • the names references of recently encountered dolls are read from the doll and reported to the website. The communication interface checks to make sure that the name audio data files that are stored on the doll are correct and complete. If any of the name audio files are missing from the doll then the communication interface downloads them from the website and transfers them to the doll. Older names are replaced with the newer ones.

Statistic Synchronisation: as part of the synchronisation process, toy characteristics data, such as the relevant statistics about the doll (e.g. who they have communicated with, how many conversations they have had and whether certain phrases have been said) are communicated back to the website where they are stored in the database and evaluated (e.g. points may be awarded to the doll's online account).

Security: all of the exchanges with the website are encrypted and signed before being communicated with the website. This makes it much harder for someone to corrupt the system and pretend to be a doll. The responses from the website are encrypted and signed and sent back in the same manor.

Debugging: the software incorporates debugging functionality, via a debug menu that enables testers to examine the communication logs and perform administrative tasks such as forcing the doll contents to be completely replaced. Only authorised users can access the debug menu. The debug menu is only provided for prototype and pre-production use, and is not included in the end user software.

Installation: the installation can be started directly from a website using an install badge or using a classic executable installer. The installer then installs or upgrades the required libraries on the user's computer to the correct version and then installs the app.

Interface: FIGS. 45a, 45b and 45c illustrate some exemplary screen shots of interfaces for presenting messages from the communication interface to the user, and enabling user input of information to enable the communication interface to perform. In particular the interface is very simple since it is intended to be used by children.

Toy Identification and Adaptation

To identify how many toys of a particular type (e.g dolls with blond hair) are connected to the website at a particular time, and to adapt the behaviour of a toy to a physical characteristic of the toy, the following arrangements are made.

A serial number is issued to each particular toy. When the serial number is issued, any significant physical characteristics of the toy are added to a toy database and linked to the issued serial number.

When a toy connects to the server, the server logs the connection with a reference to that toy's serial number. A database query should answer any questions such as the above.

To adapt the behaviour of a toy to a physical characteristic of the toy, for example enabling a doll called either ‘Molly’ or ‘Milly’ to speak a specific default (or welcome) phrase on initiation, a default phrase of the type “Hi—I'm *SAY MY NAME HERE*, plug me in!” is stored on all toys, regardless of particular type. All toys have stored a selection of name audio file, so can say any of a given selection of possible names (as described above for example a set of ten names) by referencing the correct Name ID. The initial toy data file is programmed into the particular toy during production test; at this time the serial number is set, and also the toy's own name ID is set.

If a large number of names are required, a different default theme can be generated for each name and then stored on the correct particular toys.

An example of a toy data file follows the following format:

Serial number

• • Skin colour code
  • Hair colour code
  • Name ID
  • etc

A particular toy has a toy data file such as:

6179023646

• • 14
  • 8
  • 8

Serial numbers can be incremental or freely assigned as required. Serial numbers can be obtained from a chip in the toy. Serial numbers and the associated data are obtained for example from a spread sheet, or from a database. The relevant parts of this data are used to generate an initial toy data file which is loaded to the doll.

H-Bridge Circuit Arrangement

FIG. 46 shows an example of a traditional all-n-channel FET H-bridge amplifier circuit arrangement 900 known from the prior art. The circuit includes amplifier circuitry arranged to connect a power supply (e.g. a battery with voltage VBAT) to a load (e.g. a speaker), for example as part of a portable electronic device. The circuit comprises four FETs, Q1, Q2, Q3, Q4, which may for example be power MOSFETs (metal-oxide semiconductor field-effect transistors). Each FET Q1, Q2, Q3, Q4 comprises a gate (G), a source (S) and a drain (D). The FETs Q1, Q2, Q3, Q4 also each incorporate back-biased diodes 902, 904, 906, 908 from the drain to the source, which can present a reverse-power-connection hazard since there is a current path from ground to supply through these diodes.

In prior art systems such as this, in order to avoid problems associated with reverse polarity (i.e. when the power supply is connected with opposite polarity, such as if the batteries are inserted the wrong way round), a diode 910 is included in the circuit before any of the transistors Q1, Q2, Q3, Q4. There is a voltage drop over this diode 910, even during normal operation, creating heat which reduces the efficiency of the system and reduces the available output power. This is particularly a concern with portable electrical devices.

Hybrid H-Bridge Arrangement

FIG. 47 shows an amplifier circuit 920 incorporating a hybrid H-bridge arrangement, to address the problems discussed above. The upper pair of transistors 922, 924 (electrically closest to the power supply) are bipolar transistors rather than FETs (each bipolar transistor comprising an emitter, a base and a collector). The bipolar transistors 922, 924 do not have the back-diode (i.e. 902, 904, 906, 908) present in FETs. The other transistors Q2, Q4 are FETs as before.

The H-bridge circuit 920 shown in FIG. 47 is essentially a two-leg pulse-width modulation (PWM) push-pull bridge circuit. On each side of the H-bridge 920, the collector of the bipolar transistor (e.g. 924) is connected to the drain (D) of the accompanying field-effect transistor (e.g. Q4). The transistors form inverters compared to the incoming logic (looking at it from a logic-gate point of view). The transistors provide current gain, and are low-power when “off” (i.e. both control signals are high, which pulls the output terminals (e.g. speaker terminals) to ground, but no current, or only a leakage current, flows).

Reverse-biased diodes D9 and D10 ensure that when the power supply connection is reversed (e.g. if the battery is inserted the wrong way round), the base of bipolar transistors 922, 924 remains (approximately) at the same potential as the respective emitters, ensuring that bipolar transistors 922, 924 do not turn on (as bipolar transistors can operate in reverse connection). Thus the current that flows in the case of reverse polarity is limited to a safe level by the resistors R13 and R15 which, in the embodiment illustrated, are each 560Ω. This resistance can be altered to suit an application which has a greater or lower safe back current level.

As indicated in the figures, each diode comprises an anode (A) and a cathode (C), as those skilled in the art will appreciate.

Timing Control

To control the timing of the circuit 920, small-signal diodes D4, D6, D7, D8 and resistors R12, R13, R14, R15, R19 and R20 are provided.

The timing circuitry is included with a view to inserting a small amount of dead-band—i.e. to avoid shoot-through current, which can occur if both transistors are on. For circuits with, say, four control signals, this can be performed by delaying the relative edges of the control signals. However, when using a low-cost microcontroller, pin limitations can mean that only two pins are available for use—as illustrated by pins 1 and 2 of connector J2 in the figures. In this case, the relative timing of the transistors in each half bridge can be controlled by the circuitry alone. An example low cost microcontroller comprises a printed circuit board with eight connection points (pins). Two for the control signals, two for power connection, two for the timing circuitry and two for the speaker output.

Another objective is to have a low stand-by current (i.e. when not driving a speaker, the circuit should consume very low power because the circuit is connected to the battery even when “off”).

The inductor L7 at the top of the bridge also helps soak up any short transient shoot-through. When both control signals are high, the circuit is also very low power, since there are no bias currents in this case. The hybrid bridge is unusual in that the top (bipolar) transistors 922, 924 are effectively current controllers, whereas the lower (FET) ones Q2, Q4 are directly voltage controllers.

Switching Sequence

The following switching sequence is described with respect to the control signal PWM+. The circuit 920 is largely symmetrical and so the switching sequence for the signal PWM—will substantially correspond, as those skilled in the art will appreciate.

• • When the control signal is low, current flows through diode D6 and resistor R14, switching on bipolar transistor 924.
  • When the control signal switches from low to high, the gate capacitance of FET Q4 coupled with resistor R19 slows the turn-on of the lower transistor Q4 slightly. And, diode D7 serves to speed up the raising of the base of bipolar transistor 924, which would be slower without diode D7; this is partly slowed due to the capacitance of diode D9, but also due to carriers lingering in the base of bipolar transistor 924. This allows high current flow briefly while the carriers and charge are injected/removed.
  • When the control signal is high, the base of bipolar transistor 924 is pulled up, so no current is flowing there, so no current flows through the bipolar transistor 924. VGS of FET Q4 is high, causing it to be on.
  • When the control signal switches from high to low, diode D6 helps to delay bipolar transistor 924 turn-on (by its voltage drop appearing like a 0.6 V voltage source), until FET Q4 has begun to turn off and resistor R14 limits the ultimate base current (as we don't want to over-saturate bipolar transistor 924 otherwise it would take longer to turn off).

Protection Against Damage

In the circuit 920 shown in FIG. 47, there is no risk of the diodes becoming damaged if an AC input instead of a DC input is applied. In particular, the PNP bipolar transistors 922 and 924 and/or diodes D9 and D10 will not become damaged by an alternating current in this circuit. The body diode 906 of FET Q4 is in series with the effective emitter-base diode of bipolar transistor 924 (so there are two diode drops between pin 2 of Q4 and pin 1 of bipolar transistor 924), but the base is held one diode drop below pin 2 of bipolar transistor 924, so there is no current between pin 3 and pin 1 of bipolar transistor 924 (emitter and base), effectively because diode D9 “steals” it all. Current does flow through diode D9 and resistor R15, but it is only very small (about 4 mA or 5 mA)—i.e. not the many Amps that could flow if two diodes were connected directly across the supply, which would be the case for a pair of MOSFETs as in the prior art. With the two half-bridges, around 10 mA will flow if the input supply is reversed.

Example Component Specifications

In the presently-preferred embodiment as illustrated in FIG. 47, the following components are used. These are given merely as examples. In particular, alternative values of the components may be used, as those skilled in the art will appreciate.

Reference
numeral	Component	Description/value
Q2	FET	Power MOSFET, MGSF2N02ELT1G
Q4	FET	Power MOSFET, MGSF2N02ELT1G
22	Bipolar transistor	PNP bipolar transistor
24	Bipolar transistor	PNP bipolar transistor
D4	Diode	n/a
D6	Diode	n/a
D7	Diode	n/a
D8	Diode	n/a
D9	Diode	n/a
D10	Diode	n/a
R12	Resistor	330 Ω
R13	Resistor	560 Ω
R14	Resistor	330 Ω
R15	Resistor	560 Ω
R19	Resistor	330 Ω
R20	Resistor	330 Ω
L6	Inductor	100 μH
L7	Inductor	10 μH

Heartbeat

FIG. 48(a) shows an example signal 940 prior to any modification. The signal is limited to a certain amplitude, shown by line 942. A ‘characteristic signal’ 944 is inserted into the signal periodically, shown in FIG. 48(b), thereby creating an augmented signal 946. In a preferred example, the characteristic signal 944 has a length corresponding to a single sample period. For a playback device with a sampling rate of 15625 Hz this corresponds to a length of 64 microseconds. In a preferred example, the signal 940 is an audio signal.

The characteristic signal 944 is interposed periodically into the audio signal 940. In a preferred example, this period is every 1000 samples (i.e. a single sample characteristic signal 944 followed by 999 audio samples). This corresponds to a time period of 64 milliseconds for a device with a sampling rate of 15625 Hz. Preferably, the first characteristic signal 944 is inserted as the first sample. The addition of a single-sample characteristic signal every 1000 samples increases the original signal 940 file size by approximately 0.1%. The characteristic signal 944 has an amplitude higher than the amplitude limit 942. This makes the characteristic signals 944 easy to distinguish from the rest of the augmented signal 946, by merely monitoring the augmented signal 946 for deviations above a particular amplitude limit.

The augmented signal 946 is then encoded so as to be transferred to or stored in the playback device. The encoding process (and the subsequent decoding), or the act of storing the file may corrupt the signal. This would result in the quality of the playback suffering, for example audible ‘glitches’ or the audio file breaking to silence after a starting. In embodiments where speed is favoured over reconstruction of corrupted data, simply identifying such corrupted files will suffice. The playback device can then skip the corrupted file, or (for example) flag it up for it to be re-transmitted either immediately or at a later time.

In the present example, the playback device determines whether the signal is corrupted by checking the first 2000 samples of the playback (two periods of the characteristic signal 944) for the presence of the characteristic signal 944. Two periods (i.e. 2000 samples) are checked to minimise the possibility of the checking process missing one characteristic signal 944 and mistakenly marking the signal as being corrupted. This checking process involves checking each sample's amplitude and determining whether it is above a threshold. If it is above the threshold 942, the playback device assumes that this is the characteristic signal 944 and hence the signal 940 has survived the encode/decode/store process without becoming corrupted.

The playback device may iteratively perform this check on the file as it is being played, and if two periods pass without the detection of a characteristic signal, the rest of the signal is muted. Alternatively, the playback device could perform the check on just the first two periods of the signal to determine whether the whole file has been corrupted or not. It is preferable for the entire signal to be augmented with the characteristic signal, and the decoder to check for this iteratively as the decoder buffer could theoretically underrun at any point. This could lead to errors such as ‘machine-gunning’, where a ring buffer repeats a short section of the signal. Such errors would also be flagged up by checking for the characteristic signal 944.

As the characteristic signal 944 is in this example the highest amplitude section of the signal, any corruption would likely have the greatest effect on this. Therefore, determining if corruption of the characteristic signal 944 has occurred (i.e. determining the presence of a certain amplitude) is a good proxy for corruption of the entire signal.

FIG. 49 shows an example flow diagram of the preparation of the augmented signal 946. This process is preferably performed by a device external to the playback device, and the augmented signal 946 is encoded and/or compressed, then transferred to the playback device. A schematic diagram of a suitable device is shown in FIG. 50 and is described below.

The process begins at S1 with acquiring the signal. Then, the characteristic signal 944 is inserted as the first sample in step S2. The next 999 samples are then left as original, i.e. skipped (step S3) and another characteristic signal 944 is inserted, if the end of the signal has not been reached (shown by feedback step S4). The process may then continue with another signal, as shown by feedback step S5 before ending at step S6.

FIG. 50 shows a device 960 having means for carrying out the process shown in FIG. 49. Signal modifier module 962 performs the steps described above, utilising the processer 964 and associated memory 966. In use, the original signal 940 is received by the device 960 and stored in the memory 966. This is then passed to the signal modifier 962 which modifies the original signal with the characteristic signal 944 as described above. The augmented signal 946 is then encoded by encoder 968, passed back to the memory 966 where is transmitted to a playback device by signal transmitter 970. This transmission may occur immediately, or at a later time and could be via a wired or wireless link to the playback device. The encoder 968 may not pass the encoded signal to memory 966, rather transmit it directly via signal transmitter 570, shown by a dotted arrow. Furthermore, the encoder 968 may not be necessary if the playback device can cope with uncompressed (raw) signals. The encoder 968 may comprise many different sub-components, described in more detail below.

FIG. 51 shows a flow diagram of the processes prior to and including playback performed by the playback device. The process starts with acquiring the augmented signal at step S1. Prior steps to this may include decoding the augmented, encoded signal (to produce just the augmented signal). The device then determines the amplitude of first sample of the signal in step S2. The next step, S3 comprises comparing the amplitude with a pre-stored level, corresponding to the level above which the sample can be assumed is the characteristic signal 944. If the sample is determined to be a characteristic signal 944, the process jumps to step S6a and the rest of the signal is played by the playback device. If the sample is not determined to be a characteristic signal, the process moves onto the next sample in step S4. This process continues for 2000 samples (shown by feedback to S2), if no characteristic sample is found before sample number reaches 2000 (step S5), the rest of the signal is muted (step S6b).

FIG. 52 shows part of the playback device 980 adapted to perform the process described above in relation to FIG. 51. In use, the playback device receives the augmented, encoded signal and stores it in memory 982. This is then decoded by decoder 986 utilising processor 984. The decoder 986 may comprise many different sub-components, described in more detail below. The decoded signal is then passed to an amplitude monitoring module 988 which measures the amplitude of each sample. The logic circuitry 990 then determines whether this amplitude is above the pre-determined level and decides an action accordingly. This may be to send the signal to the output module 992 or feeds back to the amplitude monitoring module 988.

Alternatives and Modifications

Although the characteristic signal 944 has been described as a single sample length signal, it could be more complex than this. For example, it could be a multi-sample length piece of code. This would afford the advantage of greater potential for determining corruption, but would require longer to process. A person skilled in the art would realise that the trade-off of longer processing to afford greater corruption detection may be worthwhile for some applications and not others.

The period of the characteristic signal 944 is described above as being every 1000 samples. A shorter period (more frequent insertion into the signal 940) would result in faster determination whether a signal is corrupted, but would increase the file size more. Conversely, a longer period would make it slower to determine corruption of the signal, but the file size would be smaller. A person skilled in the art would recognise that different applications would have different priorities and thus the sampling period would be altered accordingly.

Furthermore, although the description above describes two periods being checked for the corrupted signal, more or less could be checked. If just one period is checked, the probability of the checking process ‘missing’ the characteristic signal 944 is the greatest. This may be preferred if the checking process is very reliable. However, a reliable checking process may be processor-intensive and thus it may be more efficient to check multiple periods with a less reliable checking process.

The embodiment described above refers to the signal being an audio signal but the apparatus and method could be applied to determine corruption of any signal which has been suitably prepared.

An alternative method utilising similar apparatus to perform the same function is described below. Rather than inserting a characteristic signal 944 periodically into the signal 940, a characteristic frequency could be added to the entire signal. Thus, when the frequency spectrum of the signal is inspected, there will be distinct peaks corresponding to the added characteristic signal. The characteristic frequency signal would preferably have a frequency outside of the range of the rest of the signal, and outside human hearing (or outside the frequency response range of the playback device). This would ensure that the characteristic signal can be distinguished from the rest of the signal, and does not negatively impact the sound quality.

The characteristic signal could be a mixture of a number of different frequencies so that a number of peaks are shown in the frequency spectrum, or just a single frequency. A single frequency could be distinguished easily, but would be more likely to be missed or subject to frequency-dependent corruption. Using multiple (or a range of) frequencies would increase the file size and potentially increase the processor time necessary to distinguish the characteristic signal from the rest of the signal.

In use, the playback device inspects the frequency components of the signal, for example by performing a Fast Fourier Transform (FFT) on the time-domain signal. This analysis could be performed over the entire frequency spectrum, or just over a range of interest. The latter option would likely be significantly faster. The resulting frequency spectrum shows the characteristic frequency if the signal has not been corrupted. However, if just a small amount of corruption has occurred, it is unlikely to be able to be detected in this way. One way of improving the accuracy of the method is to include a number of different frequencies at different relative amplitudes. This gives two ‘dimensions’ to determine if corruption has occurred. For example, if the relative order of the amplitudes of the characteristic frequencies has changed, it is likely that corruption has occurred.

A potential disadvantage of this method is that the process of inspecting the frequency domain may introduce errors itself, which may make the signal appear corrupted when it in fact not. Furthermore, processes such as FFTs are generally processor-intensive, and applications focussing on speed or with limited resources may not be suited to utilising this alternative method.

Overlay Buffer

Often, due to budget, size or power constraints the processor used in a particular device may have severely limited resources. The Random Access Memory (RAM) component of one such example device (a talking doll, for example) the processor is 8 kilobytes (kB) in size. The Serial Flash Memory device (Flash) requires half of this (4 kB) to be reserved as an Erase Buffer, active when the filesystem and Universal Serial Bus (USB) are in use.

This constraint would render the decompression of audio files to be unpractical, thus effectively reducing the length of audio files able to be stored on the device (in one example from 20 minutes to approximately 3.5 minutes). In order to minimise the impact of this constraint on the system design, the Erase Buffer RAM allocation is used for other operational states without conflict with its primary function.

The additional functions and the overlaid entities are shown in FIG. 53, which collectively use 4 kB of RAM:

Speech Playback:

• • Output Audio Table Of Contents
  • Decode Table
  • Decode Buffer
  • (Pulse Width Modulation) PWM Buffer

Virtual Electronically Erasable Programmable Read Only Memory (EEPROM) access:

• • EEPROM Buffer

Theme Engine operation:

• • Attributes Data

This allocation of RAM is predetermined at the compile time.

The overlay of these operations onto the 4 kB of RAM reserved for the erase buffer means that there are some operational constraints, such as a limitation on speech playback while USB file activity is occurring. Two mutually exclusive groups of actions are therefore formed:

• • a) Flash device erase, i.e. USB file system write access.
  • b) Speech decompression/playback/Theme file processing.

Given that these groups of tasks would rarely be performed simultaneously, the overlay of their RAM allocations would not lead to critical operational constraints.

A memory controller is adapted to control the allocation of RAM, and thus switches the allocation from one group of tasks to the other if required. In one example, the write/erase group of tasks takes priority.

Alternatives and Modifications

Although the above description refers to an example device which is a talking doll, any device which suffers from similar RAM constraints can utilise the structure described above. The mutually exclusive groups of actions may vary for different devices, but may still fall into the broad categories of a) Write/erase and b) Decode/Read.

Compression—Audio Coding Scheme

Audio data is used in this system for interaction between dolls amongst other functions. This audio data is compressed and stored in the doll, A trade-off between storage space and decoder complexity determines the nature and extent of this compression. Thus the system described herein responds to a need for a particular set of requirements. In certain examples, such as when audio files are stored in and played by a doll, these requirements are asymmetrical, those for the encoder being very different from those for the decoder.

These requirements are as follows:

1. Very low decode complexity both in space and time.
2. No decoder buffering.
3. Highest possible quality at a wide range of compression ratios.
4. Capable of both lossless and lossy operation.

These requirements are typically present when a large number of low cost decoders are to be used to decode stored audio data of widely varying length at the best possible quality for each length, i.e. essentially lossless for short recordings and progressively lower quality as the recording length increases. This is analogous to choosing the tape speed of an analogue tape recorder to make a best quality recording of a given length of music onto a given length of tape.

The system uses a variable data rate and virtually unlimited encode complexity. It also has high delay in that the encoder makes multiple passes over its input before any output is made.

The encode process contains a number of steps, shown in FIG. 54.

Step 1. Normalize the peak level of the signal. It is expected that the types of signal most suited to this application are professionally recorded samples of single person speech, as required for a speaking toy. In such cases simple level normalization is all that is required. It is also normal that the bit-width of the signal presented to the encoder is greater than that which is required at the output of the decoder due to cost limitations of the circuitry (typically a Digital to Analogue Converter (DAC)) following the decoder.

Step 2E. Apply a ‘curve bender’ to the signal, such that the gain is larger for small signals than for large ones. This has an effect similar to telecommunication A-law (or μ—law) reducing the audible effect of quantization. The degree of ‘bend’ applied may be selected from none (allowing lossless encoding) in multiple steps up to severe. This step is described in more detail below.

Step 3. The signal is quantized to a selectable number of bits. This quantization determines the level of noise in the final output. If quantization to the required number of bits at the output of the decoder is used, the system is compatible with a lossless encode-decode process.

Step 4. A noise-gate is applied to the signal. This mutes the signal if it remains below a certain, selectable, level for longer than a selectable time period. The intention here is to reduce the data transmission requirement of periods of silence. Normally, when the system is used with professionally edited material, this feature need not be used. When this step is disabled a lossless encode-decode process may be obtained.

Step 5. Select a pre-emphasis filter. Pre-emphasis will be used to apply some order of differentiation to the signal in order to reduce the energy in, and thus the number of bits required to encode, the signal. The purpose here is to ‘whiten’ i.e. to flatten the spectrum of the signal. All audio signals, and especially speech signals, contain most of their energy in the low frequency region and progressively less energy in the higher frequencies. All the available orders of filter are tried with the complete audio signal and that which yields the lowest energy is selected. The selection step may not be explicitly performed and may be skipped (shown by dotted arrow) if, for example, the signal has the same features as a previous signal and thus the same pre-emphasis filter is used.

Step 6E. Apply a pre-emphasis filter of the selected order. The type of filter used is the exact bit-for-bit inverse of the de-emphasis filter to be used in the decoder. Thus the “pre-emphasis feeds de-emphasis” chain is always lossless.

Step 7. Generate a probability table from the resulting signal and from this generate tables for, for example, Huffman encode and decode of the signal. Huffman coding is one (preferred) example of a lossless coding technique. Other coding techniques such as Shannon-Fano, could also be used. Similarly to step 5 above, generation of this table could be skipped (shown by dotted arrow) if the same encode table is used as has been on a previously encoded signal.

Step 8E. Apply the Huffman encode table to the signal to generate an encoded (compressed) version of the signal.

Step 9E. Send the selected curve bender amount (from Step 2), pre-emphasis filter order (from Step 5), Huffman decoder table (from Step 7) and Huffman encoded version of the signal (from Step 8) to the decoder. It is not necessary to send the value of the number of bits used in the quantization at Step 3 to the decoder.

The decode process, though containing several steps, is significantly simpler. This provides the advantage of being able to have a much simpler decoder to the encoder, and the process of decoding is less processor intensive. This is particularly advantageous in applications where the decoder is a simple device such as a toy, or is required to perform the decode process quickly.

These steps are numbered in reverse order to correspond with the steps in the encode process. They are executed in reverse order from 9D to 2D, and shown in FIG. 55.

Step 9D. The different parts of the data from the encoder are separated for individual use by the following steps. The Huffman encoded version of the signal and the Huffman decoder table for Step 8D, the pre-emphasis filter order for Step 5D and the curve bender amount for Step 2D.

Step 8D. Apply the Huffman decode table to the encoded signal to generate a decoded (uncompressed) version of the signal.

A

Step 6D. Apply a de-emphasis filter of the selected order to reverse the effect of the filter in 6E.

Step 2D. Apply an inverse curve bender to the signal to undo the transformation done by Step 2E.

Detailed Description of Each Step

Each step (and its inverse if there is one) is described below in more detail.

Step 1. Normalize the peak level of the signal. The whole audio input is scanned for the sample having the maximum magnitude, i.e. the maximum absolute value, all samples are then divided by this value. The maximum value found in the resulting signal is exactly one.

Steps 2E and 2D. In order to make the decode process as simple as possible, the curve bender selected has a very low decode complexity. To make the system capable of lossless and lossy transmission, and to perform well over a range of compression ratios, the curve bender has an easily controlled depth of effect. This is unlike the telecoms ‘A-law’, which was designed to be simple to implement in hardware (gates and wires) as opposed to instructions on a microprocessor. The decode process is described below first as it is the simpler process, but it is of course performed afterwards.

The decode process is dictated by the expansion required between the input and output ranges, the input range for the decoder is—g to +g, the output range is −1.0 to +1.0. For ease of implementation, values of g that correspond to binary shifts of the data are preferred.

An example decode equation used is y=x+ax³, where x is the input value (signal amplitude) and y is the output value.

It may be appreciated that this relation may be economically calculated in four basic operations, three multiplies and an add. Traditional A-law type curve benders, which rely on multiple shifts, were designed for easy hardware implementation and require many instructions to implement in modern software controlled microprocessors. Thus, a cubic relationship such as the one above is easy to perform by a simple device containing a microprocessor. This family of ‘curve benders’ also only have one variable, a. This means that only one value needs to be sent to the decoder (from the encoder) to fully define the curve bender used.

The value of a for any g can be calculated by a=(1−g)/g³.

For ease of implementation values of g that correspond to binary shifts of the data are preferred. These are selected by an index used to communicate between the encoder and the decoder. Typical values of g and a are given in table 1 below:

TABLE 1
Example values of g and a
index	g	a
0	1.0	0
1	0.5	4
2	0.25	48
3	0.125	448
4	0.0625	3840
5	0.03125	31744

FIG. 56 shows the curve bender graphs for the various values of g as in Table 1. The encode curve bender is the same as this, but reflected on the y=x axis.

The encode equation is somewhat more complicated. Although the relationship between x and y depends only upon a, temporary variables u and v are included to simplify the equation:

u=cube_root(x/(2a)+square_root((x/(2a))²+(1/(3a))³))

v=cube_root(1/(2a)+square_root((1/(2a))²+(1/(3a))³))

y=(u−1/(3au))/(v−1/(3av))

Since low encode complexity is not a primary aim of the process the added complexity of this process is not a problem. The ‘curve bender’ is thus a computationally asymmetric process, which affords the advantage of a being able to use a far simpler decoding device to encoding device.

Step 3. The signal is quantized to a selectable number of bits. Quantization is a well understood process. For best results dither should probably not be applied to this quantization step as the effect of the decode curve bender (Step 2D) is to increase the perceived level of such noise. Noise shaping may be applied to this step if the Signal to Noise Ratio (SNR) is needed to be improved. Noise shaping is a well understood process.

Step 4. A noise-gate is applied to the signal. Noise gates are well understood devices. As stated above, in well edited material this step may be omitted. In the Huffman encoding stage (Step 8E) it is most likely that silence will be encoded as a very small number of bits per sample, preferably one.

Step 5. Select a pre-emphasis filter.

The type of pre-emphasis filter to be used consists of a cascade of some number of simple first order differences. Such a first order difference may be characterized by the following relationship.

w[n]=x[n]−x[n−1]

Where x[n] stands for the value of the encoder input at time n, x[n−1] stands for the value of the encoder input on the previous sample, and w[n] stands for the filtered signal value at time n. Such a filter can be performed by a differentiator circuit, such as a high-pass filter.

The inverse filter for a first order difference is a first order integrator characterized by the following.

y[n]=w[n]+y[n−1]

Provided that the state variables in both the encoder and decoder filters are reset before operation, an encode-decode cascade is bit-for-bit accurate.

To select the filter order to be used the complete audio input is passed through all the possible filter orders. For each order, a probability table of the filter outputs is prepared, and from this the information content is calculated in bits per sample according to standard information theory. The filter order which produces the most efficient use of data is selected.

Step 6E and Step 6D. Apply pre-emphasis and de-emphasis filters of the selected order as part of the encoding and decoding processes.

Step 7. Generate a probability table from the resulting signal and from this generate tables for Huffman encode and decode of the signal. The crucial aim here is to minimize the size of the decode table while recognising that the decode process must make extremely low demands on the available decode processor. The size of the decode table is not only important since it constitutes part of the data payload that must be transported from the encoder to the decoder. It is also important since the whole of the decode table, unlike the encoded audio data, must be available to the decoder processor during the decoding of every data sample. This requires that the decoder table be placed in the decode processor RAM, rather than in any attached slow memory. Decode processor RAM is a very scarce resource in certain applications.

The classic Huffman decode structure is a binary tree. The decode process begins at the root and descends from node to node, via either the left or right branch depending on whether the data bit under consideration is a ‘0’ or a ‘1’. At each node the decoding process either stops with the output of a sample or continues to descend the tree. This approach has the great advantage of simplicity and speed in execution, but can require a large data structure to hold the decode tree. Other methods can involve smaller data structures with very much more complex and time consuming decode algorithms. A third, hybrid, class of solutions involves using the simple decode tree but performing data compression on the tree for transmission; unfortunately this doesn't help when the memory available inside the decode processor is itself restricted.

The method to be used here is a classic decode tree, for minimum processor load, but packed in a manner that minimizes memory requirements without requiring more than trivial unpacking.

Each node of the classic tree can be of one of four types, depending on whether each side is an output value or a pointer to another node. In the method used here only one of the one-value-one-pointer types are used, any of the nodes of the encode/decode tables that require the unused type are flipped to become the used type.

The decode table consists of a sequence of entries (one per node) which each contain one or two items. In this implementation each item is composed of 16 bits, the maximum size of an output value is 14 bits and the maximum number of items in the table can be covered by an index of 15 bits.

The entries are of three possible types.

Type A.

An entry with no children, but which contains two actual output values the first (J) applies for a data bit of zero, the second (K) applies for a data bit of one. The values of J to be used will need to be sign extended over the two MSBs on decode. The value of K to be used is sign extended over the two MSBs during encode, shown as SS below. There are no child entries, both data zero and data one terminate the decoding of an output value.

This type of entry requires two items in the array:—

• • 11JJ JJJJ JJJJ JJJJ
  • SSKK KKKK KKKK KKKK

Type B.

An entry with one child, thus it contains one actual output value (J) which applies for a data bit of zero. A data bit of one implies that the child immediately follows this entry. The value of J to be used will need to be sign extended over the MSBs on decode. The child follows this entry immediately and thus no index is required.

• • 10JJ JJJJ JJJJ JJJJ

Type C.

An entry with two children, it contains one index (P) which is taken for a data bit of zero. A data bit of one implies that the child immediately follows this entry. The value of P to be used can include the MSB which is zero.

• • 0PPP PPPP PPPP PPPP

It is of course possible to design more compact codes, the important point here is to be compact and easy to process.

Used as a Huffman decoder for a possible N output values the minimum possible table size is N items, the maximum is 3N/2−1, that is approximately from 1.0 to 1.5 times N.

Step 8E and Step 8D. Apply the Huffman encode and decode processes using the tables generated by Step 7. The method here follows directly from the description of Step 7.

Step 9E and Step 9D. These are simple packing and unpacking steps. The encoder information may be transmitted wirelessly or via wires, and is preferably not encoded, or is encoded in a pre-defined manner in which lossless recovery is assured.

FIG. 57 shows a schematic diagram of an encoder. The encoder 1000 receives a signal and is stored in the memory 1012. This signal is then normalised by signal normaliser 1006. The normalised signal is then modified by signal modifier 1008. This includes applying a curve bender and quantizing the signal as described above. The signal is then passed through a noise gate 1010 to remove redundant low amplitude sections. A signal analyser 1012 analyses this signal and selects a pre-emphasis filter from memory (shown by dashed line) for the filter module 1014 to apply. A similar process is then undertaken by the encode table generator 1016 which selects a suitable table from memory 1002 and the encoder module 1018 applies the encode table to the signal. The signal and the associated encoder information is then transmitted by the signal transmitter 1020.

FIG. 58 shows a schematic diagram of a decoder 1040. The decoder 1040 receives an encoded signal and encoder information, and stores this in memory 1042. The signal splitter 1046 splits the encoder information from the encoded signal. The signal is then passed to the decoder, which uses the encoder information from the memory 1042 (shown by dashed line) to decode the signal. The decoded signal is then filtered by filter 1050, again, using the filter information from the encoder information via the memory 1042. This signal is then modified by signal modifier 1052, for example, an inverse curve bend applied, the value of the inverse curve bend taken from the encoder information via the memory 1042. The signal is then output via output module 1054.

FIG. 59 shows an exponentially decaying sine wave, this is typical in many respects of the filtered pulse attributes of the human voice. FIG. 60 shows this waveform after various different curve benders are applied. The different plots show the waveform after curve benders with different values of g, as in Table 1 above, are applied. The effect of the curve bender is to increase the relative amplitude of the tail. Note that the large amplitude of the signal at the left, and the nearly zero amplitude of the signal at the right are almost unchanged; the major effect is upon the size of the signal at medium amplitudes.

FIG. 61 shows a similar graph to the one shown in FIG. 60 for a linearly decreasing sine wave, where the effect on the middle amplitude section is clearer. The effect of the curve bender is to increase the level, and hence the fidelity of coding, of middle range signals.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Reference numerals and/or titles appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1-11. (canceled)

12. A toy adapted to interact with another such toy, the toy comprising: a processor; a memory for storing audio data; an output for outputting said audio data; a receiver unit for receiving an identifier from the other such toy; and a suitably programmed processor and associated memory for downloading audio data relating to said identifier for subsequent output by the toy.

13. The toy according to claim 12, wherein the audio data relating to said identifier includes audio data specific to that other toy.

14. The toy according to claim 13, wherein the specific audio data includes any one or more of the following types of personal data relating to that other toy: its name; place of birth; home town; a hobby or interest; and favourite colour or food.

15. The toy according to claim 12, wherein the identifier identifies any one or more of the following variables relating to that other toy: the specific toy; a name; place of birth; home town; a hobby or interest; and favourite colour or food.

16. The toy according to claim 12, wherein audio data is in a specific form dependent on an audio output setting of the toy, and preferably wherein the audio output setting is user selectable.

17. (canceled)

18. The toy according to claim 15, wherein the audio output setting is a user selectable voice, and preferably wherein all audio data output by the toy is in the selectable voice, and/or wherein all audio data stored by the toy is in the selectable voice.

19-20. (canceled)

21. The toy according to claim 18, wherein the audio data relating to said identifier is in the selectable voice.

22. The toy according to claim 12, wherein the toy is adapted to be connectable to a server thereby to download said audio data relating to said identifier from the server, and preferably wherein said identifier is stored in the toy memory, and/or wherein said audio data relating to said identifier is associated with the identifier on the server.

23-24. (canceled)

25. The toy according to claim 12, wherein said audio data relating to said identifier is associated with and/or linked to the identifier in the toy memory.

26. The toy according to claim 12, wherein the toy exchanges identifiers with the other such toy when it comes into contact with the other toy.

27. The toy according to claim 12, further comprising a transmitter unit for transmitting an identifier relating to the toy to another such toy.

28. The toy according to claim 12, wherein the toy further comprises a modifier unit for modifying the audio data output to the other toy in dependence on whether or not the toy has stored thereon the audio data relating to said identifier for the other toy.

29. The toy according to claim 12, wherein the audio data is in the form of expressive responses adapted to be exchanged between the toys, and preferably wherein the sequence of the expressive responses is adapted in dependence on whether or not the toy has stored thereon the audio data relating to said identifier for the other toy, and/or wherein an expressive response is selected in dependence on whether or not the toy has stored thereon the audio data relating to said identifier for the other toy.

30-31. (canceled)

32. The toy according to claim 12, further comprising an initaliser unit for initializing the toy with particular personal data associated with the toy.

33. The toy according to claim 12, further comprising a determinator unit for determining whether audio data relating to the received identifier is already stored in the toy memory.

34. The toy according to claim 12, further comprising a derminating unit for determining whether the received identifier is already stored in the toy memory.

35. The toy according to claim 34, wherein if the received identifier is not stored, then the identifier is added to the memory for subsequent request of audio data relating to the identifier, and preferably wherein upon receipt of audio data corresponding to an identifier the identifier is deleted.

36. (canceled)

37. The toy according to claim 12, wherein a storage unit for storing audio data is adapted to store a predetermined maximum quantity of audio data file relating to a predetermined maximum number of identifiers.

38. The toy according to claim 12, wherein the processor is adapted to store audio data corresponding to an identifier of the toy itself, and preferably wherein the processor is adapted to prevent deletion of the audio data corresponding to an identifier of the toy itself.

39. (canceled)

40. The toy according to claim 12, wherein the toy is a doll.

41. A system for providing audio data to interacting toys, the system comprising: a server for storing identifiers corresponding to each of the toys, and audio data relating to said identifiers; a plurality of toys adapted to interact with one another and exchange identifiers when coming into contact with one another; and wherein the toys are adapted to download from the server the audio data related to the identifiers for subsequent output by each of the toys.

42. The system according to claim 41, wherein each toy is provided with an audio output setting, and wherein the audio data downloaded to a toy is related both to the audio output setting of that to and the identifier of another toy, and preferably further comprising a storage unit for storing the audio data relating to a said identifier in a plurality of audio data files, each one of said plurality of audio data files corresponding to a respective audio output setting.

43. (canceled)

44. A method of communication between first and second toys, the method comprising:

exchanging identifiers between the toys; and

downloading audio data relating to said identifiers for subsequent output by the toys.

45-55. (canceled)

56. An authoring tool for creating themed data for toys, comprising an interface for receiving content in the form of a scripted dialogue relating to a particular theme; a suitably programmed processor and associated memory for processing said content to generate a set of instructions for operating said toy within said particular theme; and an output for outputting said set of instructions.

57. The authoring tool according to claim 56, further comprising a suitably programmed processor and associated memory for providing a plurality of user selectable content elements, and a suitably programmed processor and associated memory for receiving a user selection of at least one of said content elements thereby to create said scripted dialogue.

58. The authoring tool according to claim 57, further comprising a graphical user interface, and wherein the content elements are provided in the form of user selectable graphical indicia.

59. The authoring tool according to claim 58, wherein the graphical user interface comprises a storyboard on to which content elements (optionally) in the form of expressive responses can be dragged and dropped.

60. The authoring tool according to claim 59, wherein the storyboard comprises a plurality of panels, and preferably wherein at least one panel comprises a tool for setting the theme and/or at least one character.

61. (canceled)

62. The authoring tool according to claim 60, wherein at least one panel provides a placeholder for a content item (preferably an expressive response) associated with a character, and wherein the authoring tool is adapted to receive a user-selected expressive response and replace the placeholder with the user-selected expressive response.

63. The authoring tool according to claim 60, wherein the authoring tool is adapted to provide a plurality of potential expressive responses for user selection, and preferably wherein the authoring tool is adapted to provide a plurality of potential expressive responses in dependence on at least one of: the panel; the theme setting; the character; and prior user-selected expressive responses, and/or wherein the plurality of potential expressive responses provided is filtered in dependence on at least one of: the panel; the setting; a character; a user-selected expressive response.

64-65. (canceled)

66. The authoring tool according to claim 63, wherein the authoring tool is adapted to receive a user input and adapt at least one of the potential expressive responses to comprise the user input.

67. A method of creating themed data for toys, comprising receiving content in the form of a scripted dialogue relating to a particular theme; processing said content to generate a set of instructions for operating said toy within said particular theme; and outputting said set of instructions.

68. The method according to claim 67, further comprising providing a plurality of user selectable content elements, and receiving a user selection of at least one of said content elements thereby to create said scripted dialogue, and preferably wherein the user selectable content elements are selected via a graphical user interface, and more preferably wherein the content element is at least one of: an expressive response; a role; a number of participating roles; a theme; and a topic.

69-70. (canceled)

71. An apparatus for creating themed data for toys, comprising an interface for receiving content in the form of a scripted dialogue relating to a particular theme; a suitably programmed processor and associated memory for processing said content to generate a set of instructions for operating said toy within said particular theme; and an output for outputting said set of instructions.

72. The apparatus according to claim 71, further comprising a suitably programmed processor and associated memory for providing a plurality of user selectable content elements, and a suitably programmed processor and associated memory for receiving a user selection of at least one of said content elements thereby to create said scripted dialogue, and preferably further comprising a graphical user interface, and wherein the content elements are provided in the form of user selectable graphical indicia.

73-186. (canceled)