U.S. patent application number 14/197133 was filed with the patent office on 2015-05-21 for interacting toys.
The applicant listed for this patent is Hydrae Limited. Invention is credited to Robert Frederick Kilbride Newman, Steven LIPMAN, Alon Shmuel.
Application Number | 20150140893 14/197133 |
Document ID | / |
Family ID | 38476662 |
Filed Date | 2015-05-21 |
United States Patent
Application |
20150140893 |
Kind Code |
A1 |
LIPMAN; Steven ; et
al. |
May 21, 2015 |
INTERACTING TOYS
Abstract
There is provided as toy adapted to have an interaction with at
least one other such toy, comprising: a processor and a memory
coupled to said processor; wherein said processor comprises: means
for generating an output signal representative of an action to be
performed; and means for generating a trigger signal, for reception
at at least one other such toy, to trigger said other such toy to
perform an action before the said toy has completed its own action.
Furthermore, the trigger signal is generated at pre-determined time
interval after said toy has initiated its own action, or the
trigger signal is generated at a pre-determined time interval
before said toy has completed its own action.
Inventors: |
LIPMAN; Steven; (London,
GB) ; Kilbride Newman; Robert Frederick; (Witney,
GB) ; Shmuel; Alon; (London, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Hydrae Limited |
Ramsey |
|
IM |
|
|
Family ID: |
38476662 |
Appl. No.: |
14/197133 |
Filed: |
March 4, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13054789 |
Jan 18, 2011 |
8827761 |
|
|
PCT/GB09/00160 |
Jan 21, 2009 |
|
|
|
14197133 |
|
|
|
|
Current U.S.
Class: |
446/175 |
Current CPC
Class: |
A63H 2200/00 20130101;
A63H 3/28 20130101; A63H 30/00 20130101; H04L 67/2833 20130101;
A63H 30/04 20130101 |
Class at
Publication: |
446/175 |
International
Class: |
A63H 3/28 20060101
A63H003/28 |
Foreign Application Data
Date |
Code |
Application Number |
Jul 18, 2008 |
GB |
PCT/GB2008/002457 |
Claims
1. 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; and means for
outputting said set of instructions, wherein said receiving means
is adapted to receive, in one operation, content that comprises an
entire theme, or a substantial part of a theme, enabling a toy to
have an interaction with at least one other such toy within that
theme.
2-72. (canceled)
73. An authoring tool according to claim 1, wherein said content is
in the form of a pre-formatted file.
74. An authoring tool according to claim 73, wherein said
pre-formatted file is a text file.
75. An authoring tool according to claim 74, wherein the text file
comprises an entire (preferably self-contained) conversation
enabling a toy to have a conversation with at least one other such
toy.
76. An authoring tool according to claim 74, wherein the text file
comprises content in a script format.
77. An authoring tool according to claim 76, wherein the script
format comprises at least one toy identifier followed by expression
data, and preferably a statement.
78. An authoring tool according to claim 77, wherein the means for
processing comprises: means for identifying a toy identifier in the
content; means for creating a toy instance for expression data
associated with the toy identifier; and means for extracting
expression data associated with the toy identifier from the content
and assigning it to the toy instance.
79. An authoring tool according to claim 78, wherein the processing
means further comprises means for determining if, for a particular
toy identifier, a toy instance already exists or not.
80. An authoring tool according to claim 79, wherein if, for the
particular toy identifier, a toy instance already exists then the
extracted expression data associated with that toy identifier is
assigned to the existing toy instance; and if no toy instance
already exists then a new toy instance is generated for that toy
identifier and the extracted expression data associated with that
toy identifier is assigned to the new toy instance.
81. An authoring tool according to claim 73, wherein said
processing means generates said set of instructions using only the
content of said pre-formatted file.
82. An authoring tool according to claim 77, wherein said
expression data comprises at least one of: a theme name, the toys'
names and statements used by the toys to interact.
83. An authoring tool according to claim 1, wherein said content
further comprises scripting data comprising at least one of: the
number of toys that can interact within the theme, a method of
interaction, theme related parameters, and toy related
parameters.
84. An authoring tool according to claim 83, wherein said toy
related parameters include information relating to pre-defined
rules for selecting the next toy to interact.
85. An authoring tool according to claim 1, wherein said receiving
means is adapted to receive content that comprises scripting data
relating to the particular theme, and the scripting data comprises
a method of interaction, and the method of interaction comprises
timing related parameters.
86. An authoring tool according to claim 85, wherein said timing
related parameters determine when the next toy interacts.
87. An authoring tool according to claim 86, wherein said timing
related parameters include at least one of: the time delay between
the start of the current toy's interaction to the start of the next
toy's interaction; and the time delay from the start of the next
toy's interaction before the current toy's interaction ends.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a continuation application of
U.S. patent application Ser. No. 13/054,789, filed Jan. 18, 2011,
entitled "Interacting Toys," which is a U.S. National Phase
application under 35 U.S.C. .sctn.371 of International Application
No. PCT/GB2009/000160, filed on Jan. 21, 2009, entitled INTERACTING
TOYS, which claims priority to International Application No.
PCT/GB2008/002457, filed on Jul. 18, 2008.
FIELD
[0002] This invention relates to toys. In particular, although not
exclusively, this invention relates to toys such as dolls that
interact with each other.
BACKGROUND
[0003] 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.RTM.
Barney.RTM. is one example of an interactive toy which responds to
interaction from a child by appropriate vocalisations, and can
sing-a-long to videos.
[0004] PCT patent application WO 2006/114625 is incorporated herein
by reference.
SUMMARY
Syncing
[0005] According to a first aspect of the present invention there
is provided a toy adapted to have an interaction with at least one
other such toy, comprising: a processor and a memory coupled to
said processor; wherein said processor comprises: means for
generating an output signal representative of an action to be
performed; and means for generating a trigger signal, for reception
at at least one other such toy, to trigger said at least one other
such toy to perform an action before the said toy has completed its
own action. By providing means for generating a trigger signal for
triggering another such toy to perform an action before the said
toy has completed its own action, a more versatile toy, and in
particular a more life-like interaction, can be provided.
[0006] For a more life-like interaction, preferably said trigger
signal is generated at pre-determined time interval after said toy
has initiated its own action. Preferably said trigger signal is
generated at a pre-determined time interval before said toy has
completed its own action.
[0007] For ease of use, preferably the toy further comprises an
input enabling a user to input a measure of said pre-determined
time interval.
[0008] For ease of synchronisation, preferably the pre-determined
time interval is less than second or half or quarter of a second,
and is more preferably substantially 0 seconds. By having a time
interval of 0 seconds the actions of the toys are effectively
synchronised.
[0009] Preferably the action is at least one of: emitting sound,
emitting light, and movement.
[0010] For efficiency of communication, preferably the toy further
comprises a wireless communication module adapted to wirelessly
communicate with said at least one other such toy. More preferably,
the wireless communication module transmits at least one of: the
trigger signal; information relating to the interaction; and
information relating to the toy.
[0011] Preferably said information relating to the interaction
includes at least one of: the action output by the toy; the
duration of the action; and the action for the at least one other
toy to take.
[0012] Preferably the memory is adapted to store a pre-determined
interaction.
[0013] Preferably the processor is adapted to determine said
interaction pseudo-randomly,
[0014] For a more life-like interaction, preferably said toy is
adapted to interact as if it were animate. Preferably said
interaction is at least one of: a conversation, a vocal
interaction, an inter-personal interaction, an educational
interaction, playing music, and playing a game. Preferably, said
toy is adapted to interact as a member in a group of such toys.
More preferably, said group represents one of: a music band; a
group of cars; or a group of military assets. Yet more preferably,
said trigger signal is used to synchronise the actions of the
group.
[0015] Preferably the toy further comprises means for receiving a
trigger signal from another such toy, and uses said trigger signal
to determine a time to initiate an action.
[0016] Preferably said toy is one of: a doll, a game board, a
vehicle, and a military asset.
[0017] According to a further aspect of the present invention there
is provided a computer readable memory, for use in a toy adapted to
have an interaction with at least one other such toy, said memory
containing a set of instructions comprising: code for generating an
output signal representative of an action to be performed; and code
for generating a trigger signal, for reception at at least one
other such toy, to trigger said at least one other such toy to
perform an action before the said toy has completed its own action.
As used herein the term computer readable memory includes the term
computer program product.
[0018] Preferably, the computer readable memory further comprises
code for generating said trigger signal at a pre-determined time
interval after said toy has initiated its own action.
[0019] Preferably, the computer readable memory further comprises
code for generating said trigger signal at a pre-determined time
interval before said toy has completed its own action.
[0020] Preferably, the computer readable memory further comprises
code for enabling a user to input a measure of said pre-determined
time interval.
[0021] Preferably, said pre-determined time interval is less than 1
second or half or quarter of a second, and is preferably
substantially 0 seconds.
[0022] Preferably, said action is at least one of: emitting sound,
emitting light, and movement.
Authoring Tool
[0023] According to a further aspect of the present 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;
and means for outputting said set of instructions. By providing
means for generating a set of instructions for operating a toy the
process of generating themed instruction can be made substantially
more efficient.
[0024] For efficiency of receiving the content, preferably said
receiving means is adapted to receive content that comprises
separately both scripting data relating to the particular theme,
and expression data defining the personality of said toy.
Preferably, said receiving means is adapted to receive content in
discrete portions.
[0025] For efficiency of processing, preferably the authoring tool
further comprises means for allocating a unique ID number to each
expression data portion. Preferably, said processing means is
adapted to utilise said unique ID numbers as references to said
expression data portions in said set of instructions.
[0026] Preferably, said expression data comprises at least one of:
a theme name, the toys' names and statements used by the toys to
interact.
[0027] Preferably, said scripting data comprises at least one of:
the number of toys that can interact within the theme, a method of
interaction, theme related parameters, and toy related
parameters.
[0028] For efficiency of processing, preferably the authoring tool
further comprises means for storing together, in an array, said
scripting data and expression data relating to a particular theme.
More preferably, said processing means is adapted to generate said
set of instructions from said array.
[0029] For efficiency of processing, preferably said processing
means includes means for compiling at least one list comprising at
least some of the expression data. More preferably, said list
compiling means is adapted to compile a respective list for each
toy in said particular theme.
[0030] Preferably, the expression data is symbolic data. Symbolic
data as used herein connotes the written form of words, music or
actions.
[0031] Preferably, the authoring tool further comprises recording
means for recording enacted data versions of the symbolic data.
Enacted data as used herein connotes the enacted form of words,
music or actions.
[0032] Preferably, the authoring tool comprises means for prompting
an actor to generate the requisite portion of enacted data.
[0033] Preferably, said processor is adapted to generate a lookup
table between the symbolic data and enacted data.
[0034] Preferably, said processing means is adapted to output the
expression data. More preferably, said processing means is further
adapted to output the expression data and set of instructions
separately.
[0035] Preferably, said processing means is adapted to generate a
set of instructions that includes: a base set of instructions for
controlling the basic functions of the toy; and a themed set of
instructions for the base set of instructions to control the toy
within the theme. More preferably, said processor is adapted to
combine said base set and said themed set of instructions
together.
[0036] Preferably the authoring tool further comprises a compiler.
More preferably, said compiler is adapted to compile said base set
and said themed set of instructions.
[0037] Preferably, said processor includes a coding engine adapted
to transform said set of instructions into computer readable
code.
[0038] Preferably, the output of the authoring tool is adapted to
be used in a conversation engine as described herein.
[0039] Preferably, the toy is a toy as described herein.
[0040] According to a second aspect of the present invention, there
is provided a user interface for an authoring tool for creating
themed data for a toy, comprising: means for providing a user with
a set of input windows, each window corresponding to the input of a
particular sub-set of content relating to a theme; and means for
initiating output of the themed data.
[0041] Preferably, said sub-sets of content include at least one
of: theme related data, toy related data, and context related
data.
[0042] Preferably, the context related data includes at least one
of: statements used by the toys to interact, a method of
interaction, theme related parameters, and toy related
parameters.
[0043] Preferably, the receiving means is adapted to receive, in
one operation, content that comprises an entire theme, or a
substantial part of a theme. More preferably, the content is in the
form of a pre-formatted file. Yet more preferably, the
pre-formatted file is a text file.
[0044] Preferably, the processing means generates the set of
instructions using only the content of said pre-formatted file.
[0045] Preferably, said toy related parameters include information
relating to pre-defined rules for selecting the next toy to
interact.
[0046] Preferably, said method of interaction comprises timing
related parameters. More preferably, said timing related parameters
determine when the next toy interacts. Yet more preferably, said
timing related parameters include at least one of: the time delay
between the start of the current toy's interaction to the start of
the next toy's interaction; and the time delay from the start of
the next toy's interaction before the current toy's interaction
ends.
[0047] Preferably, the authoring tool further comprises means for
receiving content relating to a game. More preferably, said content
relating to a game includes logic for enabling the game to be
executed.
[0048] Preferably, the authoring tool is adapted to implement any
of the methods of interaction as herein described.
[0049] According to a third aspect of the present invention, there
is provided a system for generating themed data for a toy,
comprising: an authoring tool for accessing, creating and editing
said themed data; and a server, comprising a database for storing
said themed data; wherein the authoring tool is adapted to access
the themed data via the internet.
[0050] Preferably, said authoring tool is adapted to process the
themed data into an array, and said database is adapted to store
said themed data in said array.
[0051] Preferably, said authoring tool is an authoring tool as
described herein.
[0052] Preferably, the further comprises a user interface. More
preferably, the user interface is an interface as described
herein.
USB Communications Dangle
[0053] According to a further aspect of the present invention,
there is provided a device for providing wireless communications
between at least one toy as described herein, and a computer,
comprising: a communication port for connecting the device to the
computer; and means for establishing a network between the computer
and the or each toy; wherein said device allows the computer to
communicate with the or each toy as if it were another such
toy.
[0054] Preferably, said device enables said computer to act as a
virtual toy.
[0055] Preferably, said communication port is a USB communication
port.
[0056] Preferably, said network is wireless.
[0057] According to a yet further aspect of the present invention,
there is provided a system comprising: at least one toy as
described herein; and at least one computer, each with a device for
providing wireless communications as described herein; wherein the
combination of said computer and device acts as if it were a toy as
described herein.
[0058] Preferably, said computer comprises a visual, and an audio
output adapted to provide a virtual toy. More preferably, said
virtual toy is an avatar.
Controller Doll
[0059] According to a yet further aspect of the present invention,
there is provided a toy comprising: a processor; a memory coupled
to said processor; an output coupled to said processor; and means
for establishing a network connection with at least one further
such toy; wherein the processor includes means for controlling the
output of each toy with which a network connection has been
established.
[0060] Preferably, said controlling means is adapted to transmit,
over said network connection, instructions to control a plurality
of the outputs (preferably all of the outputs) of each toy with
which a network connection has been established.
[0061] Preferably, said network connection forms part of a personal
area network.
[0062] Preferably, said memory is adapted to store at least one
group of data, each said at least one group representing a
particular theme.
[0063] Preferably, the toy further comprises means for determining
the at least one theme stored in said memory.
[0064] Preferably, said toy is adapted to only establish a
connection with another toy when at least one theme stored in said
memory is the same in both toys.
[0065] Preferably, said controlling means is adapted to
transmit/receive a control message to control the output of each
said toy, and wherein preferably the control message comprises an
ID of the toy for which it is intended, and a command segment, and
more preferably further comprises an ID of the originating toy
and/or a message ID.
[0066] Preferably, said control message comprises instructions to
access a reference database and perform a task,
[0067] Preferably, the processor includes means for
transmitting/receiving acknowledgement of a transmitted/received
control message, and wherein preferably said transmitting/receiving
means is adapted to request that the control message is re-sent if
it does not receive acknowledgement.
[0068] Preferably, said transmitting/receiving means is adapted to
transmit a parameter associated with the time that such toy will
take to generate an output in dependence on the control message,
and wherein preferably the originating toy waits for a duration
associated with said parameter before transmitting a further
control message (the time such toy will take to generate such
output may vary, according for example with a theme or sub-theme of
the toy).
[0069] Preferably, the processor comprises means for counting the
number of re-sent control messages, and whereby communication with
said toy that does not acknowledge said control message is stopped
after 1,000-2,000, 2,000-5,000, 5,000-10,000 or more attempts to
resend.
[0070] Preferably, said processor further comprises a conversation
engine adapted to construct a conversation between said toys.
[0071] Preferably, the further such toy is identical or
substantially identical to the first such toy. Therefore, no "Spoke
and Hub" arrangement is required.
[0072] Preferably, said means for establishing a network is a
network controller, preferably a network controller utilising the
Zigbee protocol.
Parameter Storage
[0073] Preferably, the toy is adapted to interact with another such
toy, wherein said processor includes means for defining at least
one variable associated with said interaction, means for storing
said variable in said memory and means for using said variable to
control an (interactive) output of said toy.
[0074] According to a yet further aspect of the present invention,
there is provided a toy adapted to interact with another such toy,
comprising: a processor; a memory coupled to said processor; and an
output coupled to said processor; wherein said processor includes
means for defining at least one variable associated with said
interaction, means for storing said variable in said memory and
means for using said variable in association with an (interactive)
output of said toy (thereby preferably more efficiently keeping
track of the interaction).
[0075] Preferably, said variable is used a plurality of times (more
preferably a multiplicity of times) to control said output.
[0076] Preferably, said variable is used to determine the number,
type or nature of said interaction, and wherein preferably said
variable is said interaction.
[0077] Preferably, said variable is selected randomly or
pseudo-randomly, and said random selection is affected by
weightings.
[0078] Preferably, the toy further comprises means for generating
an interaction. The means for generating an interaction is
preferably adapted to generate the interaction in dependence upon
the stored parameter.
[0079] Preferably, the storing means associates each variable with
a toy.
[0080] Preferably, the storing means is memory located within the
toy.
[0081] Preferably, the means for using the variable is adapted to
access the variable from the storing means.
[0082] Preferably, said interaction is a communication between the
toys.
[0083] Preferably, said variable is a word or phrase utilised in
speech.
Expressing Personality and Scripting Themes
[0084] Preferably, said processor is adapted to store themed data
in said memory, said theme comprising scripting data and expression
data, said expression data defining the personality of said
toy.
[0085] According to a yet further aspect of the present invention,
there is provided a toy comprising: a processor; a memory coupled
to said processor; and an output coupled to said processor; wherein
said processor is adapted to store themed data in said memory, said
theme comprising scripting data and expression data, said
expression data defining the personality of said toy (thereby
preferably providing multiple, thorned, toy personalities more
efficiently).
[0086] Preferably, the toy is adapted to interact with at least one
other similar toy, wherein said scripting data is shared by each
such toy and said expression data is different between each such
toy.
[0087] Preferably, said scripting data is independent of said
expression data.
[0088] Preferably, the processor is adapted to output the scripting
data as a control message to another such toy, and is adapted to
respond to a control message with its individual expression
data.
[0089] Preferably, the scripting data is the same for each toy, and
controls the output of each toy.
[0090] Preferably, the processor is adapted to utilise the
scripting data to reference the expression data, and preferably the
expression data communicates the same information using different
content.
[0091] Preferably, the personality of the toy is defined by the
content of the communication.
[0092] Doll Choice
[0093] Preferably, said processor includes means for selecting a
toy to interact based on pre-defined rules.
[0094] According to a yet further aspect of the present invention,
there is provided a toy adapted to interact with other such toys,
comprising: a processor; a memory coupled to said processor; and an
output coupled to said processor, wherein said processor includes
means for selecting a toy to interact based on pre-defined rules,
and wherein said selected toy may be the originating toy.
[0095] Preferably, said selecting means is adapted to select the
next toy to interact.
[0096] Preferably, said pre-defined rules comprise: direct
selection; random selection; and choose the current interacter to
interact again.
[0097] Preferably, the processor is adapted to output a control
message comprising the ID of the selected toy and preferably the ID
of the originating toy.
[0098] Preferably, said interaction comprises communication and
wherein preferably said communication includes speech and
directions.
Game Playing
[0099] Preferably, the toy is in the form of an animate object,
suitable for playing games with other similar toys, wherein said
processor includes a games engine, wherein said games engine is
adapted to allow said toy to play games as if the toy were
animate.
[0100] According to a yet further aspect of the present invention,
there is provided a toy in the form of an animate object, suitable
for playing games with other similar toys, comprising: a processor;
a memory coupled to said processor; an output coupled to said
processor; wherein said processor includes a games engine that
enables each said toy to play a game as if said toy were its
relevant animate object.
[0101] Preferably, said games engine is adapted to enable a human
game.
[0102] Preferably, said human game is played with games
equipment.
[0103] Preferably, said games engine is adapted to output an
instruction to enable a human to adjust the games equipment to play
the game.
[0104] Preferably, said toy further comprises means for
communicating with at least one further such toy.
[0105] Preferably, said games engine is further adapted to play
rules based games.
[0106] Preferably, said game engine is adapted to store information
regarding the game in said memory.
[0107] Preferably, said information comprises the rules of the
game.
[0108] Preferably, said information further comprises the layout of
at least one playing board.
[0109] Preferably, said games engine comprises a random number
generator adapted to be a virtual die.
[0110] Preferably, the games engine comprises means for receiving
an external input regarding the game.
[0111] Preferably, said external input is associated with the
playing piece of the game.
[0112] Preferably, said external input is at least one sensor
within the playing board.
[0113] Preferably, said external input is a switch adapted to be
used by a user of said toy.
[0114] Preferably, said rules based games include Snakes and
Ladders, and Ludo.
[0115] Preferably, said output is a transducer. Preferably, said
transducer is a loudspeaker. Preferably, said transducer is an
actuator.
[0116] According to a yet further aspect of the present invention,
there is provided a combination comprising a plurality of such
toys.
[0117] Preferably, each one of said plurality of toys comprises
means for controlling the other said toys, whereby only one toy
controls the other said toys at a time.
[0118] Preferably, said memory is adapted to store information
relating to the game state. The game state may be at least one of:
the layout of a playing board; the position of at least one counter
on a playing board; and the order of play for all of the toys
and/or user.
Doll Specific Download
[0119] According to a yet further aspect of the present invention,
there is provided a device for providing a plurality of toys with
themed data comprising: means for storing said themed data, wherein
each said theme comprises a plurality of sub-themes; means for
identifying a specific toy; means for selecting a sub-theme
according to the specific toy; and means for outputting said
specific sub-theme to said toy (thereby preferably accessing themed
downloads is accomplished more efficiently).
[0120] Preferably, the toy further comprises means for storing a
plurality of different themes.
[0121] Preferably, the toy further comprises means for allowing a
user to select one of the said plurality of themes.
[0122] Preferably, said means for identifying a specific toy uses a
unique identification number of said toy.
[0123] Preferably, the toy further comprises means for encrypting
each said sub-theme according to a parameter associated with said
toy. Preferably, said parameter is the toy's unique identification
number.
[0124] Preferably, the device comprises a processor and associated
memory for storing the themed data and identifying the specific
toy.
[0125] Preferably, the device further comprises a connection for
outputting the sub-theme to the toy. Preferably the connection
comprises the internet and a USB cable.
Conversation Engine
[0126] According to a yet further aspect of the present invention,
there is provided a conversation engine for a device such as a toy
comprising means for selecting a theme for the conversation;
randomly choosing a starting point from a plurality of starting
points; randomly choosing phrases based on variables; and randomly
choosing the next speaker based on variables.
[0127] Preferably, said phrase choices are further based on
weightings.
[0128] Preferably, the toy incorporates a conversation engine.
[0129] Preferably, the toy, or conversation engine, is adapted to
receive input data from the user.
[0130] Preferably, the toy, or conversation engine, is adapted to
output data to the user.
[0131] Preferably, the conversation engine is further adapted to
utilise the input data from the user in random choosing
process.
[0132] Preferably, the conversation engine comprises a processor
adapted to carry out the selecting operation.
[0133] Preferably, the toy, or conversation engine, is adapted to
construct the conversation in real-time.
[0134] Preferably, the toy, or conversation engine, is adapted to
pre-process a conversation. The toy, or conversation engine, is
preferably further adapted to output the pre-processed
conversation.
[0135] Preferably, the toy, or conversation engine, is adapted to
utilise the parameters of the other toys present in the established
network as a variable when constructing the conversation.
[0136] Preferably, the toy, or conversation engine, is adapted to
output data in dependence on weightings.
[0137] Preferably, the toy is adapted to store a plurality of sets
of themed data. The toy is preferably further adapted to utilise at
least two of the plurality of sets of themed data during a single
conversation.
[0138] Preferably, the toy is adapted to enable a network to be
established with a plurality of other such toys, preferably, 2, 3,
4 or more.
[0139] Preferably, the toy is adapted to be animate.
[0140] Preferably, the toy is adapted to communicate with other
such toys, and said communication includes, speech, actions, and
gestures,
[0141] Preferably, the toy or conversation engine has one, some, or
all of the following features in any combination:
[0142] Chad can play interactively with the toys
[0143] Conversation constructed on-the-fly
[0144] Conversation is preprocessed prior to starting the
conversation
[0145] Conversation is based on the dolls present in the
network
[0146] Conversation is based on the type of doll present in the
network
[0147] Weightings used to control the conversation length and
direction
[0148] Ability to switch between themes mid conversation
[0149] Two, three or more toys
[0150] Toys are animate/human/dolls
[0151] Interaction includes communication; communication is defined
in a broad sense
[0152] In summary, the present invention refers amongst others to
the following inventions:-- [0153] Authoring tool--provides the
facility for inputting conversation data to be compiled into
program code readable by the toys. [0154] USB communications
dongle--provides a device for enabling communication between a toy
and a PC. [0155] Controller doll--more than two dolls, control is
conducted using as a single controller the first doll that is
switched on. [0156] Expression of personality--same theme has
different expression based on the personality factor of the doll.
[0157] Scripting themes--themes are a downloadable combination of
expression and script/script and expression are integral/different
script for each different theme. [0158] Parameter
storage--capability of storing information relevant to the current
conversation, e.g. in the phrase "My dog is called Fluffy" the doll
stores the information (pet="dog" and name of pet="fluffy") for use
later in that conversation, [0159] Doll specific downloads--website
download only has as expression the specific language relevant to
the given personality/expression is downloaded according to
personality [0160] Construction of conversations--dolls choose
either to respond with relevant speech, select another doll and
address them, or announce something about themselves. [0161] Doll
choices--controller decides which doll speaks next randomly; select
randomly but no doll can speak twice in a row, or select a specific
doll by name. [0162] Game playing--dolls play games as if
humans.
[0163] The invention also provides a computer program and a
computer program product comprising software code adapted, when
executed on a data processing apparatus, to perform any of the
methods described herein, including any or all of their component
steps.
[0164] The invention also provides a computer program and a
computer program product comprising software code which, when
executed on a data processing apparatus, comprises any of the
apparatus features described herein.
[0165] The invention also provides a computer program and a
computer program 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.
[0166] The invention also provides a computer readable medium
having stored thereon the computer program as aforesaid.
[0167] The invention also provides a signal carrying the computer
program as aforesaid, and a method of transmitting such a
signal.
[0168] The invention extends to methods and/or apparatus
substantially as herein described with reference to the
accompanying drawings.
[0169] Apparatus and method features may be interchanged as
appropriate, and may be provided independently one of another. Any
feature in one aspect of the invention may be applied to other
aspects of the invention, in any appropriate combination; equally,
any feature in one invention may be applied to any other invention,
in any appropriate combination. For example, method aspects may be
applied to apparatus aspects, and vice versa. Again, for example,
any "Controller doll" feature may be applied to any "Parameter
storage" feature.
[0170] Furthermore, features implemented in hardware may be
implemented in software, and vice versa. Any reference to software
and hardware features herein should be construed accordingly.
[0171] Herein, any use of the term "means for" plus a function may
be replaced by the appropriate hardware component (for example a
processor and/or memory) adapted to perform that function.
BRIEF DESCRIPTION OF THE DRAWINGS
[0172] Embodiments of this invention will now be described, by way
of example only, with reference to the accompanying drawings, of
which:
[0173] FIG. 1 shows three types of doll;
[0174] FIG. 2 is a schematic illustration of a doll;
[0175] FIG. 3 is a schematic illustration of a controller toy, with
slave toys;
[0176] FIG. 4 is a schematic illustration of a doll connected to a
website enabled to download themes/sub-themes to the doll;
[0177] FIG. 5 is a schematic illustration of a doll adapted to play
games;
[0178] FIG. 6 is a flow diagram of the process of playing a
game;
[0179] FIG. 7 is a schematic of an alternative embodiment;
[0180] FIGS. 8A, 8B, and 8C illustrate an embodiment of a circuit
diagram of the processor and associated electronics;
[0181] FIGS. 9A, 9B, and 9C illustrate an alternative embodiment of
a circuit diagram of the processor and associated electronics;
[0182] FIG. 10 shows user PCs in communication with an authoring
tool server;
[0183] FIG. 11 shows an overview of the authoring tool, and
associated systems;
[0184] FIG. 12A shows a conversation designer window;
[0185] FIG. 12B shows a theme generation window;
[0186] FIG. 12C shows a populated theme generation window;
[0187] FIG. 12D shows an alternative embodiment of a theme
generation window;
[0188] FIG. 12E shows a flow diagram of the text file import
feature;
[0189] FIG. 13A shows an add doll window;
[0190] FIG. 13B shows a create doll window;
[0191] FIG. 14 shows a doll context window;
[0192] FIG. 15A shows a conversation entry window;
[0193] FIG. 15B shows an alternative embodiment of the conversation
entry window;
[0194] FIG. 16 shows a USB dongle in communication with multiple
dolls;
[0195] FIG. 17A shows a schematic illustration of two dolls and a
timeline of actions;
[0196] FIGS. 17B, 17C, and 17D, show examples of the various
timings for triggering another toy.
DETAILED DESCRIPTION
[0197] FIG. 1 shows three types of toy doll; 10 is a tennis playing
doll, 20 is a ballerina doll, 30 is a generic doll shown walking a
dog, and 40 is a toy in the form of a tank. In general the toys are
adapted to appear animate and in particular human, or human
controlled in the case of the tank and the like. The four toys
shown are examples of types of themed toys. The toys are adapted to
communicate wirelessly with other such toys within the theme.
[0198] 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.
[0199] FIG. 2 shows a schematic representation of the doll, with
the hardware components required to allow the doll to communicate,
and perform other such tasks. The doll 100, as shown in FIG. 2,
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 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. Alternatively, the doll is adapted to use replaceable
batteries, rather than rechargeable batteries.
[0200] 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 the current conversation and is used in order to
produce more realistic conversation by storing information relating
to the phrases already used for example.
[0201] Each doll 100 contains in memory 106: a data set containing
the doll's name, and other 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 only
stored in the controller doll.
[0202] In one embodiment the processor is in the form as used in
MP3 decoding, with the associated memory interfaces (such as SD
cards). This embodiment provides a significant amount of processing
power (and hardware based compression technology) and would
therefore allow for long and detailed conversations between the
dolls.
Controller Doll
[0203] As can be seen in FIG. 3 the controller unit, 200, is in
communication with a number of slave units, 202. The controller
includes a conversation engine 204, a speech compiler 206, a speech
database 208, a loudspeaker (transducer) 210, a
transmitter/receiver 212 capable of transmitting and receiving data
from the slave units. The conversation engine comprises a random
speech selector 214, a parameter storage memory 216 and a speaker
selector 218. The slave unit has all of the components of the
controller unit; not all of the slave unit's components are shown
in FIG. 3.
[0204] The first unit to be powered on is initialised to be the
controller unit. When a unit is powered on it searches for an
existing network, and when no network exists it creates a network
and waits for other units to join the network. When further units
are turned on they join the network and are initialised as slave
units. The controller unit awaits communications from both new
units indicating they require the network details, and conversation
initiation messages. The slave units, once they have joined the
network, await instructions from the controller unit. It should be
understood that all of the units (toys/dolls) are identical in as
far as they are all able to become the controller unit, or a slave
unit.
[0205] The units are adapted to communicate within themes, such as
"The Zoo", "Sport", "Gangsta" or "Fashion". Themes allow the units
to have detailed conversations without requiring extremely large
databases of information relating to all of the possible
conversation topics. The themes/sub-themes can be downloaded to the
units by the user from a website.
[0206] The following process is used to initiate a network of toys:
[0207] When a doll is turned on it performs a check to determine
whether there is an existing network to join this is accomplished
using the transmitter/receiver 212, [0208] If there is not a
network available then that doll becomes the controller, and
automatically sets up a network--the wireless module 104 is adapted
to create a network where necessary. [0209] Each subsequent doll
that is turned on transmits a doll ID number and theme/themes ID
number that they have stored in memory--the information is
transmitted via the transmitter 212. [0210] The controller checks
the theme/themes and only allows dolls with the same theme/themes
as the controller to join--the controller unit performs a
comparison of the transmitted data with the data is has stored in
memory. [0211] Once two or more dolls have joined the network it is
possible to initiate a conversation [0212] The user initiates the
conversation by pressing a button or the like, and the controller
starts a conversation instructing the other dolls what to say
[0213] The user can press the button again to stop the conversation
at any point
[0214] The controller unit runs the program to generate
conversations and then transmits information to the slave units to
inform them which audio files to access (the audio files can be
different for each personality type, but the reference to each of
the audio files is the same for each unit). The controller unit
transmits the identifiers of the words/phrases to access from the
slave unit's memory. The slave unit acknowledges receipt of the
message by transmitting a message verifying the phrase to be used,
and the expected length of time required to say the phrase. The
slave unit then uses the speech compiler to compile the
words/phrases and then uses the loudspeaker to say the phrase. Once
the slave unit has finished saying the phrase it transmits a signal
to the controller unit that it has finished and the conversation
can carry on.
[0215] The controller unit then instructs the next speaker in the
same way, and so on until the conversation comes to an end. Further
detail regarding conversation construction is provided below.
Communication Protocol
[0216] The toys communicate using a communication protocol; the
format of the messages is as follows:
[0217] [MessageID, SendingToy_ID, ReceivingToy_ID, MessageType,
Parameters]
[0218] The MessageID is a unique number identifying the message.
Each message sent from the controller toy has a unique identifying
number.
[0219] The SendingToy_ID indicates the toy sending the message.
[0220] The ReceivingToy_ID indicates the toy that is to receive the
message.
[0221] The MessageType indicates the type of message e.g. START,
STOP, SAY.
[0222] The Parameters are any other required information related to
the message type. Only the SAY message has a parameter, which
identifies the phrase(s) to be spoken.
[0223] Therefore, the range of messages comprises: [0224]
[MessageID, SendingToy_ID, ReceivingToy_ID, START] [0225]
[MessageID, SendingToy_ID, ReceivingToy_ID, STOP] [0226]
[MessageID, SendingToy_ID, ReceivingToy_ID, SAY, PhraseID]
[0227] Each of these messages will produce an acknowledgement of
the following form:
[0228] [MessageID, SendingToy_ID, ReceivingToy_ID, Ack,
Parameter]
[0229] The parameter is only used for acknowledging the SAY message
and it specifies the duration of the phrase. The controller unit
uses the duration of phrase parameter to wait for the appropriate
length of time before sending the next message.
[0230] So the normal sequence of events for each message, assuming
Toy 1 is communicating with Toy 2, is as follows:
TABLE-US-00001 [MessageID, 1, 2, START] [MessageID, 2, 1, ACK]
[MessageID, 1, 2, SAY, [MessageID, 2, 1, ACK, PhraseID] DURATION]
[MessageID, 1, 2, STOP] [MessageID, 2, 1, ACK]
[0231] The START command instructs the receiving toy to expect to
receive further incoming messages. The controller doll then sends
at least one message containing the phraseID of the phrase that the
slave toy is required to use. Each phraseID is sent separately to
the slave toy, and so multiple messages of this type may be sent to
build up an entire sentence. The STOP command is used to instruct
that slave toy that there are no further messages in that
sequence.
[0232] The slave toy, upon receipt of a message, sends a message to
the controller acknowledging the receipt of the message. The
controller continues with the conversation program immediately for
the START and STOP acknowledgements; however, for the SAY command
the controller doll continues after a delay equal to the DURATION
for the SAY acknowledgement. If the acknowledgement is not received
then the message is resent until an acknowledgment is received.
This resending happens a large number of times at which point the
dolls will reset and the conversation will stop; for example, the
message is resent between 1,000-2000, 2000-5000, 5000-10,000 times,
or more.
[0233] An "end of phrase flag" is also attached to the end of each
phrase to inform the slave unit when the phrase has finished. At
this point the slave unit will transmit a message to the controller
indicating that it has finished speaking. Upon receipt of the
message the controller instructs the next unit to speak, the next
speaker may be the controller or another slave unit.
[0234] Alternatively to instructing speech, when the controller toy
is a tank the instructions communicated to the slave units take the
form of directions that the slave unit tanks should move in.
Therefore, the PhraseID would be replaced with a movementID. In
this way the controller tank would simulate a battle or the like.
The toy tanks are provided with means to locate the other toy tanks
in the network so that they may move in a coordinated manner. The
means can take the form of a playing board with position sensors
that the toys are in communication with, or other means of location
such as a camera, transponders or the like.
[0235] In an alternative embodiment, each doll controls its own
actions; i.e. each doll runs the program to generate the
conversation. Therefore, effectively each doll in the network is a
controller doll. In this example, each doll transmits information
to the other dolls relating to the point within the program that
they have reached. This enables the next doll that is due to speak
to continue running the program from the correct point. In
addition, information relating to variables set by the current
controller doll are transmitted to all of the other relevant dolls;
e.g. if it is a global variable it will be transmitted to all of
the other dolls. By enabling each doll within the network to be a
controller, the robustness of the network can be increased. This is
due to the fact that any doll can be removed from the network, even
the current controller doll, and the remaining dolls can work
around the missing doll.
Synchronisation
[0236] In another embodiment the toys are adapted to interact with
other such toys, in a more life-like manner. The toys, in the form
of dolls, vehicles, or the like, are provided with an interaction
engine that enables them to interact as if they were animate. The
interaction engine is adapted to enable the toys to output actions
simultaneously, i.e. without requiring each toy to complete an
action before another toy can begin a separate action. The
interaction engine is similar to the conversation engine as
described herein, but it is enabled--additionally or
alternatively--to handle the output of actions other than speech,
such as movement.
[0237] FIG. 17A is a schematic illustration of two dolls, A and B
1750, and the corresponding timelines showing the various timings
available to synchronise the dolls' actions are shown in FIGS. 17B,
17C, and 17D. Both of dolls A and B are essentially the same, and
include a processor 1700, a memory 1702 coupled to the processor, a
transducer 1704 coupled to the processor, and a wireless
communications module 1706. The memory 1702 stores information
relating to the prospective interaction between the dolls, such as
a conversation or military manoeuvre. The interaction engine 1708
is connected to the processor and enables the interaction to be
constructed. The processor 1700 is adapted to utilise the stored
information to construct an interaction between two or more dolls.
The output of the processor 1700 outputs signals representative of
the actions chosen by the processor, and this is forwarded to
transducer 1704 to turn the output into the appropriate action.
[0238] The processor 1700 is also adapted to generate a trigger
signal which is wirelessly communicated, via the wireless
communications module 1706, to the other dolls within the network.
The trigger signal can be sent at any time before the current doll
has completed its own action. This can enable the dolls within the
network to be synchronised with respect to their outputs.
[0239] As can be seen in FIGS. 178, 17C, and 17D, there are three
types of synchronisation that can be employed: [0240] Timed from
the start of an action [0241] The toy triggers the next toy after a
time interval from starting the current action; in this example
Doll A triggers Doll B to say Phrase 2 after x seconds from
starting to say Phrase 1. [0242] For example, this form of
synchronisation is used to enable Doll B to interrupt Doll A
because Doll B is getting "bored" of what Doll A is saying. [0243]
Zero time interval between actions [0244] The toy triggers the next
toy immediately after starting the current action; in this example,
Doll A triggers Doll B to say Phrase 4 zero seconds after starting
to say Phrase 3. [0245] For example, this form of synchronisation
is used to enable the Dolls to interact as if they were in a music
band, with all members of the band starting to play music at the
same time. [0246] Timed from the end of an action [0247] The toy
triggers the next toy at a time interval before the end of the
current action; in this example, Doll A triggers Doll B to say
Phrase 6 y seconds before ending Phrase 5. [0248] For example, this
form of synchronisation is used to enable Doll B to start
"laughing" at Doll A's joke before Doll A has finished.
[0249] The trigger signal sent to the next toy can contain
information relating to the current interaction, and information
relating to the toy itself. For example, where a single controller
doll controls the entire interaction, the trigger signal will
request that the slave doll outputs a certain action. However, if
each doll controls its own output, then the trigger signal will
inform the next doll where in the interaction they should begin
processing what to output next. In addition, the trigger signal
could include parameters that have been set; for example, if a doll
randomly chooses a name for their pet that name is passed to all
dolls so that they can use that information in constructing a
conversation. Lastly, the trigger signal could include information
relating to the timing; e.g. the trigger signal is not sent when
the next doll must act, but at the beginning of the current doll's
action with information indicating when the next doll should
start.
[0250] An interaction, such as a conversation, playing music or
playing a game, can either be pre-determined, or can vary dependent
on pseudo-random selection of what action to output next. In either
case, the toys are adapted to interact as if they were animate. The
ability for any toy to perform an action at any point provides a
more life-like interaction than one where all actions occur in
sequence. The toys are also provided with an input, such as a port,
that enables an interaction to be downloaded into the toy. The
interaction is in the form of a theme as herein described.
[0251] The synchronisation can allow for the dolls to act as if
they were members of a group. For example, a number of dolls can
act as if they were in a band. In this example, the first doll
initiates a piece of music, and each of the other dolls plays a
different part of that piece of music; i.e. one would act as the
lead singer, one the drummer, one the guitar and one the bass
guitar. The doll would send a signal to each other doll to start
playing their section of the music immediately, thereby creating a
complete piece of musk. In order to avoid problems of maintaining
synchronisation, the musk can be divided into phrases with control,
and timing, being negotiated at the end of each phrase.
[0252] In a similar way, the toys could be grouped into two, or
more, armies with tanks, soldiers and the like (i.e. military
assets). Each army would act as a unit, and the one of the toys
could trigger the other toys to move as a unit. The movement would
be synchronised using the above described methods.
[0253] Another example of grouped actions would be racing cars,
where one of the toys determines the actions of a group of cars to
simulate a motor race. Alternatively a user can control one, or
more, of the cars remotely and initiate a pre-determined set of
actions for the other surrounding cars. Again, the synchronisation
methods would be used to control the actions of the cars, so that
they move together rather than in sequence.
[0254] In another example, one of the dolls in the group is adapted
to be a game board, such as a chess board, ludo board, snakes &
ladders board or the like. The board comprises sensors that allow
the position of the playing pieces to be known, and in this way the
board can interact with the other dolls and the child by outputting
information relating to the stage of game play and whether or not
the playing pieces are in the correct position.
[0255] In a further example, the dolls are adapted to act out a
famous play, or a famous religious scene such as the nativity.
Thus, children can be provided with an educational experience while
having fun.
[0256] Other examples of grouped actions would be used in an
educational environment. For example, a group of dolls would be
taught in any subject, whereby one doll is the teacher and asks
questions which would be answered by all of the other dolls
simultaneously, thus promoting learning for the child.
Conversation Construction
[0257] The conversation engine constructs the conversation on the
fly. Alternatively, before initiating the conversation the entire
conversation is constructed and then stored in memory and
effectively the conversation is then run through until the end.
However, in both cases the conversation constructed will be based
on certain random choices.
[0258] The conversation is based on the units present in the
network, and therefore the number of units present, and the type of
units present, are used as control variables. The start of each
conversation is fixed, such as for when the toys are dolls "Wow,
we're at the Zoo what shall we do now?". But there are multiple
starting phrases. The conversation will then be randomly chosen
from that point on. The controller unit selects the first unit to
speak and then branches at random to any of the starting
phrases.
[0259] The system is enabled to use an instruction set comprising a
number of different types of commands as follows: [0260] Definition
of variables and variable setting [0261] Context reference and
switching [0262] Conditional flow control [0263] Unconditional flow
control [0264] Uttering phrases
[0265] A number of statements are defined to control the flow of
the conversation and are as follows: [0266] SELECT NEXT--selects
the next unit to speak. There are a number of variations of this
statement that will be discussed in further detail below. [0267]
SWITCH--switches to next unit. [0268] switch speaker--moves the
speaker pointers to another speaker [0269] switch finish--this
statement is used to finish the conversation [0270] SAY--instructs
the unit to say something. [0271] SET--this statement is used to
set a variable, such as "SET pet ([1,dog])". The SET statement is
used to set a variable of the current speaker, or it can be used to
set a global variable. [0272] TEST--this statement is used to test
whether a variable has been set, or if a branch has been used for
example. If the TEST is true a flag is set. There are two forms of
the TEST statement: [0273] TEST EQ--this statement tests whether
the two expressions are equal and will produce a positive flag if
they are; for example, "TEST EQ &ME.PET &UNDEF" will test
whether the current speaker's pet variable is undefined and will
produce a positive flag if it is. [0274] TEST NE--this statement
tests whether the two expressions are not equal, and will produce a
positive flag if they are not equal. [0275] BRANCH--this statement
is used to branch off into another section of the conversation. For
example, "BRANCH Gorillas:" would branch off into the Gorillas
section of the "Zoo" theme; where "Gorillas:" is a label to a
section of the theme. This is an unconditional statement and is
always used when the program reaches a branch statement. [0276]
BRANCH_F--conditionally branches on a flag from TEST. Therefore,
only when the flag produced from the TEST statement is positive
will the branch statement be used. [0277] CHOOSE--this statement
enables the controller to randomly select a label to proceed to.
This statement is similar to the SET statement in that weights can
be used to control the probability of proceeding to a label. [0278]
CHOOSE_F--conditionally chooses based on a flag from TEST
[0279] The audio files are stored in a cropped form to reduce the
storage requirements, i.e. there is no silence before or after each
audio segment. To produce more realistic speech a number of silent
audio files are provided of differing length that can be placed
after the cropped audio files, between each phrase or word. These
audio foes are referenced in the same way as any of the other audio
files by the SAY statement.
[0280] Variables can be defined, by the SET statement, to store
parameters associated with each of the dolls; this is discussed in
further detail below. There are two types of variables that can be
defined: [0281] Local variables--These are variables that are
associated with each Toy/Doll. The local variables are created
within each Doll's data set. Doll variables are created by the
DEFINE VARIABLE_NAME statement. [0282] Global variables These are
variables that are associated with the "theme" and not with each
Doll. Global variables are created by the DEFINE G_VARIABLE_NAME
statement,
[0283] The variables defined within the theme do not have a value
assigned to them until a value is assigned during the
conversation.
Setting Values to Variables
[0284] During the conversation it is necessary to set values to the
variables that have been defined. This is accomplished with the SET
statement. The SET statement consists of a random feature that
allows the variable to be set with a value taken at random from a
set of values as follows: [0285] SET VARIABLE_NAME
([w1,value1],[w2,value2], . . . , [wn,valuen])
[0286] The operation of this statement is to set the value of
VARIABLE_NAME to one of value1, value2, . . . , valuen based on the
outcome of a random number. The probability of which value is
chosen is based on the weights w1, w2, . . . , wn.
[0287] For example the statement [0288] SET COLOUR
([1,red],[1,blue],[1,green])
[0289] Will set the variable COLOUR to red, blue or green with
equal probability. Doll variables are set in the context of the
current Doll.
[0290] Additionally the SET_F statement is used to set a variable
only when a TEST statement has produced a condition_flag situation.
In this case if and only if the condition_flag is active the
variable is set.
Context Reference and Switching
[0291] Pointers are used to store information relating to the
speakers, and to enable the controller doll to reference other
dolls. When constructing conversations these are used to create
sensible conversations; the following are the pointers used: [0292]
Previous speaker (PREV)=the ID number of the previous speaker
[0293] current speaker (ME)=the ID number of the current toy [0294]
next speaker (NEXT)=the ID number of the chosen next speaker
[0295] An important feature of the Doll's conversation engine is
the context of which Doll is the current speaker. The context
refers to the variables that the current doll has access to. Only
the previous, next and current doll's variables are available for
access. The concept of context is handled by three reference
pointers, as defined above.
[0296] Control of context is achieved by use of the SELECT commands
and the SWITCH command. There are a number of variations of the
SELECT command. These are: [0297] SELECT NOTME--This selects the
next speaker to be any of the group of Dolls chosen at random
except the current Doll. [0298] SELECT NEXT--This selects the next
speaker to be any of the group of Dolls chosen at random. [0299]
SELECT PREV--This selects the next speaker to be the same as the
previous speaker. [0300] SELECT NAME--This selects the Doll with
the name NAME to be the next speaker. This variation of the SELECT
command is for fully scripted conversations.
[0301] The context is then changed by use of the SWITCH command.
There are two variations of the SWITCH command: [0302] SWITCH
SPEAKER label--This switches the speaker context and branches to
the instruction specified by the label. On switching context the
previous speaker (PREV) becomes equal to the current speaker (ME),
the current speaker (ME) becomes equal to the next speaker (NEXT),
and the next speaker (NEXT) is undefined. [0303] SWITCH
FINISH--This is the command used to end a conversation
Conditional Flow Control
[0304] At times during the conversation the flow will depend on the
values of various variables. This is accomplished with the
following commands: [0305] TEST EQ value1 value2--This sets a
condition_flag if value1 equals value2. [0306] TEST NE value1
value2--This sets a condition_flag if value1 is not equal to
value2. [0307] Variables can be referenced by value1 and/or value2
by using the &CONTEXT.VARIABLE_NAME reference. For example the
instruction TEST EQ &ME.NAME &PREV.NAME sets the
condition_flag if the current speaker's (ME) name is the same as
the previous speaker's (PREV) name. [0308] BRANCH_F label--This
branches to the instruction specified by the label if the
condition_flag is set, otherwise the next instruction is used,
[0309] CHOOSE_F ([w1,label1],[w2,label2], . . . , [wn,labeln])--If
the condition_flag is set this branches to the instruction
specified by one of label1, label2, . . . , labeln based on a
random selection using the weights w1, w2, . . . , wn, otherwise
the next instruction is used.
[0310] Each time that a doll requires knowledge of a variable
relating to another doll the TEST statement is used to interrogate
whether the variable is undefined, or is a specific value. This can
then be used for flow control; for example, if the variable PET is
undefined then the doll will ask the other doll what type of pet is
has, and if the variable is set it will ask the other doll what
colour the pet is, and so on.
Unconditional Flow Control
[0311] At times it is necessary to be able to change the flow of
instructions unconditionally. In this case a TEST statement is not
used and the BRANCH or CHOOSE statements are always executed. This
is accomplished using the following statements: [0312] BRANCH
label--This unconditionally branches to the instruction specified
by the label. [0313] CHOOSE ([w1,label1],[w2,label2], . . . ,
[wn,labeln])--This branches to the instruction specified by one of
label1, label2, . . . , labeln based on a random selection using
the weights w1, w2, . . . , wn.
Uttering Phrases
[0314] An important part of the conversation engine is the uttering
of phrases. This is accomplished with the following statement
[0315] SAY (phrase1, phrasen) command. [0316] This command causes
the Doll that is the current speaker (ME) to utter the phrases
phrase1, phrase2, . . . , phrasen.
Example Script
[0317] The following is a short example of a script. [0318] DEFINE
COLOUR [0319] DEFINE GARMENT [0320] Loop: [0321] SET COLOUR
([1,red],[1,blue],[1,green]) [0322] SET GARMENT
([1,dress],[1,blouse],[1,hat]) [0323] SAY (hello my name is,
&ME.NAME, and I have a, &ME.COLOUR, &ME.GARMENT) [0324]
SELECT NOTME [0325] SWITCH SPEAKER Loop
[0326] This example can say nine different things for each Doll
present by choosing one of three colours to go with one of three
garments.
[0327] The conversation is constructed using multiple branches.
Each branch is a different area of conversation related to the
theme. For example, in the "Zoo" theme the branches available are
"Gorillas", "Reptiles" and "Ice cream". Each branch has
phrases/words associated with it and they are then chosen randomly
from the selection. The doll's responses are dependent on the
branch, the doll's personality type, and the weightings of the
possible responses.
[0328] For example, when a choice is required to determine the next
branch to take the conversation will continue until two (or more)
dolls choose the same place to go in a row. This provides a more
realistic conversation as the agreement is required before choosing
a branch to take.
[0329] The conversation continues within a branch until a section
is reached that enables the controller doll to select another
branch to take. At this point another decision is made regarding
the branch to take. To limit the length of the conversation only
branches that have not been used are available to be selected.
[0330] Weightings are attached to each variable that can be chosen
randomly, such as Branch, Phrase, Word, or Next speaker. When the
phrase/word or branch etc is chosen randomly the weightings alter
the probability that that phrase/word branch, etc, is chosen. For
example, if all of the phrases had a weighting of I then they would
all have the same probability of being chosen. The weightings can
be adjusted to produce conversations that are more life like.
Phrases such as "I fell off my bike today" are far less likely to
arise than phrases such as "I had breakfast this morning". As a
result the latter phrase would have a far greater weighting than
the former. Therefore, only occasionally the conversation engine
would result in a unit saying "I fell off my bike this
morning".
[0331] In a further example, the weightings used can be
preferential to the previous doll and will therefore induce mini
conversations between two dolls.
[0332] In order to limit the conversation length the amount of time
within any one branch of the theme is controlled. This can be used
as another weighting parameter to reduce the time spent in one
branch and increase the amount of time spent in another branch for
example. This aids in reaching an end to the conversation without
the possibility of the continuing indefinitely.
[0333] The length of the conversation may be random; however, in
some cases the conversation will continue until all of the
variables have been set. For example, in the PET theme the
conversation will continue until all of the dolls' pets have been
fully described. This is accomplished by performing a check to
determine whether all of the variables are defined, and only
allowing the conversation to end if they are all defined.
[0334] As the current speaker only has the context of the previous
speaker and the next speaker it is not always possible to determine
when all of the dolls' variables have been set. Therefore, in
another example the conversation will continue until all of the
variables have been set for all three dolls in the current context,
i.e. the current doll, the previous doll and the next doll.
Alternatively, the conversation will continue until all of the
variables are known for two, or more, sets of dolls in a row.
[0335] The conversation engine can cope with multiple dolls, and
potentially multiple dolls of the same type, e.g. 2 Jane dolls.
When the network is initialised each doll that joins the network is
associated with a network node. The system then references the
dolls using the associated network node, and not the name of the
doll. This enables multiple dolls with the same name to be
referenced without error.
[0336] Conversations can also be pre-determined in their entirety
and then downloaded directly to the dolls. For example, an episode
of The Simpsons.TM. could be downloaded into a group of The
Simpsons.TM. dolls. Pre-determined conversations enable the doll to
have especially lifelike conversations, since they are generated by
humans, or alternatively they could be generated by a conversation
engine and then edited by humans. The same instructions are used
when producing a pre-determined conversation; however, the random
elements are removed such that the conversation is the same every
time it is activated.
[0337] The above conversation engine could be used independently to
generate conversations. For example, it could be used for automated
script writing for a television show, such as a cartoon.
[0338] In one particular embodiment, to generate the themes the
theme is scripted, and then a compiler is used to compile the
script. A run-time error check is performed to ensure that the
theme does not produce never ending conversations or any other
errors, and then a sanity check is performed to ensure that the
conversations are not completely nonsensical. The theme is then
able to be downloaded to the toy once the audio files have been
recorded. In an alternative embodiment, described in further detail
below, there is provided an authoring tool to simplify the
generation of theme scripts. However, the basic principles of the
conversations within the themes still apply. For example, the same
methods of choosing what to say are present in both
embodiments.
Doll Choice
[0339] As shown in FIG. 3, the conversation engine has a speaker
selector 218. The speaker selector selects the next toy to speak.
There are three possibilities for choosing the next toy to speak:
choose at random any of the toys within the network; choose a toy
by name (ID number); and choose the current speaker to speak again.
Therefore, the first process in choosing the next speaker is to
select, at random, which one of the above three possibilities to
use. When choosing the next speaker by name, a check must be
performed to determine that the toy is in the network.
[0340] As described above the select statement chooses who will
speak next. When deciding on the next speaker the options are to
respond with relevant speech, select another doll and address them,
or announce something about the current speaker.
[0341] The SELECT statement is used within the speaker selector 218
to initiate the random selection of the next speaker.
Alternatively, the SELECT statement can use logic to determine the
reference to the next speaker. For example, if the next doll chosen
to speak is Jane, then the current speaker can ask the following
question "Jane, what is your favourite pet?". Jane is set as the
next speaker and so the reply will come from Jane. As can be seen
in the examples below the & statement can be used to reference
the next speaker, or any other general parameter without knowing
the specific parameter. For example, &NEXT.NAME references the
next speakers variable NAME, and can be used to say the next
speakers name.
[0342] Further options are available such as no doll can speak
twice in a row, so for example if Jane announces that she has a pet
dog, then Jane would not be selected to speak again directly
afterwards.
[0343] Similar methods are utilised by the authoring tool to choose
the next doll to speak, this will be described in further detail
below.
Parameter Storage
[0344] The parameter storage memory 216 stores information relating
to the current conversation. The information stored includes: the
phrases that have already been used; the variables that have been
used; flow control variables; and other such information like the
dolls that are in the network. The information is only stored
within the controller doll. The slave unit only receives
information relating to the next thing to say.
[0345] The variables that have been used in the conversation are
stored so that they may be referred to later in the conversation.
Variables are pieces of information describing the doll, and are
used to differentiate the characters. For example, the information
stored from the phrase "My dog is called Fluffy" would be the
information, dog and fluffy. This variable can be used to set the
type of pet that a doll has. The variables can be set so that dolls
can only have a certain sub-set of the variable. For example, girl
dolls can not have a snake as a pet.
[0346] Flow control variables are used to store information
regarding the branches that have already been used. For example, a
branch may be going to see the Gorillas when at the Zoo. This piece
of information will be stored so that the conversation does not
return to the Zoo.
[0347] Alternatively, the phrases that have already been used are
stored so that the conversation does not go on forever. Limits can
be set on the number of times a particular word/phrase can be used
within a single conversation; this limit may be 1, 2, 3 or more.
This ensures that the conversation does not become too
repetitive.
[0348] There are also global variables that can be set and are
stored within the parameter storage memory. An example of a global
variable would be anything that affects all of the dolls within the
network, for example "it's raining outside", or the places that the
doll's have been within the conversation. A global variable can be
accessed independently of the context of the doll, and so can be
used at any point in the theme.
[0349] Parameters are also defined using the authoring tool to
store attributes relating to the theme/doll, this will be described
in further detail below. In brief, theme attributes/global
variables store parameters associated with the entire theme and can
be accessed by any doll at any time, and doll attributes/local
variables store parameters associated with each doll and are only
accessible by the previous/current/next doll.
Doll Specific Downloads
[0350] FIG. 4 shows a schematic illustration of the process through
which a doll can change, or update, the theme that it has stored in
memory. The doll 300 contains an ID number 302 which is used to
identify the doll. The doll is connected to a PC 304 via a USB
connection, and the PC is in turn connected to the Internet 306 via
a standard connection type. The Internet provides the PC with a
connection to the Website 308 that contains downloadable themes
310. The themes contain sub-themes 312 that are not selectable by
the user as they are dependent on the doll connected. For example,
a Jack doll--identified using the doll's ID number--would not be
presented with a Jill sub-theme. The themes are generic to all of
the personality types. The sub-themes are identical to the main
theme, except that the expression of the theme is different and
dependent on the personality type of the doll. The audio files are
therefore different for each sub-theme--different voice, different
wording (same meaning), etc.
[0351] Alternatively, the first personality downloaded into the
doll can be used to restrict the subsequent downloaded
personalities to be the same as the first type. For example, if the
doll is set up to be Jack, the website will recognise the Jack
sub-theme when the doll is connected, and only present the user
with Jack sub-themes. The website recognises the sub-theme by
accessing the doll's name variable, i.e. Jack, and comparing it to
the list of names of sub-themes.
[0352] The downloaded sub-theme includes the script for the theme
chosen, such as "The Zoo", the associated personality type, the
corresponding audio files that enable the doll to vocalise the
conversation, and a theme ID which is used to ensure all of the
dolls within a network have the same theme.
[0353] The PC 304 is adapted to interface between the doll 300 and
the website 310 to enable the theme to be downloaded in an
efficient manner. Furthermore the theme is only stored on the doll
and therefore each doll that requires the theme must be connected
to the website. Therefore, if one user has two dolls and requires
the same theme for each doll the user must connect to the website
with each doll, and download the appropriate sub-theme.
[0354] Alternatively, the doll can store multiple themes at any one
time. The doll communicates using one theme at a time; however, the
themes could be changed--by the controller--at any time. Therefore,
the dolls could use the "Sport" theme and then progress onto using
the "Zoo" theme. This enables the conversation to continue for
longer and provides further combinations to extend the usability of
the dolls.
[0355] The dolls all have a default theme so that they may
communicate briefly when they do not have the same theme as other
dells. The default theme contains a few basic phrases, and may
direct the user to connect to the website to download a theme.
[0356] To ensure the themes are secure the data can be encrypted,
using the don unique ID number before being downloaded to the doll.
Each doll's unique ID number can then be used to decrypt the data
within a theme. This can be used to ensure that every doll connects
to the website to download the theme. For example, even though each
Jane doll would use the same sub-theme the data would be encoded
differently for each specific doll, and is therefore effectively
useless other then for that specific doll.
Expression of Personality and Scripting Themes
[0357] As mentioned previously, each different theme has various
sub-themes that enable different personalities to be expressed. The
script for every theme is different and is used to generate
conversations according to that theme. However, each sub-theme
within every theme has the same script to generate the
conversations, but the language used in the sub-theme is different.
This enables multiple personalities to be available for the same
theme.
[0358] To increase the variability of the conversations there are
multiple random chokes available to ask the same questions. So for
example there are multiple ways of asking a simple question, and
this may be dependent of the themes/sub-themes for example: "What
shall we do next?"; "What are we going to do now?"; or "What's
next?". Each sub-theme can have different expressions that are used
to mean the same thing. For example, one sub-theme may say "Hello,
how are you?", and another says "Hi, how's it going?". The meaning
of the phrase is effectively the same but the expression, and
therefore the personality, is different. In this way each theme can
have any number of sub-themes to create a colourful and interesting
conversation. In this way the user experience is enhanced and
allows for a more varied game play without the requirement for
large amounts of memory.
[0359] Personality traits can be attributed to one and the same
theme. It is therefore possible to have a Jack version and a Jill
version of the same theme. The Jack version is a sub-theme, and the
Jill version is a sub-theme.
[0360] The name of the doll, i.e. Jane, is linked to the
personality type so the personality expressed by the Jane doll will
be the same for every theme; only the content of the theme would
change. This enables the doll to remain consistent and allow the
doll to react in similar ways in different situations.
[0361] Alternatively, the user of the doll can select the doll's
name and the dolls personality when the doll is first initialised
by the website. This enables the user to be more involved with the
doll. The doll's name and personality type would then be stored in
memory within the doll, each attribute associated with an ID, and
used when downloading further sub-themes for example.
[0362] The downloadable themes are a combination of the expression
and the script and dictate the type of conversation.
[0363] The aesthetics and vocabulary of the dolls can also be
tailored so that it is age appropriate for a target audience.
Various themes may have an age appropriate rating. This allows hip
hop themed dolls, for example, for a teenage market.
[0364] Furthermore, phrases can be provided that are only allowed
to be used by a discrete set of dolls (this may be a single doll).
When this phrase is selected a check is performed to ensure that it
can be used by the current doll. If it can not be used by that doll
then another phrase is selected.
[0365] Similarly, sections of the instructions can be restricted to
only a discrete set of the dolls to introduce further randomness
into the conversations.
[0366] Alternatively, the toy is in the form of a tank, or other
such toy. The expression of the toy's personality in this case is
in the form of movements as opposed to speech. For example, one toy
tank could have a "defensive" personality and another toy tank
could have an "aggressive" personality.
Authoring Tool
[0367] The authoring tool is an application which can be used to
create conversation themes for multiple dolls. The conversations as
described above require a significant amount of time to create due
to the large number of potential branches that the conversation can
follow. Therefore, in order to make the process more efficient an
authoring tool is provided to aid in this process. Although the
client application runs on a personal computer or the like, such as
PC 1000 or laptop 1002 as shown in FIG. 10, the data is stored on a
server 1004 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 to
interface the database with the client application. The client
application communicates with the server 1004 via the internet 306.
The client application formats requests to the web service, and
hence the database, using XML, and transmits the data using the
SOAP protocol.
Overview of the Authoring Tool
[0368] FIG. 11 shows an overview of the authoring tool. A user
interface 1100 is provided to allow theme developers to simply and
efficiently output themes for toys. Using the user interface
provided the developer follows the following steps: [0369] 1.
Create a theme using a theme generation engine, 1102 [0370] 2.
Create toys for that theme using a toy generation engine, 1104
[0371] 3. Create multiple contexts for each toy, using a context
input window 1106 [0372] 4. Output the instructions ("C" code),
using the code generation engine 1108 [0373] 5. Output the
"dictionary" of phrases to be recorded for each doll, using the
dictionary generation engine 1110 [0374] 6. Output, when required,
the theme as a simulation using simulation engine 1111 for use in
testing the themes on a PC
[0375] The term context, as used herein, connotes a sub-set of
content within the theme data, e.g. for each position within the
themed conversation there is at least one context that determines
what the doll says and which doll will speak next. A context can
also set theme/doll attributes.
[0376] Once the instructions and "dictionary" have been output
using the code generation engine and dictionary generation engine
1110 respectively, the phrases are recorded using recording means
and audio files are created and saved using the recorder 1112. The
recorder prompts an actor to generate each of the expression data
required for the particular theme being created. The recorder then
allocates each audio file with the ID number corresponding to the
appropriate expression data. In use, the audio files are referenced
using the appropriate ID number by the code operated by the toy's
processor and output using the toy's speaker.
[0377] A set of base instructions 1114 (the firmware for the toy's
processor) are combined with a set of themed instructions
(generated by the code generation engine 1108) and compiled using a
compiler 1116 into binary files that are used by the toy's
processor to operate the toy according to the theme. In the
previous embodiment, described above, the base set of
instructions/firmware was located in the toy's processor memory,
and only the set of themed instructions, and the audio files, were
downloaded to the doll each time the theme was changed or
updated.
[0378] Once the instructions are compiled they are bundled together
with the audio files using the combiner engine 1120 so that they
can be downloaded to each doll (each doll has an individual
download, comprising the same themed instructions, but with
personalised audio files).
[0379] The authoring tool has access to the server 1004 and a
database 1122, where the themes are stored. The themes are stored
in different formats depending on whether they have been finalised
by a theme developer. The non-finalised themes are stored such that
the information is readily accessible by the authoring tool; this
is in the form of a database containing references to the theme
name, toy name, contexts, etc. Once the theme developer finalises
the theme the theme is also stored as a set of instructions as
described above, in addition to the non-finalised format. This
enables a finalised theme to be amended, and a new theme created
based on a previously finalised theme. A website 1124 is provided
that enables the users of the toys to download the themed data to
his/her toy/doll 1126.
[0380] The authoring tool has several functions including those as
described above; [0381] 1) it can be used to import a conversation
from a pre-formatted text file, [0382] 2) It can be used to create
and to edit themed conversations for multiple dolls, using the
theme generation engine 1102. [0383] 3) It can be used to simulate
the conversation process, producing a text output of the resultant
themed conversation, using the simulation engine 1111. [0384] 4) it
can be used to assemble a list of all the phrases to be recorded
for each doll, using the [0385] dictionary generation engine 1110.
[0386] 5) it can be used to produce "C" code output (sets of
instructions), using the code generation [0387] engine 1108, which
can then be compiled and linked with the modified processor
firmware to [0388] produce a binary data file for each doll ready
for download.
Entering Conversation Data
[0389] The authoring tool application user interface is shown in
FIGS. 12A to 15. Each window of the interface has numerous
navigation buttons to either interface with input windows, or to
proceed to the next interface window. The user interface utilises
the processor 1150, and associated memory 1152 to display to the
theme developer the various aspects of the user interface, and the
receiver 1153 to receive the content input by the user. The
processor 1150 and memory 1152 are situated within the PC 1000 or
laptop 1002. The term content, as used herein, connotes scripting
data, expression data, theme data, doll data, and any other data
type that may be input by the user into the authoring tool.
[0390] FIG. 12A is the first interface window, and has the
following options: [0391] Add Theme, 1100: This is used to create a
new theme and is normally the first option used. It brings up a
theme form, as shown in FIGS. 126 & 12C, which requires the
following inputs: [0392] Name: The name of the theme. This is a
place holder for a spoken_text_string [0393] Number of Dolls: The
total number of dolls supported in this theme [0394] Description:
The description of the theme [0395] Theme attributes: The global
attributes of the theme, such as the location [0396] Dolls
attributes: The local attributes of the dolls such as a mood
[0397] These inputs are equivalent to the inputs required in the
construction of conversations as described above. The theme and
doll attributes, as described with reference to the authoring tool
embodiment, are equivalent to the global and local variables
respectively, as described above. However, the authoring tool
provides the theme developer with structured input windows to
enable the information to be input more efficiently.
[0398] In further detail, theme attributes consist of a name and
optionally a value. The value can be a placeholder for
spoken_text_string. The spoker_text_string is created after the
theme has been finalised, as described below. A spoken_text_string,
is a sound file that can be accessed during the conversation. For
example, if the theme was located in the Zoo, a possible theme
attribute would be location="Zoo", and can be used by the dolls;
e.g. to say "Hi, I'm really having fun at the Zoo", where the word
"Zoo" was accessed using the theme attribute "location".
[0399] The doll attributes are created in the interface window as
each doll in a particular theme require a value for an attribute.
For example, if the attribute set is "mood", then each doll will be
attributed a value for this attribute, such as "happy", "sad",
"angry", etc. During the conversation the conversation engine can
access any of the doll attributes (local variables) and use it in
the conversation [0400] Edit, 1202: This is used to edit an
existing theme. For example, selecting the theme Alon#1, 1206, and
pressing edit will allow the user to edit the details of the Alon#1
theme. [0401] Remove, 1204: This is used to delete the selected
theme.
[0402] FIG. 12A shows the window after three themes 1208, 1208 and
1210 have been created. It can be seen that each theme shows the
overview of the theme's details, including a brief description of
the theme, the number of dolls involved in the theme, and its ID
number. The information input into the theme form is stored in the
database 1122 in the server 1004 for later retrieval when
generating the output instructions.
[0403] Once the theme has been created, the user moves on to the
next window to create the dolls within the theme. FIG. 13A shows
the doll generation window, and when the user presses the "add
doll" button 1300, the window shown in FIG. 138 is displayed. This
window allows a doll to be created named, and given a brief
description.
[0404] As many dolls as required can be created using the windows
shown in FIGS. 13A & B. However, the number of dolls that can
be created is limited by the previously determined maximum number
of dolls for that particular theme. Using these same windows it is
also possible to edit existing dolls. Each doll created in this way
will lead to a sub-theme being generated. The sub-theme, as
described above, is the theme for each specific doll. For example,
the voice used to record the speech is different for each toy, and
the context data will be different. Again, the information input
into the doll form is stored in the database 1122 in the server
1004 for later retrieval when generating the output
instructions.
[0405] FIG. 14 shows the context definition window where the
different contexts are input against each doll in the theme. As
shown in FIG. 14, at Position 100 there are two contexts defined,
1400 and 1402, one for Doll#1 and one for Doll#2. Therefore, when
Position 100 is accessed within the conversation, a doll is chosen
by a method as described above, and the corresponding context is
accessed. Each context holds information relating to what the doll
should say, and which doll should speak next. This simplifies the
process of conversation construction as described above, by
providing the theme developer with a structure for creating the
conversation. The theme developer is no longer required to code the
theme themselves, rather the authoring tool generates the required
code in dependence on the theme developers input.
[0406] FIG. 15 shows the context generation window for each
position within the theme. In the example shown in FIG. 15, this is
the context for position 100 and Doll#1. Each context requires the
following information: [0407] Position, 1500--A text string
labelling this position which is created automatically by the
authoring tool when a new context is created in the context
definition window shown in FIG. 14. This is a convenient label for
each context row. It can be any text; however, the default is to
sequentially number the context rows starting at 100. The use of
text labels is to aid clarity while creating and editing the
conversation. When output of "C" code is required all Position
labels are converted to indexes into an array of
youme_conversation_struct_t structures (C code naming convention
utilised for this and the other structures described herein) which
correspond to the context positions, [0408] Statement, 1502--A list
of statements that the doll can say together with weightings used
in the random selection process. The statements contain a list of
phrases which are spoken_text_strings. This is a list of statements
that can be said by the particular doll at this context point in
the conversation. Each statement is enclosed in square brackets and
each statement can either be separated by a comma (e.g.
[statement1],[statement2],[statement3]), or entered on a separate
line of the context input window as shown in FIG. 15. Statements
consist of a weighting, for random selection, and a list of
phrases. The weighting in this case operates in a similar manner to
the weightings as described above with reference to the conditional
flow control, such as the SET, BRANCH or CHOOSE controls. Each
phrase is either an explicit spoken_text_string or a reference to a
theme attribute or a doll attribute, e.g. the statement can
reference to the location of the theme or the mood of the doll.
Explicit spoken_text_strings are defined as text within double
quotes (e.g. "hello how are you"). References take the following
forms: [0409] theme.attribute for a theme/global attribute [0410]
me.attribute for the current speaker doll attribute [0411]
prev.attribute for the previous speaker doll attribute [0412]
next.attribute for the next speaker doll attribute [0413]
name.attribute for the named doll/local attribute
[0414] The following are examples of valid input to the Statements
field; [0415] Blank--This means there is nothing to say by this
doll at this point. [0416] [1,"hello how are you"]--Only one
statement specified "hello how are you" will be spoken by this doll
at this point. [0417] [1,"hello",prev.name,"how are you"]--Only one
statement "hello" followed by the previous speakers name followed
by "how are you" will be spoken by this doll at this point. [0418]
[1,"hello"],[1,"hi"]--Two statements with equal weighting. If the
default_say_procedure is used then "hello" will be said 50% of the
time by this doll at this point and "hi" will be said the other 50%
of the time. [0419] [3,"hello"],[1,"howdy"]--Two statements with
unequal weighting. If the default_say_procedure is used then
"hello" will be said 75% of the time by this doll at this point and
"howdy" will be said the other 25% of the time. [0420] Say,
1504--The procedure used to say the statements. If left blank then
the default _say_procedure is used. The default_say_procedure
randomly selects one of the available statements using the weights.
Alternatively, any available built in say procedures providing
different behaviour can be selected using the drop down list. The
say procedures as described above can be provided in the drop down
list. Finally, if custom behaviour is required "C" code of the
required say procedure can be entered here. [0421] Transition,
1506--The procedure used to select the next doll. It can be any of
the procedures described above including: NOTME, ANY, ME, PREV,
FINISH or one of the dolls names or some "C" code can be entered
here. If left blank the default_transition_procedure is used, which
is the NOTME transition. Alternatively, there is a pull down list
of available transition procedures. This list consists of the
following built in transitions, and is accessed in the authoring
tool via a drop down menu (each as described in detail above):
[0422] NOTME Selects any doll except the current speaker at random.
[0423] ANY Selects any doll at random, [0424] ME Selects the
current speaker [0425] PREV Selects the previous speaker [0426]
Doll's name Selects that doll
[0427] Additionally, if a custom transition behaviour is required
"C" code of the required transition procedure can be entered here.
[0428] Next, 1508--A list of branch choices of where to go next
together with weightings used in the random selection process. This
is a list of branch choices for the next context position. Each
branch choice is enclosed in square brackets and delimited by
commas. Branch choices themselves consist of a list of position
labels together with weightings for random selection. They are
similar in format to the BRANCH command as described above. The
following are examples of valid input to this field (each as
described in detail above): [0429] [(1,label1),(1,label2)]--One
branch choice containing a choice of two labels with equal weights.
[0430] [(1,label1),(1,label2)],[(2,label3),(3,label4)]--Two branch
choices, the first containing a choice of two labels with equal
weights, the second containing a choice of two labels with weights
2 and 3. [0431] Branch, 1510--The procedure used to effect the
branch, and the format is the same as described above with
reference to conversation construction. Otherwise some "C" code can
be entered here. This field is used to specify the branch procedure
to process the branch chokes. If left blank then the
default_branch_procedure is used. The default_branch_procedure uses
the first branch choke in the Next list and chooses one of the
labels at random using the provided weightings. The context is then
changed to the context row with the chosen label as its position
label. Alternatively, there is a pull down list of available built
in branch procedures. The branch procedures as described above can
be provided in this drop down list. [0432] Attributes, 1512--A list
of attributes, a set_flag, and list of values and weightings for
random selection. This field is used to specify any attributes to
set with values at this context point, i.e. the theme developer can
set the doll attribute "mood" to happy. If left blank then no
attributes are set. Each attribute to be set is enclosed in square
brackets and delimited by commas. Within the square brackets the
attribute is specified followed by a set_flag which specifies if
the attribute is to be set once or can be reset, followed by a list
of values and weightings for random selection. The attributes field
is the equivalent of the SET command as described above. The
following are valid input to the Attributes field; [0433] Blank No
attributes to set [0434] [me,attribute1,set,(1,"hello")] One
attribute to be set, if not already set, to the value of
spoken_text_string "hello" [0435]
[me.attribute1,reset,(1,"hello"),(1,"hi")],
[me.attribute2,set,(1,"peter"),(1,"paul")] Two attributes to be
set. The first to be set, even if already set, to either "hello" or
"hi". The second to be set, if not already set, to either "peter"
or "paul". [0436] Set, 1514--The procedure used to effect the
setting of attribute values. If left blank then the
default_set_procedure is used. The default_set_procedure sets each
specified attribute to the appropriate choke of values taking
account of the set_flag. A set_flag of "set" means that the
attribute can only be set if it has not already been set. A
set_flag of "reset" means the attribute can be reset over and over
again. Alternatively, there is a pull down list of available built
in set procedures. Finally, if some special custom set behaviour is
required "C" code of the required set procedure can be entered
here.
[0437] As described above, the fields, Statements, Say, Transition,
Next, Branch, Attributes, and Set are replicated for each doll. The
fields Say, Transition, Next and Branch are all parameters that
contribute to the method of interaction between the toys/dolls, and
are all equivalent to commands as described above with reference to
conversation construction.
[0438] FIG. 15B shows an alternative embodiment of the context
generation window. As area 1550 shows, there are additional
parameters that can be set to enable the user to determine when the
next doll will speak. The three options are follow on; timed from
start; and timed from end. The follow on parameter allows for
conversations to continue with the dolls speaking in series, i.e.
one after the other with no overlap. The timed from start parameter
enables the user to enter a time interval after the doll starts
speaking to trigger the next doll to speak. This allows two dolls
to speak at the same time, for example, multiple dolls can laugh at
the same time in response to a joke. The timed from end parameter
is similar to the timed from start parameter except that the user
enters a time interval for the next doll to start speaking before
the end of the current doll's speech. This feature enables more
life-like conversations to be constructed.
[0439] The Context option is used repeatedly to add context rows to
the conversation until the conversation is complete.
[0440] When the theme has been completed, including defining each
doll, and each context, the authoring tool provides a save
function. This option is used to save the conversation, and in one
example it creates the following directories: [0441]
c:\youme\themes\theme_name [0442]
c:\youme\themes\theme_name\doll_name--for each doll [0443]
c:\youme\themes\theme_name\doll_name\audio--for each doll
[0444] Therefore, all of the files required for a single theme are
saved within the master directory folder "theme_name". Sub-folders
are created for each doll to enable the downloads for each doll to
be managed efficiently. Finally, each doll sub-folder has a folder
to store the audio files required for that doll,
[0445] It also creates the following files: [0446]
c:\youme\themes\theme_name\theme.txt--containing the theme data as
a text file [0447]
c:\youme\themes\theme_name\doll_name\doll.txt--containing the doll
data as a text file. [0448]
c:\youme\themes\theme_name\doll_name\audio\A00001.wav [0449]
c:\youme\themes\theme_name\doll_name\audio\A00002.wav [0450] . . .
[0451] . . . [0452] . . . [0453]
c:\youme\themes\theme_name\doll_name\audio\A00010.wav [0454] . . .
[0455] . . . [0456]
c:\youme\themes\theme_name\doll_name\audio\Annnnn.way
[0457] The way files created are place holders for each of the
spoken_text_strings defined in the theme for each doll. The
spoken_text_strings are assigned file names A0000n.wav in sequence
starting from A00001.wav. The n used in the file name is also used
as the index to the phrase when output of "C" code is required. The
recorder, 1112, in one embodiment, provides a prompt for the actor
to enact the required spoken_text_string, and then automatically
saves the file with the correct file name before prompting the
actor with the next spoken_text_string.
[0458] In addition, the authoring tool is adapted to generate "C"
code corresponding to the conversation. The majority of the "C"
code is predefined (a base set of instructions), and acts as the
operating system for the toys/dolls processor. Once the "C" code
corresponding to the conversation is output (the themed set of
instructions) it is combined with the predefined "C" code, see FIG.
11, and then compiled to create the binary file suitable to operate
the processor in the doll, or in the PC. Incorporating the
operating system/firmware into the doll each time a new theme is
created allows the functionality of the doll to be altered simply
and efficiently whenever required.
[0459] Two varieties of "C" code can be output: [0460] 1. "C" code
for windows--This "C" code can be saved as: [0461]
c:\youme\themes\theme_name\theme_simulation.c; and [0462]
c:\youme\themes\theme_name\theme_simulation.h
[0463] This code can be subsequently compiled and linked with a
windows based conversation simulation engine The resulting
application can be saved as
c:\youme\themes\theme_name\simulation.exe. The simulator allows the
user to specify which dolls should be considered as present and
active. It then simulates an instance of the conversation as it
would happen in real dolls. It selects one of the active dolls at
random to be the current speaker and processes the first context
row for that doll. It then executes each new row in turn outputting
which doll is speaking and what they are saying. It continues until
the conversation finishes. [0464] 2. "C" code for the processor
this code can be subsequently compiled and linked with the modified
player to produce binary data files for each doll. These "C" code
files can be saved, for each doll, as: [0465]
c:\youme\themes\theme_name\doll_name\youme_chat.c; and [0466]
c:\youme\themes\theme_name\doll_name\youme_chat.h
[0467] The resulting binary data files can be saved as: [0468]
c:\youme\themes\theme_name\doll_name\player.sb.
[0469] The binary data file contains the entire information set
required to run the conversation on each doll. This binary data
file includes the firmware for the processor, and so additional
features can be incorporated into the doll's functionality without
the requirement for an additional process to update the
firmware.
[0470] In order that the correct phrases are recorded as way files
for the dolls a list of all the distinct phrases
(spoken_text_strings) for each doll is created and output using the
dictionary generation engine 1110, as shown in FIG. 11; this is a
dictionary of phrases required for each doll. The dictionary
generation engine 1110 communicates with the database 1122 within
the server 1004, and compiles the list based on the information
stored on the theme within the database. The dictionary is
effectively a look-up table between the expression/statement and
the ID number allocated to the expression/statement.
[0471] The phrases used by each doll are defined in the Statements
field and the Attributes field of each context row. They can be
explicitly defined spoken_text_strings or they can be references to
custom attributes. Whenever an explicit spoken_text_string is
defined it is allocated a file name such as A00xxx.wav in sequence
starting at A00001.wav. The number xxx will also be the phrase
index. The list of spoken_text_strings can be saved in the
following files: [0472]
c:\youme\themes\theme_name\phrases.txt--this contains a list of all
the phrases used in this theme [0473]
c:\youme\themes\theme_name\doll_name\phrases.txt--these contain a
list of all the phrases used by each doll
[0474] These files will contain text in the following format:
[0475] A00xxx The associated phrase as text
[0476] In this way, the process of creating the large number of way
files is simplified as the list of phrases can be recorded
sequentially, saved with the appropriate file name, and prepared
for downloading for use in the doll, or PC in the case where the PC
acts as a virtual doll.
[0477] As shown in FIG. 12A, the process for generating the files
is activated by the button 1212 "generate file". The user selects
the appropriate theme, that has been completed, and presses the
button 1212. This then generates the files as described above. The
entire bundle of files is then uploaded to the doll; this bundle
includes the binary file of the theme and accompanying operating
system, the sound (wav) files for the speech, and the processor
operating code (firmware).
[0478] The array of youme_conversation_struct_t conversation
structures, as described above, is the main controlling data for
the conversation. In outline, when the conversation is operated in
the controller doll, the conversation engine starts at the context
specified by index 1 of this array for the first doll. It then
performs the following actions: [0479] 1. It calls the current
context's transition procedure to decide which doll will be next.
[0480] 2. It calls the current context's set procedure to set the
values of any attributes specified in the context. [0481] 3. It
calls the current context's say procedure to select which statement
to speak according to the data specified in the context. This will
result in wireless communication to a remote doll if the current
doll is not the controller doll. In either case, the engine waits
until the audio output has completed before proceeding. [0482] 4.
It calls the context's branch procedure to select the next index
into the conversation array to use. [0483] 5. It sets the previous
doll pointer (prev) equal to the current doll pointer (me). [0484]
6. It sets the current doll pointer (me) equal to the next doll
pointer (next). The next doll pointer has been set in step 1.
[0485] 7. It then starts at step 1 again with the new index and
with the new doll, and continues this process until it hits a
FINISH branch in one of steps 4.
[0486] In an alternative embodiment, shown in FIG. 12D, an
additional method of inputting a conversation is provided. The
"Import Themes" button 1250 allows the user to import a text file
in order to create a themed conversation. In order to import a text
file, the file must be formatted in an appropriate manner. The
import theme feature allows for a text file to be converted
directly into a format suitable to be uploaded to the dolls,
without further input from the user.
[0487] The content of the text file can be some, or all, of the
content required to construct a theme. For example, the text file
can contain an entire (preferably self-contained) conversation,
about any topic. The entire conversation would then be imported
into the authoring tool and converted into a format suitable for
controlling the dolls. The text file would appear similar to a
script (such as for a play), with the doll's name followed by the
words that the doll should say. The authoring tool proceeds through
the text file and extracts the doll's name, creates a doll with
that name as described above with reference to FIGS. 13A and B, and
then stores the corresponding text as a context (a context is
described in further detail above). During the extraction
procedure, the authoring tool only creates a new doll when that
doll name has not been extracted previously from the text file. In
that case, the corresponding text is stored as another context for
that doll. This procedure continues until the entire text file has
been parsed into the authoring tool.
[0488] FIG. 12E shows a flow diagram of the process involved in
importing a text file into the authoring tool. The import means
identifies a line of text associated with a doll name, then creates
a doll if a doll with that name does not already exist. The text is
then imported into the authoring tool database and associated with
the corresponding doll's context. This process continues until all
of the lines of text are imported into the authoring tool. In order
for the text file to be parsed it must be formatted correctly, in
this case, the doll name must be followed by a colon, and each
entry for subsequent dolls must be on a new line. Appendix I
provides an example of a formatted text file, using the following
formatting requirements: [0489] $Theme: [0490] The text following
this statement is imported as the theme name [0491] $Dolln: [0492]
The text following this statement is imported as a statement for a
doll called Dolln
[0493] Once the text file has been parsed, the authoring tool
generates the output instructions, as described above. In this
embodiment the text file conversation engine only allows for
deterministic conversations to be created. However, once the text
file is imported into the authoring tool it is possible for the
user to amend the conversations to include further probabilistic
outcomes as described below.
USB Communications Dangle
[0494] In a further embodiment, a USB communications dangle is
provided that enables a PC to wirelessly interact with a toy as
described herein. FIG. 16 shows a schematic representation of the
USB communications dongle 1600, attached to a PC 304, and in
wireless communication with the dolls 100. The dangle contains a
wireless module 104, an IR/RF transmitter/receiver 212, and an
interface 1602. These components, except the interface 1602, are
the same as contained within the doll 100, as described above.
However, the PC 304 is utilised as the processor 1604, instead of
the dangle 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, that may be similar in
appearance to the real doll, and whereby the animation of the
avatar is 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. Alternatively, the authoring
tool, as described above, outputs specific code for the PC based
virtual doll, in both cases the themed conversation data is used to
run a conversation using an application running on the PC that
emulates the firmware of the toy/doll. The speech of the toy/doll
is output via the PC speakers.
[0495] The interface 1602 is a USB connection, and provides an
efficient way to connect the wireless communications dangle 1600 to
the PC 304. The wireless communications protocol used by the dangle
is the same as that used between the dolls as described herein,
i.e. IEEE 802.15.4.
[0496] When the user connects to the website he/she is able to use
the USB communications dangle to facilitate a conversation between
a physical doll, and a virtual doll animated within the website. In
this way a single user can use the functionality of the doll's
conversation engine without the requirement for multiple physical
dolls. In addition, the virtual doll can take part in a
conversation with multiple physical dolls. The virtual dolls can
also interact with other virtual dolls, e.g. if two users each had
a laptop computer with a USB communication dangle.
Game Playing
[0497] In a further embodiment the toy is also adapted to play
games with the child. For example, board games such as Snakes and
Ladders, Mousetrap, Ludo, or any other chance based game that can
be played using dice can be payed by the toy.
[0498] The toy is provided with a random number generator that is
used to simulate a die, or dice. Furthermore, the toy is adapted to
count the number of spaces to be progressed along the board by the
playing piece. The toy audibly signals the child to move the
playing piece the required number of spaces. Once the child has
moved the playing piece the child indicates to the toy, by pressing
a button or the like, that it is the next toys/child's turn.
Alternatively, the board is also interactive and contains sensors
or the like to receive information from the playing board regarding
the position of the counters. Play progresses in this way until
there is a winner.
[0499] FIG. 5 provides a schematic illustration of a controller toy
200 further comprising a games engine 400. The remaining components
are the same as described in FIGS. 2 and 3. The games engine 400
comprises a board memory 402, a random number generator 404,
position RAM 406 and an acknowledgement receiver 408.
[0500] The board memory 402 stores information relating to the
layout of board games such as Snakes and Ladders or Ludo. The
random number generator is used to simulate dice, and is adapted to
produce the numbers 1, 2, 3, 4, 5 and 6 (or any other set of
numbers appropriate to the game. The position RAM is used to store
information regarding the position on the board of each of the
players, in this case the controller and the three slaves. This
information is used in conjunction with the board memory and the
virtual dice roll to count the appropriate number of positions for
the playing piece to move, and to know whether the square the
playing piece has moved to has any special relevance, such as is it
the bottom of a ladder or the top of a snake.
[0501] The conversation engine 204 utilises the information
obtained from the games engine to count the number of spaces, for
example if the original position was square 13, and the virtual
dice roll produce a 4, then the doll would vocalise through the
loud speaker 210, "I've rolled a 4, 14, 15, 16, 17". In this
example if square 17 was the top of a snake then the doll would go
on to vocalise, "oh no, I've slipped down a snake to square 6!".
The counting mechanism cycles through the text the appropriate
number of times, and then remembers the final position, within the
position RAM 406. So, for example, when the virtual dice rolls a 4
the list of numbers is accessed 4 times to produce the end
result.
[0502] Additionally, the doll has the ability to receive
information from an external random number generator that is
activated by the child. In this way the child can play with the
dolls, and the doll can keep track of all of the player's playing
pieces including the child to determine when there is a winner.
[0503] FIG. 6 shows a flow diagram of the process of playing a
game. The game is initiated by the user, step 500, and the
controller doll will perform a check, step 502, to determine the
number of players. The controller doll will then decide on the
first player, step 504, using the random number generator or the
like. The controller doll then rolls the virtual dice, step 506,
for the first player, or if the child is the first player the
controller doll asks the child to roll their dice. The controller
doll then instructs the player to move the counter/playing piece,
the corresponding number of squares on the board, step 508, and
then waits for acknowledgement that the child has moved the
counter, step 510. At step 512 the controller doll waits a
pre-determined number of seconds, such as 2, 3, 5, or 8 seconds,
before prompting the child for acknowledgment that the counter has
been moved. Once the controller doll receives acknowledgement a
check is performed, step 514, to determine whether the player has
won the game. If the player has not won the game then the play
proceeds to the next player, step 516, and the process continues
from step 506 until a player wins, step 518.
[0504] The games engine is adapted to play any rule based game in
the manner described above.
[0505] Alternatively, the system could implement a conventional
programming language, such as C, to run more complex algorithms to
play more complex games such as chess. The same language as
described above would be used to generate the conversations and
would be referenced from the C program.
[0506] Such toys and dolls provide children with different
opportunities for interaction, and enhance their play.
Theme Examples
[0507] There are various examples of different methods of
constructing a conversation. For example, it is possible to have
randomly generated conversations, such as Zoo and Pet themes, a
fully scripted (deterministic) conversation, or a game playing
theme, such as to enable Snakes and Ladders to be played.
[0508] The unit's processor 102 is used in conjunction with the
other modules, such as the speech compiler 206, the speech database
208, and the parameter storage 216, to interpret the script within
the themes. For example, when a variable is defined memory is
allocated within the parameter storage. Each time the conversation
is initiated the variables are allocated within the parameter
storage. This enables the theme to be changed, i.e. from Zoo to
Pets, and for the new variables to be allocated the appropriate
memory resources without conflicting with the variables from a
previous conversation. Furthermore, the parameters such as PREV,
NEXT, and ME are also allocated memory within the parameter
storage. This enables the SELECT statement to reference the
parameter within the script.
[0509] When the SAY statement is used either the controller doll
uses the communication protocol described above to transmit the
command to the relevant doll using the wireless module and
transmitter, or if the controller doll is the current speaker the
controller doll's relevant modules are utilised. The Speech
compiler 206 within the doll required to speak is utilised to
access the appropriate audio file within the Speech database 208.
For example, the first line with a SAY statement within the Zoo
theme is "SAY (i think we've seen everything now,p03,lets go
home)". This statement consists of three references to audio files
within the Speech database. Those references are "i think we've
seen everything now"; "p03"; and "lets go home". They all refer to
audio files but the "p03" reference refers to a pause of a specific
length. The pauses are blank audio files used to space the audio
files appropriately. The Speech compiler 206 then uses the loud
speaker 210 to play the audio files. In each case the processor
interprets the code and utilises the appropriate module to execute
the statement.
[0510] In an alternative embodiment, as described herein, the
processor does not use an in-built interpreter, but instead each
theme consists of a binary data file that includes all of the
processor control instructions to enable the processor to function
correctly. This effectively enables the firmware of the processor
to be updated with new features whenever required. The theme
examples provided below can all be generated using the authoring
tool. However, the instructions to control the toys/dolls would be
a binary file of compiled "C" code.
Processor and Associated Electronics
[0511] FIGS. 8A, 8B, and 8C show the schematic of a circuit diagram
and parts list for a potential production version of the schematic
diagram shown in FIGS. 2 and 3--Appendix H details the components
within FIGS. 8A, 8B, and 8C. FIGS. 9A, 9B, and 9C show the
schematic of an alternative circuit diagram--Appendix III details
the components within FIGS. 9A, 9B, and 9C. There are alternatives
that could have been included in the production circuit, and these
are discussed later.
[0512] The circuit includes: [0513] The Jennic wireless
controller
[0514] The production circuit uses the Jennic IC, contains the RF
circuitry, and combines the firmware and data in to a single large
Flash memory IC. The Jennic wireless controller can use the Zigbee
wireless communications protocol for example to communicate between
the dolls. [0515] a The battery charger
[0516] The production circuit uses a part that is specifically
designed to charge from the USB port and also power a circuit
whilst charging. [0517] The Audio amplifier
[0518] The audio amplifier on the production circuit is a class-D
audio amp. This is very efficient (.about.80%).
Technical Options
[0519] This section discusses possible alternatives that have not
been included in the production circuit in FIGS. 8A, 8B, and 8C.
[0520] USB interface
FTDI FT245RQ
[0521] This component was chosen primarily as it a ready-to-use IC
complete with USB driver software, reducing development effort. Its
main disadvantage is that it uses most of the DIOx lines on the
Jennic. Although this is not an issue with the current design, if
DIOx lines are needed for other options, e.g. speech compression
IC, then this part would be unsuitable.
Alternative Embodiments
[0522] Both the alternatives below are 8-bit microcontroller ICs
with built-in USB and SPI slave interfaces. They both need to have
firmware and software drivers developed to make them functional,
although both manufacturers provide reference designs, application
notes etc to aid in this process. The advantage of these parts are
that they can interface with the Jennic SPI interface, and only
need 1 DIOx line, freeing up the other DIOx lines for other
uses.
[0523] The toy does not have complex USB requirements; the only
requirement is to download data to be programmed in to Flash
memory. The device does not need to conform to any generic device
functionality, e.g. memory sticks. This reduces the development
effort required.
[0524] The parts identified below were chosen as they are targeted
at simple low-power embedded applications and have an SPI slave
interface. However, other devices from the manufacturers' families
or from other manufacturers may well be equally suitable.
Cypress CY7C63833-LFXC
Atmel AT90USB82-16MU
Battery
Lithium-Ion
[0525] The circuits shown in FIGS. 8A, 8B, and 8C and 9A, 9B, and
9C use a Lithium-ion (Li+) battery. The Li+ battery was chosen for
3 reasons: [0526] i) Shape--it is available in a flat prismatic
package that was convenient for the demonstrator project. [0527]
ii) Ease of development--Li+ charging requirements are simpler than
the alternatives, especially when the charger has to power an
additional circuit at the same time. [0528] iii) Power capacity--a
conservative estimate of power requirements at the start of the
demonstrator project suggested that only Li technology would give
enough power in the small space available. (See later).
[0529] Alternative rechargeable technologies are NiMH and NiCad,
NiMH has similar charging requirements to NiCad (more complex than
Li+), but has similar (higher) power density (holds more power for
a given physical volume) and price to that of Li+.
NiCad/NiMH
[0530] The characteristics of NiCad/NiMH batteries compared to Li+
will be considered in this section. For simplicity, read NiMH for
NiCad in the sections below.
i) Shape
[0531] NiCad batteries usually come in standard sizes such as AA,
and AAA, although other shapes are available. In a production
environment where smaller components can be used, and where the
cost of manufacturing more complex PCBs, such as two pieces and/or
flexible circuits/connectors may not be inhibitive, the use of
standard size batteries may be possible,
ii) Ease of Development
[0532] The circuit must be powered up (from the USB port) at the
same time as the battery is charging (from the USB port), so that
it can download new data. (The battery cannot simultaneously be
charged and power the circuit.) It is possible to either isolate
the circuit from the battery during charging or leave the circuit
connected. Isolating the battery involves more complex circuitry.
Leaving the circuit connected means that the charger sees both the
normal current to the battery that it is controlling and the extra
current our circuit takes.
[0533] Leaving the circuit connected for Li+ battery chargers is
not so critical. The main disadvantage is that it is normal to
switch off the charger once the Li+ battery is fully charged. This
function has to be inhibited otherwise our circuit would be
switched off as well. The result is a shorter lifetime for the
battery.
[0534] Leaving the circuit connected for NiCad battery chargers is
critical. NiCad batteries have a more complex charging profile,
especially towards the end of charging. If this profile is not
detected correctly, the battery is never fully charged, or the
battery is overcharged resulting in damage to the battery and
excessive temperature rises. Battery chargers use one of two
methods to detect this profile. The first is by changes in current
drawn by the battery. Unfortunately, the currents drawn by the
present circuit will confuse the charger, resulting in potentially
dangerous circumstances. The second method is by detecting changes
in temperature of the battery. However, the battery charging
components also get hot during normal use. In this application, it
may be difficult to thermally isolate the battery enough to give
reliable results.
[0535] Isolating the battery is the solution adopted by the circuit
in FIGS. 8A, 8B, and 8C. The battery charger IC incorporates
sophisticated power management circuitry and provides the
isolation. This integrated power management is not available for
NiCad technology in off-the-shelf products. So this would be
implemented in discrete components or in a custom integrated
IC.
iii) Power Capacity
[0536] A discussion of the power requirements on the doll
electronics is given in this section. Battery lives used in this
section are based on the following battery capacities: [0537] AAA
Alkaline=1150 mAh@1.5V [0538] AAA NiCad=300 mAh@1.2V [0539] AAA
NiMH=750 mAh@1.2V [0540] Li+ prismatic=620 mAh@3.7V
[0541] Note: The Li+ battery holds twice as much power for the same
rating as the other batteries because its voltage is twice as
large. Either two AAA batteries must be used in series, or a single
AAA is used with a step-up converter and its capacity is
halved.
[0542] Power estimates for circuit shown in FIGS. 9A, 9B, and
9C.
[0543] Estimated current consumption=136 mA when speaking, 48 mA
otherwise. This is made up from: [0544] Jennie module=48 mA [0545]
Audio Driver:
[0546] 250 mW max 8 ohm speaker power=175 mA, but in a conversation
between 2 dolls each doll speaks for half the time=>88 mA.
[0547] Note: it is unlikely that the speaker will be driven at
maximum power the whole time, however the audio amp is not 100%
efficient, so 88 mA is a reasonable compromise. [0548] Rest of
circuit=negligible
[0549] Battery lives based on Demonstrator estimates.
TABLE-US-00002 Continuous Powered but no Battery conversation
speaking Single AAA Alkaline 41/4 hrs 12 hrs Single AAA NiCad 66
mins 3 hrs Single AAA NiMH 23/4 hrs 7 hrs 40 mins Dual AAA Alkaline
81/2 hrs 24 hrs Dual AAA NiCad 21/4 hrs 61/4 hrs Dual AAA NiMH 51/2
hrs 15 hrs 40 mins Single prismatic Li+ 41/2 hrs 13 hrs
[0550] The single prismatic Li+ solution was the obvious choice for
the demonstrator.
[0551] Power requirements of the circuit shown in FIGS. 8A, 88, and
8C
[0552] As the audio power is the most significant factor in the
overall power consumption, it is important to get a more precise
value. The best method is a direct measurement, but this is only
possible once the audio performance is finalised.
[0553] However, there are a number of factors that suggest the
audio power will not be as great as the estimates: [0554] The
characteristics of speech make the average power of a waveform a
lot less than its peak amplitude. For instance, speech contains a
lot of pauses. So it is likely that the circuit will drive at less
than the maximum average power levels. [0555] The class-D amplifier
used in the production circuit has much better efficiencies than
the one in the circuit shown in FIGS. 9A, 9B, and 9C, resulting in
a significant power saving.
[0556] More detailed calculations and analysis of the demonstration
conversations suggest that the average audio power will be only 10
mA whilst speaking, so for a conversation between 2 dolls gives and
average of 5 mA. This makes the Jennic power dominate giving a
total of 53 mA when speaking and 48 mA when not.
[0557] Note: This audio power level is only for spoken voices, not
music.
[0558] Battery lives based on improved estimates for audio
power
TABLE-US-00003 Continuous Powered but no Battery conversation
speaking Single AAA Alkaline 10 hrs 50 mins 12 hrs Single AAA NiCad
23/4 hrs 3 hrs Single AAA NiMH 7 hrs 7 hrs 40 mins Dual AAA
Alkaline 21 hrs 40 mins 24 hrs Dual AAA NiCad 51/2 hrs 61/4 hrs
Dual AAA NiMH 13 hrs 50 mins 15 hrs 40 mins Single prismatic Li+
111/2 hrs 13 hrs
[0559] There are ways to reduce the power consumption of the
Jennic. Currently, the Jennic is on all the time, listening for
messages continually. With a change in the firmware, and the way
the dolls communicate with one another, only one doll (the first to
be powered up) needs to be listening continually. The other dolls
can check periodically with the first doll if they need to speak,
and only need to be powered for this short time. The rest of the
time the Jennic can be in low-power sleep mode. If a 10% duty cycle
is achievable this would cut the power consumption by a factor of
10 when not speaking. When speaking, the Jennic needs to be
powered, but it does not need to listen for messages, so the RF
stage can be unpowered. This reduces the Jennic power consumption
by a factor of 4. Thus it may be possible to reduce the overall
current consumption to 14 mA when speaking and 4 mA when not.
[0560] Although the most dolls would have this reduced power
requirement, one doll (the first to be switched on) would not have
this power saving. With a change in the way the dolls are activated
it may be possible to reduce this as well. Further investigations
are needed to determine what is feasible.
[0561] Battery lives based on reduced Jennic power requirement
TABLE-US-00004 Continuous Powered but no Battery conversation
speaking Single AAA Alkaline 41 hrs 1433/4 hrs Single AAA NiCad
103/4 hrs 371/2 hrs Single AAA NiMH 263/4 hrs 933/4 hrs Dual AAA
Alkaline 82 hrs 2871/2 hrs Dual AAA NiCad 211/2 hrs 75 hrs Dual AAA
NiMH 541/2 hrs 1871/2 hrs Single prismatic Li+ 441/2 hrs 155
hrs
[0562] If these power requirements can be achieved then the use of
dual AAA standard, NiCad or NiMH batteries becomes possible.
Automatic Power-Off Function
[0563] The current specification for the doll electronics is that
an ON-OFF switch controls the powering of the circuit. Unlike other
toys, it is not obvious when the doll is switched on, as it sits
passively waiting for a button to be pressed in any one of the
active dolls. This means that it is highly likely that the dolls
will be forgotten to be switched off. The result is that the next
time (e.g. next day) the doll is played with the batteries will be
dead.
[0564] It is possible for the circuit to switch itself in to a
`standby` mode, drawing very little current, but this has not been
included in the current functional specification. When the
electronics goes in to this standby mode and how it is re-activated
has implications for the overall behaviour and performance of the
doll.
Speech Compression
[0565] Speech compression allows more audio data to be stored in
the same amount of memory. The current designs do not contain any
speech compression technology. The current designs use 8-bit 8 kHz
audio data that results in a data rate of 64k bps (bits per
second), and uses a 64 Mbit serial flash memory enabling about 1000
seconds (17 minutes) of audio data to be stored. Speech compression
can be used to drop this data rate to between 2 kbps and 8 kbps,
the higher compression the lower the audio quality. So at 8 kbps a
4 Mbit flash memory can hold about 500 seconds (81/2 minutes) of
audio data.
[0566] Compressed audio data requires decompression as it is played
out. This can be done in software or dedicated hardware. A few
options are given below.
Software Decompression on Jennic Controller
[0567] This option has not been widely investigated. Firstly, the
source code of suitable compression/decompression algorithms must
be found, so that the algorithms can be ported on to the Jennic
controller. Secondly, and analysis of processing power required by
the algorithms and available on the Jennic controller must be
done.
Sensory Inc Speech Synthesis ICs
[0568] Sensory Inc has two microcontroller families. The SC-6x
family has the pre-programmed SC-691 slave synthesiser. This has a
4-bit MCU interface that requires 9 DiOx lines to interface to the
Jennic and can direct drive a 32 ohm speaker. The newer RSC-4x
family does not have a pre-programmed slave synthesiser, and so
requires custom firmware to be developed. It would interface to the
Jennic with a 4-bit or 8-bit MCU interface (9 or 15 DOIx lines).
However it has a more powerful processor (it can handle speech
recognition algorithms), and can direct drive an 8-ohm speaker.
Either of these parts could not be used with the USB FT245 chip, as
the Jennic does not have enough DIOx lines for both. A slave SPI
USB chip would be necessary (see USB section),
[0569] Using a speech synthesis microcontroller such as RSC-4x that
has significant processing power suggests a possible alternative
system architecture. Instead of the Jennic wireless microcontroller
running the main doll algorithms, and using the synthesis
microcontroller as a slave co-processor to simply decompress the
audio, the synthesis microcontroller could run the main doll
algorithms and use the wireless microcontroller as a slave
co-processor for wireless communications. See the Wireless
microcontroller section for further details.
Wireless Microcontroller
[0570] The current design is based on the 2.4 GHz IEEE 802.15.4
Personal-Area-Network communications standard. Wireless
microcontroller products exist that contain the necessary RF
hardware and firmware to take care of all low-level RF
communications. Only the data in the communications needs to be
defined by the doll application. The current design has selected
the Jennic wireless microcontroller.
[0571] Although the IEEE 802.15.4 products take care of the
low-level RF communications, there is one aspect that is not a good
fit with the doll application. The IEEE 802.15.4 is based on a
hierarchical structure of nodes, with many reduced function devices
communicating with a full function device. The doll application has
a peer-to-peer structure, where all devices are the same.
[0572] Other RF transceiver products that work in the same 2.4 GHz
or different ISM frequency bands are available. They contain all
the necessary RF hardware, but do not impose a particular low-level
protocol. These transceiver ICs work as a slave to either a general
purpose microcontroller or dedicated microcontroller such as the
RSC-4x speech synthesiser. Using these parts a proprietary
peer-to-peer communications protocol could be developed.
[0573] Examples of RF transceivers are Ti CC2500 and Atmel ATA542x
family. These parts potentially provide lower power consumption and
lower unit costs than the Jennic IC.
[0574] It is of course to be understood that the invention is not
intended to be restricted to the details of the above embodiments
which are described by way of example only, and modifications of
detail can be made within the scope of the invention.
[0575] Each feature disclosed in the description, and (where
appropriate) the claims and drawings may be provided independently
or in any appropriate combination.
[0576] Appendix I--Example of formatted text file for import into
the Authoring Tool
[0577] $Theme: MALL SCENARIO ONE
[0578] $Doll1: Hi--Thanks for coming!
[0579] $Doll2: Are you kidding--I'd never miss a trip to the mall
with you guys!
[0580] $Doll3: Or a chance to check out the sales!
[0581] $Doll4: I've got all my spending money with me!
[0582] SDoll3: This is gonna be super fun!
[0583] $Doll2: So what do we hit first--The department stores--Shoe
sale or the cosmetic stand?
[0584] SDoll1: I don't mind but I can't leave without buying a new
glitter gloss.
[0585] $Doll4: And I have to check out the new ribbon tie sandals
at the shoe boutique!
[0586] $Doll1: They would totally go with your boot cut jeans.
[0587] SDoll4: Totally.
[0588] $Doll3: Oh and I need to check if that pussy bow dress comes
in pink yet--They only ever have blah blue!
[0589] $Doll1: Are you sure ifs the dress you wanna check out?
[0590] $Doll2: And not the boy working on the coffee counter
outside?
[0591] $Doll4: (Giggles) Totally!
[0592] $Doll1: (Giggles1).
[0593] $Doll2: (Giggles2).
[0594] $Doll3: No way--That's SO not happening--It's all about the
dress!
[0595] $Doll4: Oh--You're so couture!
[0596] $Doll3: (Giggling) Totally!
[0597] $Doll2: So where shall we start?
[0598] $Doll: I say hit the second floor department store and work
our way back to the shoe boutique.
[0599] $Doll4: And make sure we hit the purse stall.
[0600] $Doll2: And the Bling Box.
[0601] $Doll3: Ooh--And the nail bar!
[0602] $Doll1: I think I'm gonna need a smoothie before all
that
[0603] $Doll2: Great idea--Let's spilt a raspberry crush.
[0604] $Doll3: No--Orange cream!
[0605] $Doll4: Peppermint delight?
[0606] $Doll2: Maybe we should just get our own--We don't have to
share everything.
[0607] $Doll1: And let's decide when we get to the smoothie
lounge--or we'll never get started!
[0608] $Doll3: Cool!
[0609] $Doll1: So what are we waiting for?
[0610] $Doll2: Let's roll!
[0611] $Doll4: Totally!
[0612] Appendix II--Details of components relating to FIGS. 8A, 8B,
and 8C
TABLE-US-00005 Part Description Value Comment R8 Resistor 1% 1k6
R12 4k7 R14 39k R11 43k R6 56k R2 100K R7 150k R9, R13 200k R1 220k
R3 Resistor 5% 10k R4, R10 100k C4, C8 Capacitor, 5% COG 15p C15
47p C17 330p C9, C13 Capacitor, 10% X7R 2n2 C18 3n3 C1, C2, C3, C7,
Capacitor, hi-cap multilayer 100n C11, C12, C14, ceramic decoupler,
6v3 C16, C19, C20, C21, C22, C23, C24, C25, C26, C27 C5, C10 2u2 C6
10u IC1 IEEE 802.15.4 wireless JN513x www.jennic.com controller IC2
Low speed USB peripheral FT245R www.ftdichip.com controller IC3 64
Mb serial flash AT45DB642 www.atmel.com IC4 Micropower op amp
MCP607 www.microchip.com IC5 Class-D Audio Driver TPA2005
www.ti.com IC6 LDO reg 3v3, 200 mA w MAX882CSA+ www.maxim-ic.com
shutdown IC7 Battery charger, USB and BQ24032A www.ti.com power
management Q1 Digital FET switch/ FDV301N www.fairchildsemi.com
inverter D2 Signal diode TS4148 J1 Ceramic antenna Alternative:
printed circuit 2.45 GHz 50R antenna T1 Balun Transformer e.g.
Murata 2.45 GHz LDB182G4520C- 200R(diff): 50R(unbal) 110 XTAL1
Crystal resonator 16.0 MHz SW1 Push button switch START JP1 Mini B
USB connector e.g. Molex 54819- www.molex.com 0519 JP5 TEST
connection Optional JP6 JENNIC connection Optional: for debugging
SW2 (JP2) SPST switch ON-OFF B1 (JP3) Li+ battery 620 mAh Olympus
camera battery Li-30B LS1 (JP4) Loudspeaker, 8 ohm ADS02008MR-R
www.projectsunlimited.com
[0613] Appendix III--Details of components relating to FIGS. 9A,
9B, and 9C
TABLE-US-00006 Part Description Value Order Code R6 Resistor 1%
0R15 FEC 1107344 R8, R9 20k FEC 9332774 R2 100K FEC 9332405 R7 150k
FEC 9332626 R1 220k FEC 9332839 R3 Resistor 5% 10k FEC 9332391 R4,
R5, R10 100k FEC 9332405 C15 Capacitor, 5% NPO 47p FEC 9406263 C10
2n2 FEC 9406220 C13 Capacitor, 10% X7R 22n FEC 9406360 C2, C7, C9,
Capacitor, Decoupler X7R 100n FEC 1294627 C11, C12, C14, C16 C5 2u2
FEC 9402152 C1, C6 Capacitor decoupler X5R 10u FEC 9227814 U1 IEEE
802.15.4 wireless controller JN5121-00-M00 www.sequoia.co.uk module
IC1 Battery charger MCP73826C- FEC 1084313 4.2VCHTR IC2 Low speed
USB peripheral FT245RL FEC 1146034 controller IC3 64 Mb serial
flash AT45DB642D-TU FEC 1095799 IC4 Micropower op amp MCP607-I/SN
FEC 1196812 IC5 Audio Driver TPA301D FEC 8456518 IC6 LDO reg 3v3,
200 mA w shutdown MAX882CSA+ FEC 1188007 IC7 Voltage monitor, 4v75
MCP121T-475E/TT FEC 8752893 Q1 Digital FET switch/inverter FDV301N
FEC 9845011 Q2 p-channel power MOSFET FDS6375 FEC 9846212 D1
Schottky diode, 1A ZLLS1000 FEC 9525688 D2 Signal diode TS4148 RY
FEC 8150206 SW1 START Push button switch 6 mm SMD FEC 3121173 JP5
TEST connection JP6 JENNIC connection Molex 52746-1070 FEC 9786325
SW2 (JP2) SPST switch ON-OFF JP1 Mini B USB connector e.g. Molex
54819- FEC 9786465 0519 B1 (JP3) Li+ battery 620 mAh Olympus camera
battery Li-30B LS1 (JP4) Loudspeaker, 8 ohm ADS02008MR-R FEC
1192972
* * * * *
References