対話式玩具
プロセッサと、前記プロセッサに結合されたメモリと、前記プロセッサに結合された出力部と、少なくとも1つのさらなるこのような玩具とのネットワーク接続を確立する手段とを含む玩具を提供し、プロセッサはネットワーク接続が確立された個々の玩具の出力を制御する手段を含む。さらに、制御手段は、ネットワーク接続が確立された個々の玩具の複数の出力(好ましくは全ての出力)を制御するための命令を前記ネットワーク接続を介して送信するようになっている。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は玩具に関する。特に、限定的な意味ではないが、本発明は互いに対話する人形などの玩具に関する。
【背景技術】
【0002】
組込み型コンピュータ及びマイクロプロセッサは、子供用玩具を進歩させてきた。これらは教育用玩具において最も広く使用されてきたが、対話型玩具においても使用されてきた。ActiMates(登録商標)Barney(登録商標)は、子供からの適切な発声による対話に応答するとともにビデオに合わせて歌うことができる対話型玩具の一例である。
【0003】
本明細書にはPCT特許出願WO2006/114625号が引用により組み入れられる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】PCT特許出願WO2006/114625号
【発明の概要】
【課題を解決するための手段】
【0005】
オーサリングツール
本発明の第1の態様によれば、玩具のテーマ別データを作成するためのオーサリングツールが提供され、該オーサリングツールは、特定のテーマに関連するコンテンツを受信する手段と、前記コンテンツを処理して前記特定のテーマ内で前記玩具を動作させるための命令セットを生成する手段と、前記命令セットを出力する手段とを含む。玩具を動作させるための命令セットを生成する手段を提供することにより、テーマ別の命令を生成するプロセスが実質的により効率化される。
【0006】
コンテンツを受信する効率性のために、前記受信手段は、特定のテーマに関連するスクリプトデータ及び前記玩具の性格を定義する表現データの両方を別個に含むコンテンツを受信するようになっていることが好ましい。前記受信手段は、コンテンツを別の部分の形で受信するようになっていることが好ましい。
【0007】
処理の効率性のために、オーサリングツールは、個々の表現データ部分に一意のID番号を割り当てる手段をさらに含むことが好ましい。前記処理手段は、前記命令セットにおいて前記表現データ部分への参照として前記一意のID番号を利用するようになっていることが好ましい。
【0008】
前記表現データは、テーマ名、玩具の名前、及び玩具が対話するために使用する文のうちの少なくとも1つを含むことが好ましい。
【0009】
前記スクリプトデータは、テーマ内で対話できる玩具の数、対話方法、テーマ関連パラメータ、及び玩具関連パラメータのうちの少なくとも1つを含むことが好ましい。
【0010】
処理の効率性のために、オーサリングツールは、特定のテーマに関連する前記スクリプトデータ及び表現データを共に配列の形で記憶する手段をさらに含むことが好ましい。前記処理手段は、前記配列から前記命令セットを生成するようになっていることがさらに好ましい。
【0011】
処理の効率性のために、前記処理手段は、表現データの少なくとも一部を含む少なくとも1つのリストをコンパイルする手段を含むことが好ましい。前記リストコンパイル手段は、前記特定のテーマ内で玩具ごとにそれぞれのリストをコンパイルするようになっていることがさらに好ましい。
【0012】
表現データはシンボルデータであることが好ましい。本明細書で使用するシンボルデータは、書かれた形の単語、音楽又は行動を意味する。
【0013】
オーサリングツールは、シンボルデータの上演(enacted)データバージョンを記録する記録手段をさらに含むことが好ましい。本明細書で使用する上演データとは、上演される形の単語、音楽又は行動を意味するものである。
【0014】
オーサリングツールは、関係者に上演データの必要な部分を生成するように促す手段を含むことが好ましい。
【0015】
前記プロセッサは、シンボルデータと上演データとの間のルックアップテーブルを生成するようになっていることが好ましい。
【0016】
前記処理手段は、表現データを出力するようになっていることが好ましい。前記処理手段はさらに、表現データ及び命令セットを別個に出力するようになっていることがさらに好ましい。
【0017】
前記処理手段は、玩具の基本機能を制御するための基本命令セットと、基本命令セットがテーマ内で玩具を制御するためのテーマ別命令セットとを含む命令セットを生成するようになっていることが好ましい。前記プロセッサは、前記基本命令セット及び前記テーマ別命令セットを共に組み合わせるようになっていることがさらに好ましい。
【0018】
オーサリングツールは、コンパイラをさらに含むことが好ましい。前記プロセッサは、前記基本命令セット及び前記テーマ別命令セットをコンパイルするようになっていることがさらに好ましい。
【0019】
前記プロセッサは、前記命令セットをコンピュータ可読コードに変換するようになっている符号化エンジンを含むことが好ましい。
【0020】
オーサリングツールの出力は、本明細書で説明するような会話エンジンで使用されるようになっていることが好ましい。
【0021】
玩具は、本明細書で説明するような玩具であることが好ましい。
【0022】
本発明の第2の態様によれば、玩具のテーマ別データを作成するオーサリングツールのためのユーザインターフェイスが提供され、該ユーザインターフェイスは、各々がテーマに関連する特定のコンテンツのサブセットの入力に対応する入力ウィンドウのセットをユーザに提供する手段と、テーマ別データの出力を開始する手段とを含む。
【0023】
前記コンテンツのサブセットは、テーマ関連データ、玩具関連データ及びコンテキスト関連データのうちの少なくとも1つを含むことが好ましい。
【0024】
コンテキスト関連データは、玩具が対話するために使用する文、対話方法、テーマ関連パラメータ及び玩具関連パラメータのうちの少なくとも1つを含むことが好ましい。
【0025】
本発明の第3の態様によれば、玩具のテーマ別データを生成するためのシステムが提供され、該システムは、テーマ別データにアクセスし、これを作成及び編集するオーサリングツールと、前記テーマ別データを記憶するためのデータベースを含むサーバとを備え、オーサリングツールは、インターネットを介してテーマ別データにアクセスするようになっている。
【0026】
オーサリングツールは、テーマ別データを処理して配列するようになっており、前記データベースは、前記テーマ別データを前記配列の形で記憶するようになっていることが好ましい。
【0027】
オーサリングツールは、本明細書で説明するようなオーサリングツールであることが好ましい。
【0028】
オーサリングツールは、ユーザインターフェイスをさらに含むことが好ましい。ユーザインターフェイスは、本明細書で説明するようなインターフェイスであることがさらに好ましい。
【0029】
USB通信ドングル
本発明のさらなる態様によれば、本明細書で説明するような少なくとも1つの玩具とコンピュータの間に無線通信を提供する装置が提供され、該装置は、装置をコンピュータに接続するための通信ポートと、コンピュータと前記又は各玩具との間にネットワークを確立する手段とを含み、コンピュータが別のこのような玩具であるかのように前記又は各玩具と通信できるようにする装置を提供する。
【0030】
前記装置は、コンピュータを仮想玩具として機能できるようにすることが好ましい。
【0031】
前記通信ポートはUSB通信ポートであることが好ましい。
【0032】
前記ネットワークは無線であることが好ましい。
【0033】
本発明のさらに別の態様によれば、本明細書で説明するような少なくとも1つの玩具と、各々が本明細書で説明するような無線通信を行う装置を有する少なくとも1つのコンピュータとを備えたシステムが提供され、前記コンピュータと装置とを組み合わせることにより本明細書で説明するような玩具であるかのように機能する。
【0034】
前記コンピュータは、仮想玩具を提供するようになっている視覚及び音声出力を含むことが好ましい。仮想玩具は、アバターであることがさらに好ましい。
【0035】
コントローラ人形
本発明のさらに別の態様によれば、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部と、少なくとも1つのさらなるこのような玩具とのネットワーク接続を確立する手段とを含む玩具が提供され、プロセッサは、ネットワーク接続が確立された各玩具の出力を制御する手段を含む。
【0036】
前記制御手段は、ネットワーク接続が確立された各玩具の複数の出力(好ましくは全ての出力)を制御する命令をネットワーク接続を介して送信するようになっていることが好ましい。
【0037】
前記ネットワーク接続が、パーソナルエリアネットワークの一部を形成することが好ましい。
【0038】
前記メモリは、データの少なくとも1つのグループを記憶するようになっており、個々の前記少なくとも1つのグループは特定のテーマを表すことが好ましい。
【0039】
玩具は、前記メモリに記憶された少なくとも1つのテーマを決定する手段をさらに含むことが好ましい。
【0040】
前記玩具は、別の玩具との接続を、前記メモリに記憶された少なくとも1つのテーマが両玩具において同じである場合にのみ確立するようになっていることが好ましい。
【0041】
前記制御手段は、制御メッセージを送信/受信して個々の前記玩具の出力を制御するようになっていることが好ましく、制御メッセージは、対象の玩具のID及びコマンドセグメントを含むことが好ましく、発信元玩具のID及び/又はメッセージIDをさらに含むことがより好ましい。
【0042】
前記制御メッセージは、参照データベースにアクセスしてタスクを実行する命令を含むことが好ましい。
【0043】
プロセッサは、前記送信/受信された制御メッセージの確認応答を送信/受信する手段を含むことが好ましく、前記送信/受信手段は、確認応答を受信しない場合に制御メッセージを再送するよう要求するようになっていることが好ましい。
【0044】
前記送信/受信手段は、このような玩具が制御メッセージに基づいて出力を生成するのに掛かるであろう時間に関連するパラメータを送信するようになっていることが好ましく、発信元玩具は、さらなる制御メッセージを送信するまで前記パラメータに関連する時間の間待機することが好ましい(このような玩具がこのような出力を生成するのに掛かる時間は、例えば玩具のテーマ又はサブテーマにより様々であってもよい)。
【0045】
プロセッサが、再送信制御メッセージの数をカウントする手段を含み、これにより前記制御メッセージの確認応答を行わない前記玩具との通信が、1,000〜2,000回、2,000〜5,000回、5,000〜10,000回又はそれ以上の試行後に停止されることが好ましい。
【0046】
前記プロセッサは、前記玩具間の会話を構築するようになっている会話エンジンをさらに含むことが好ましい。
【0047】
さらなるこのような玩具は、最初のこのような玩具と同一又は実質的に同一であることが好ましい。従って、「スポークハブ」構成は不要である。
【0048】
前記ネットワークを確立する手段はネットワークコントローラであることが好ましく、Zigbeeプロトコルを利用するネットワークコントローラであることが好ましい。
【0049】
パラメータ記憶
玩具は、別のこのような玩具と対話するようになっており、前記プロセッサは、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数をメモリに記憶する手段と、前記変数を使用して前記玩具の(対話型)出力を制御する手段とを含むことが好ましい。
【0050】
本発明のさらに別の態様によれば、別のこのような玩具と対話するようになっている玩具が提供され、該玩具は、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを備え、前記プロセッサは、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数をメモリに記憶する手段と、前記玩具の(対話型)出力に関連して変数を使用する手段とを含む(この結果より効率的に対話の経過を追い続けることが好ましい)。
【0051】
前記変数を複数回(より好ましくは数えきれないほど)使用して出力を制御することが好ましい。
【0052】
前記変数を使用して、前記対話の回数、種類又は性質を決定することが好ましく、前記変数が前記対話であることが好ましい。
【0053】
前記変数は、ランダムに又は疑似ランダム的に選択され、前記ランダム選択は重み付けにより影響されることが好ましい。
【0054】
玩具は、対話を生成する手段をさらに含むことが好ましい。対話を生成する手段は、記憶パラメータに基づいて対話を生成するようになっていることが好ましい。
【0055】
記憶手段は、各変数を玩具と関連づけることが好ましい。
【0056】
記憶手段は、玩具内に位置するメモリであることが好ましい。
【0057】
変数を使用する手段は、記憶手段から変数にアクセスするようになっていることが好ましい。
【0058】
前記対話は、玩具間の通信であることが好ましい。
【0059】
前記変数は、発話で利用される単語又は語句であることが好ましい。
【0060】
性格の表現及びテーマのスクリプト記述
前記プロセッサは、前記メモリにテーマ別データを記憶するようになっており、前記テーマはスクリプトデータ及び表現データを含み、前記表現データが前記玩具の性格を定義することが好ましい。
【0061】
本発明のさらに別の態様によれば、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを備えた玩具が提供され、前記プロセッサは、前記メモリにテーマ別データを記憶するようになっており、前記テーマはスクリプトデータ及び表現データを含み、前記表現データが玩具の性格を定義する(この結果、複数のテーマ別の玩具の性格がより効率的に提供されることが好ましい)。
【0062】
玩具は、少なくとも1つの他の同様の玩具と対話するようになっており、前記スクリプトデータが個々のこのような玩具により共有され、前記表現データが個々のこのような玩具間で異なることが好ましい。
【0063】
前記スクリプトデータは、前記表現データとは無関係であることが好ましい。
【0064】
プロセッサは、別のこのような玩具に制御メッセージとしてスクリプトデータを出力するようになっており、制御メッセージに個々の表現データで応答するようになっていることが好ましい。
【0065】
スクリプトデータは、各玩具ごとに同じものであり、各玩具の出力を制御することが好ましい。
【0066】
プロセッサは、スクリプトデータを利用して表現データを参照するようになっていることが好ましく、表現データは、異なるコンテンツを使用して同じ情報を通信することが好ましい。
【0067】
玩具の性格は、通信のコンテンツにより定義されることが好ましい。
【0068】
人形の選択
プロセッサは、対話するための玩具を予め定めたルールに基づいて選択する手段を含むことが好ましい。
【0069】
本発明のさらに別の態様によれば、他のこのような玩具と対話するようになっている玩具が提供され、該玩具は、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを備え、前記プロセッサは、対話する玩具を予め定めたルールに基づいて選択する手段を含み、前記選択される玩具は発信元玩具であってもよい。
【0070】
前記選択手段は、次の対話する玩具を選択するようになっていることが好ましい。
【0071】
前記予め定めたルールは、直接選択、ランダム選択、及び現在の対話玩具を選択して再び対話することを含むことが好ましい。
【0072】
プロセッサは、選択された玩具のID及び好ましくは発信元玩具のIDを含む制御メッセージを出力するようになっていることが好ましい。
【0073】
前記対話は通信を含むことが好ましく、該通信は発話及び指示を含むことが好ましい。
【0074】
ゲームのプレイ
玩具は、他の同様の玩具とゲームをプレイすることに適した生きているものの形をとり、前記プロセッサはゲームエンジンを含み、該ゲームエンジンは、前記玩具が生きているかのようにゲームをプレイ可能にするようになっていることが好ましい。
【0075】
本発明のさらに別の態様によれば、他の同様の玩具とゲームをプレイすることに適した生命があるものの形をした玩具が提供され、該玩具は、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを含み、前記プロセッサは、個々の前記玩具を関連する生きているものであるかのようにゲームできるようにするゲームエンジンを含む。
【0076】
前記ゲームエンジンは、人間のゲームを可能にするようになっていることが好ましい。
【0077】
前記人間のゲームは、ゲーム機器でプレイされることが好ましい。
【0078】
前記ゲームエンジンは、人間がゲーム機器を調整してゲームをプレイできるようにする命令を出力するようになっていることが好ましい。
【0079】
前記玩具は、少なくとも1つのさらなるこのような玩具と通信する手段をさらに含むことが好ましい。
【0080】
前記ゲームエンジンはさらに、ルールに基づいたゲームをプレイするようになっていることが好ましい。
【0081】
前記ゲームエンジンは、前記メモリにゲームに関する情報を記憶するようになっていることが好ましい。
【0082】
前記情報はゲームのルールを含むことが好ましい。
【0083】
前記情報は、少なくとも1つのプレイボードのレイアウトをさらに含むことが好ましい。
【0084】
前記ゲームエンジンは、仮想サイコロになっている乱数発生器を含むことが好ましい。
【0085】
ゲームエンジンは、ゲームに関する外部入力を受信する手段を含むことが好ましい。
【0086】
前記外部入力は、ゲームの駒に関連付けられることが好ましい。
【0087】
前記外部入力は、プレイボード内の少なくとも1つのセンサであることが好ましい。
【0088】
前記外部入力は、玩具のユーザが使用するようになっているスイッチであることが好ましい。
【0089】
前記ルールに基づくゲームは、ヘビとはしご及びルードを含むことが好ましい。
【0090】
前記出力は変換器であることが好ましい。前記変換器はスピーカであることが好ましい。前記変換器はアクチュエータであることが好ましい。
【0091】
本発明のさらに別の態様によれば、複数のこのような玩具を含む組み合わせが提供される。
【0092】
前記複数の玩具の各々の1つが他の前記玩具を制御する手段を含むことにより、1つの玩具のみが他の前記玩具を同時に制御することが好ましい。
【0093】
前記メモリは、ゲームの状態に関連する情報を記憶するようになっていることが好ましい。ゲーム状態は、プレイボードのレイアウト、プレイボード上の少なくとも1つのカウンタの位置、玩具及び/又はユーザの全てに関するプレイの順序の少なくとも1つであってもよい。
【0094】
人形固有のダウンロード
本発明のさらに別の態様によれば、複数の玩具にテーマ別データを提供する装置が提供され、該装置は、各々が複数のサブテーマを含む前記テーマ別データを記憶する手段と、特定の玩具を識別する手段と、特定の玩具に基づいてサブテーマを選択する手段と、前記玩具に対して前記特定のサブテーマを出力する手段とを含む(この結果、テーマ別ダウンロードへのアクセスがより効率的に達成されることが好ましい)。
【0095】
玩具は、複数の異なるテーマを記憶する手段をさらに含むことが好ましい。
【0096】
玩具は、ユーザが複数のテーマのうちの1つを選択できるようにする手段をさらに含むことが好ましい。
【0097】
前記特定の玩具を特定する手段は、前記玩具の一意の識別番号を使用することが好ましい。
【0098】
玩具は、前記玩具に関連するパラメータに基づいて個々の前記サブテーマを暗号化する手段をさらに含むことが好ましい。前記パラメータは玩具の一意の識別番号であることが好ましい。
【0099】
装置は、プロセッサと、テーマ別データを記憶するとともに特定の玩具を識別する関連メモリとを含むことが好ましい。
【0100】
装置は、玩具にサブテーマを出力するための接続部をさらに含むことが好ましい。接続部は、インターネット及びUSBケーブルを含むことが好ましい。
【0101】
会話エンジン
本発明のさらに別の態様によれば、玩具などの装置のための会話エンジンが提供され、該会話エンジンは、会話のテーマを選択し、複数の起点から起点をランダムに選択し、変数に基づいて語句をランダムに選択し、変数に基づいて次の発話者をランダムに選択する手段を含む。
【0102】
前記語句選択はさらに、重み付けに基づくことが好ましい。
【0103】
玩具は、会話エンジンを組み込むことが好ましい。
【0104】
玩具又は会話エンジンは、ユーザから入力データを受信するようになっていることが好ましい。
【0105】
玩具又は会話エンジンは、ユーザにデータを出力するようになっていることが好ましい。
【0106】
会話エンジンはさらに、ユーザからの入力データをランダム選択処理の形で利用するようになっていることが好ましい。
【0107】
会話エンジンは、選択動作を実行するようになっているプロセッサを含むことが好ましい。
【0108】
玩具又は会話エンジンは、会話をリアルタイムに構築するようになっていることが好ましい。
【0109】
玩具又は会話エンジンは、会話を前処理するようになっていることが好ましい。玩具又は会話エンジンはさらに、前処理済みの会話を出力するようになっていることが好ましい。
【0110】
玩具又は会話エンジンは、会話を構築する際に、確立されたネットワーク内に存在する他の玩具のパラメータを変数として利用するようになっていることが好ましい。
【0111】
玩具又は会話エンジンは、重み付けに基づいてデータを出力するようになっていることが好ましい。
【0112】
玩具は、複数組のテーマ別データを記憶するようになっていることが好ましい。玩具はさらに、1つの会話中に複数組のテーマ別データのうちの少なくとも2つを利用するようになっていることが好ましい。
【0113】
玩具は、好ましくは2、3、4又はそれ以上の複数の他のこのような玩具とネットワークを確立できるようになっていることが好ましい。
【0114】
玩具は、生きているようになっていることが好ましい。
【0115】
玩具は、他のこのような玩具と通信するようになっており、前記通信は、発話、行動及びジェスチャを含むことが好ましい。
【0116】
玩具又は会話エンジンは、以下の特徴の1つ、いくつか、又は全てをいずれかの組合せで有することが好ましい。
・子供が玩具と対話式に遊ぶことができる
・オンザフライで構築される会話
・会話を開始する前に会話が前処理される
・会話がネットワーク内に存在する人形に基づく
・会話がネットワーク内に存在する人形の種類に基づく
・会話の長さ及び方向性の制御に使用される重み付け
・会話の半ばでテーマを切り替える能力
・2、3又はそれ以上の玩具
・玩具は生きているもの/人間/人形である
・対話は通信を含み、通信は広い意味で定められる
【0117】
要約すると、本発明は特に以下の発明に言及するものである。
・オーサリングツール〜玩具が読み込み可能なプログラムコードにコンパイルされる会話データを入力する機能を提供する。
・USB通信ドングル〜玩具とPCとの間の通信を可能にする装置を提供する。
・コントローラ人形〜3以上の人形であり、単一のコントローラとして最初に電源が入った人形を使用して制御が行われる。
・性格の表現〜人形の性格要素に基づいて、同じテーマが異なる表現を有する。
・テーマのスクリプト作成〜テーマは、ダウンロード可能な表現の組合せであり、スクリプト/スクリプト及び表現は、異なるテーマごとに不可欠な/異なるスクリプトである。
・パラメータ記憶〜現在の会話に関する情報を記憶する能力、例えば、「私の犬はFluffyと言います」という語句では、人形がその会話内の情報(ペット=「犬」及びペットの名前=「fluffy」)を後で使用するために記憶する。
・人形固有のダウンロード〜ウェブサイトダウンロードのみが、特定の性格に関する特定の言語を表現として有し、性格に従って表現がダウンロードされる。
・会話の構造〜人形は、関連する発話で応答するか、別の人形を選択して話しかけるか、或いは自分自身について何かを発表するかのいずれかを選択する。
・人形の選択〜コントローラは、次にどの人形が発話するかをランダムに決定し、ランダムに選択するものの、人形は2回続けて発話することができず、或いは特定の人形を名前で選択することもできない。
・ゲームのプレイ〜人形は人間のようにゲームをプレイする。
【0118】
本発明は、データ処理装置で実行された場合、構成要素の段階のいずれか又は全てを含む本明細書で説明する方法のいずれかを実行するようになっているコンピュータプログラム及びソフトウェアコードを含むコンピュータプログラム製品も提供する。
【0119】
本発明は、データ処理装置で実行された場合、本明細書で説明する装置の特徴のいずれかを含むコンピュータプログラム及びソフトウェアコードを含むコンピュータプログラム製品も提供する。
【0120】
本発明は、本明細書で説明する方法のいずれかを実行し及び/又は本明細書で説明する装置の特徴のいずれかを具体化するコンピュータプログラム及びコンピュータプログラムをサポートするオペレーティングシステムを有するコンピュータプログラム製品も提供する。
【0121】
本発明は、上述したようなコンピュータプログラムを記憶したコンピュータ可読媒体も提供する。
【0122】
本発明は、上述したようなコンピュータプログラムを保持する信号及びこのような信号を送信する方法も提供する。
【0123】
本発明は、実質的に添付図面を参照しながら本明細書で説明するような方法及び/又は装置にまで及ぶ。
【0124】
装置及び方法の特徴は適宜入れ替えることができ、また互いに独立して提供することができる。本発明の1つの態様におけるあらゆる特徴を、本発明の他の態様にあらゆる適当な組合せで適用することができ、同様に1つの本発明におけるあらゆる特徴を、本発明の他の態様にあらゆる適当な組合せで適用することができる。例えば、方法の態様を装置の態様に適用することができ、この逆もまた可能である。この場合も、例えば「コントローラ人形」のあらゆる特徴を「パラメータ記憶」のあらゆる特徴に適用することができる。
【0125】
さらに、ハードウェアで実行される特徴をソフトウェアで実行することができ、この逆もまた可能である。本明細書におけるソフトウェア及びハードウェアの特徴へのあらゆる言及については、以上に従って解釈すべきである。
【0126】
本明細書では、「〜する手段」に機能をプラスした用語の使用は、この機能を実行するようになっている適当なハードウェアコンポーネント(例えば、プロセッサ及び/又はメモリ)と置き換えることができる。
【0127】
以下、ほんの一例として、本発明の様々な実施形態について添付図面を参照しながら説明する。
【図面の簡単な説明】
【0128】
【図1】3種類の人形を示す図である。
【図2】人形の概略図である。
【図3】スレーブ玩具を含むコントローラ玩具の概略図である。
【図4】人形にテーマ/サブテーマをダウンロードできる、ウェブサイトに接続された人形の概略図である。
【図5】ゲームをプレイするようになっている人形の概略図である。
【図6】ゲームをプレイする処理のフロー図である。
【図7】代替実施形態の概略図である。
【図8】プロセッサ及び関連する電子機器の回路図の実施形態である。
【図9】プロセッサ及び関連する電子機器の回路図の代替実施形態である。
【図10】オーサリングツールサーバと通信しているユーザPCを示す図である。
【図11】オーサリングツール及び関連システムの概要を示す図である。
【図12a】会話デザイナーウィンドウを示す図である。
【図12b】テーマ生成ウィンドウを示す図である。
【図12c】データ入力したテーマ生成ウィンドウを示す図である。
【図13a】人形追加ウィンドウを示す図である。
【図13b】人形作成ウィンドウを示す図である。
【図14】人形コンテキストウィンドウを示す図である。
【図15】会話入力ウィンドウを示す図である。
【図16】複数の人形と通信しているUSBドングルを示す図である。
【発明を実施するための形態】
【0129】
図1は3種類の人形を示す図であり、10はテニスをしている人形、20はバレリーナ人形、30は犬の散歩中を示す一般的な人形、及び40は戦車の形をした玩具である。一般に、玩具は生きているように見えるようになっており、特に戦車などの場合は、人間のように又は人間が制御しているように見えるようになっている。図示の4つの玩具は、テーマ別玩具の種類の例である。玩具は、テーマ内の他のこのような玩具と無線で通信するようになっている。
【0130】
以下の説明は、他のこのような玩具と通信できるようにされた人形などの玩具に関するものであり、人形は、人形間で発話を調整するようになっている。別の実施形態では、玩具は戦車又は別のこのような車両であり、この場合も、人形間の発話の代わりに戦車が他のこのような戦車と無線で通信して戦車の挙動を調整するようになっている。
【0131】
図2は人形の概略図を示しており、人形が通信を行って他のこのようなタスクを実行できるようにするために必要なハードウェアコンポーネントを含む。図2に示すように、人形100は、無線モジュール104を含むプロセッサ102を含む。プロセッサは、メモリ106、ROM108及びRAM110と通信している。IR/RF送信機/受信機がプロセッサ/無線モジュールに接続され、他のこのような人形との間で信号を送信/受信できるようにされる。人形はスピーカ114にも接続される。USBコントローラ116を使用してメモリ106を更新し、充電器回路118を介して電池120の充電も行う。或いは、人形は、充電式電池ではなく交換式電池を使用するようにされる。
【0132】
メモリ106は、人形が行うことができる会話に関する情報を記憶し、プロセッサが発話をコンパイルしているときにプロセッサによりアクセスされる。ROM108を使用して、人形の名前及びID番号などの人形に関する恒久的情報を記憶する。この情報は、人形のネットワークを設定するときの初期化手順において使用される。RAM110は、現在の会話に関する情報を記憶し、例えばすでに使用された語句に関する情報を記憶することにより現実的な会話を作成するために使用される。
【0133】
個々の人形100は、メモリ106内に、人形の名前を含むデータセット及び会話中に定義されるその他の変数、会話を作成する命令セット、及び音声データセットを含む。会話中に定義される変数は、コントローラ人形にのみ記憶される。
【0134】
1つの実施形態では、プロセッサが、関連する(SDカードなどの)メモリインターフェイスを伴ってMP3復号で使用されるような形をとる。この実施形態は、かなりの量の処理能力(及びハードウェアベースの圧縮技術)を提供し、従って人形間の長く詳細な会話を可能にする。
【0135】
コントローラ人形
図3でわかるように、コントローラユニット200がいくつかのスレーブユニット(202)と通信している。コントローラは、会話エンジン204と、発話コンパイラ206と、発話データベース208と、スピーカ(変換器)210と、スレーブユニットからデータを送信及び受信できる送信機/受信機212とを含む。会話エンジンは、ランダム発話セレクタ214と、パラメータ記憶メモリ216と、発話者セレクタ218とを含む。スレーブユニットは、コントローラユニットの全ての構成要素を有しており、図3ではスレーブユニットの構成要素の全てを示しているわけではない。
【0136】
最初に電源が入るユニットがコントローラユニットとなるように初期化される。ユニットに電源が入ると、このユニットが既存のネットワークを検索し、ネットワークが存在しなければ、ネットワークを作成して他のユニットがネットワークに参加するのを待つ。さらなるユニットがオンになると、これらがネットワークに参加し、スレーブユニットとして初期化される。コントローラユニットは、両方の新しいユニットからの、ネットワークの詳細及び会話開始メッセージを求めることを示す通信を待つ。スレーブユニットは、ネットワークに参加すると、コントローラユニットからの命令を待つ。ユニット(玩具/人形)は、全てがコントローラユニットにも又はスレーブユニットにもなることができる限り全て同じものであることを理解されたい。
【0137】
ユニットは、「動物園」、「スポーツ」、「ギャングスタ」又は「ファッション」などのテーマ内で通信するようになっている。テーマにより、ユニットは、考えられる会話の話題全てに関する情報についての極めて大規模なデータベースを必要せずに詳細な会話を行えるようになる。ユーザは、テーマ/サブテーマをウェブサイトからユニットにダウンロードすることができる。
【0138】
以下のプロセスを使用して玩具のネットワークを開始する。
・人形がオンになったときに、参加する既存のネットワークが存在するかどうかを判定するためのチェックを行う〜これは送/受信機212を使用して遂行される。
・利用可能なネットワークが存在しない場合、この人形がコントローラになって自動的にネットワークを設定する〜必要な場合、無線モジュール104がネットワークを作成するようになっている。
・オンになった個々の後続の人形が、メモリに記憶した人形ID番号及びテーマ/複数のテーマID番号を送信する〜情報は送信機212により送信される。
・コントローラがテーマ/複数のテーマをチェックして、コントローラと同じ参加するテーマ/複数のテーマを有する人形のみを許可する〜コントローラユニットが、送信データとメモリに記憶されたデータとの比較を行う。
・2又はそれ以上の人形がネットワークに参加すると、会話を開始することが可能となる。
・ユーザがボタンを押すことなどにより会話を開始し、コントローラが、他の人形に何を発言すべきかを指示する会話を開始する。
・ユーザは、いつでも再びボタンを押して会話を停止することができる。
【0139】
コントローラユニットは会話を生成するプログラムを実行し、その後どのオーディオファイルにアクセスすべきかを知らせる情報をスレーブユニットへ送信する(このオーディオファイルは個々の性格型によって異なってもよいが、オーディオファイルの各々への参照はユニットごとに同じものである)。コントローラユニットは、スレーブユニットのメモリからアクセスするための単語/語句の識別子を送信する。スレーブユニットは、使用する語句及びこの語句を発言するのに要する予想される時間長を確認するメッセージを送信することにより、メッセージの受信についての確認応答を行う。次に、スレーブユニットは、会話コンパイラを使用して単語/語句をコンパイルし、その後スピーカを使用して語句を発言する。スレーブユニットは、語句を発言し終わると、文が終了し会話を続けることができる旨の信号をコントローラユニットへ送信する。
【0140】
その後、コントローラユニットが同じ方法で次の発話者に指示を行い、会話が終わるまでこれを継続する。会話構造に関するさらなる詳細を以下に示す。
【0141】
通信プロトコル
玩具は通信プロトコルを使用して通信し、メッセージのフォーマットは以下の通りである。
[MessageID,SendingToy_ID,ReceivingToy_ID,MessageType,Parameters]
【0142】
MessageIDとは、メッセージを識別する一意の番号のことである。制御玩具から送信される個々のメッセージは一意の識別番号を有する。
【0143】
SendingToy_IDは、メッセージを送信する玩具を示す。
【0144】
ReceivingToy_IDは、メッセージを受信する玩具を示す。
【0145】
MessageTypeは、START、STOP、SAYなどのメッセージの種類を示す。
【0146】
パラメータとは、メッセージタイプに関する他のあらゆる必要な情報のことである。SAYメッセージのみが、話される(単複の)語句を識別するパラメータを有する。
【0147】
従って、メッセージの範囲は以下を含む。
[MessageID,SendingToy_ID,ReceivingToy_ID,START]
[MessageID,SendingToy_ID,ReceivingToy_ID,STOP]
[MessageID,SendingToy_ID,ReceivingToy_ID,SAY,PhraseID]
【0148】
これらのメッセージの各々は、以下の形の確認応答を生成する。
[MessageID,SendingToy_ID,ReceivingToy_ID,Ack,Parameter]
【0149】
パラメータは、SAYメッセージへの確認応答のみに使用され、語句の持続時間を指定する。コントローラユニットは、語句パラメータの持続時間を使用して、次のメッセージを送信するまで適当な時間長の間待機する。
【0150】
従って、玩具1が玩具2と通信していると仮定した場合、各メッセージの通常のイベントのシーケンスは以下の通りになる。
[MessageID,1,2,START][MessageID,2,1,ACK]
[MessageID,1,2,SAY,PhraseID][MessageID,2,1,ACK,DURATION]
[MessageID,1,2,STOP][MessageID,2,1,ACK]
【0151】
STARTコマンドは、受信側玩具にさらなる到来メッセージの受信を予想するように指示する。次に、コントローラ人形が、スレーブ玩具が使用する必要がある語句のphraseIDを含む少なくとも1つのメッセージを送信する。個々のphraseIDがスレーブ玩具へ別個に送信され、従ってこの種の複数のメッセージを送信して文章全体を構築することができる。STOPコマンドを使用して、このシーケンスにこれ以上のメッセージが存在しない旨をスレーブ玩具に指示する。
【0152】
スレーブ玩具は、メッセージを受信すると、メッセージの受信を確認応答するメッセージをコントローラへ送信する。コントローラは、START及びSTOPの確認応答に対しては直ちに会話プログラムを続行するが、SAYコマンドについては、コントローラ人形は、SAYの確認応答に対応するDURATIONと等しい遅延後に続行する。確認応答が受信されない場合、確認応答が受信されるまでメッセージが再送される。この再送は何回も行われ、その時点で人形がリセットされて会話が停止し、例えば、メッセージは1000〜2000回、2000〜5000回、5000〜10,000回又はそれ以上再送される。
【0153】
個々の語句の最後には「語句終了フラグ」も添付されて、いつ語句が終わったかをスレーブユニットに通知する。この時点で、スレーブユニットは、発話が終了したことを示すメッセージをコントローラへ送信する。コントローラは、メッセージを受信すると次のユニットに発話するように指示するが、次の発話者はコントローラであっても、又は別のスレーブユニットであってもよい。
【0154】
コントローラ玩具が戦車である場合、発話を指示する代わりに、スレーブユニットに通信される命令は、スレーブユニット戦車が動くべきであるという指図の形をとる。従って、PhraseIDは、movementIDに置き換えられる。このようにして、コントローラ戦車が戦闘などのシミュレーションを行うことになる。玩具の戦車には、これらが協調して動くことができるように、ネットワーク内に他の玩具の戦車を位置決めする手段が設けられる。この手段は、玩具が通信している位置センサを有するプレイボード、又はカメラ、トランスポンダなどの他の位置決め手段の形をとることができる。
【0155】
会話の構築
会話エンジンは、会話をオンザフライで構築する。或いは、会話を開始する前に会話全体を構築してその後メモリに記憶し、その後事実上終了まで会話が実行される。しかしながら、いずれにしても、構築される会話は特定のランダム選択に基づくことになる。
【0156】
会話はネットワーク内に存在するユニットに基づき、従って存在するユニット数及び存在するユニットの種類が制御変数として使用される。玩具が人形である場合には「わーい動物園に来たよ、さあどうしよう」のように、個々の会話の最初の部分が固定される。しかしながら、複数の開始語句が存在する。その時点以降、会話はその後ランダムに選択されることになる。コントローラユニットは、発話する最初のユニットを選択し、その後開始語句のいずれかにランダムに分岐させる。
【0157】
システムは、以下のようないくつかの異なる種類のコマンドを含む命令セットを使用できるようにされる。
・変数の定義及び変数設定
・コンテキスト参照及びスイッチング
・条件付きフロー制御
・無条件フロー制御
・発話語句
【0158】
会話の流れを制御するために多くの命令文が定義され、これらは以下の通りである。
SELECT NEXT〜次の発話するユニットを選択する。この命令文には数多くの変形が存在し、これについて以下でさらに詳細に説明する。
SWITCH〜次のユニットに切り替える。
switch speaker〜発話者ポインタを別の発話者に移動させる。
switch finish〜この命令文を使用して会話を終える。
SAY〜ユニットに何かを発言するように指示する。
SET〜この命令文を使用して、「SET pet([1,dog])などの変数を設定する。SET文を使用して現在の発話者の変数を設定し、或いはこれを使用してグローバル変数を設定することができる。
TEST〜この命令文を使用して、例えば変数が設定されたかどうか、又は分岐が使用されたかどうかをテストする。TESTが真の場合、フラグが設定される。TEST命令文には2つの形がある。
TEST EQ〜この命令文は、2つの表現が等しいかどうかをテストして等しければ肯定的なフラグを作成し、例えば「TEST EQ&ME.PET&UNDEF」は、現在の発話者のペットの変数が未定義かどうかをテストして未定義であれば肯定的なフラグを作成する。
TEST NE〜この命令文は、2つの表現が等しいかどうかをテストして等しくなければ肯定的なフラグを作成する。
BRANCH〜この命令文を使用して別の会話のセクションに分岐する。例えば、「BRANCH gorillas:」は、「Gorillas」のラベルを付けられたテーマのセクションである、「Zoo(動物園)」というテーマのゴリラセクションに分岐する。この命令文は無条件文であり、プログラムが分岐文に至ったときには常に使用される。
BRANCH_F〜TESTからのフラグに基づいて条件付きで分岐する。従って、TEST文から作成されたフラグが肯定的であるときにのみ、分岐文が使用される。
CHOOSE〜この命令文により、コントローラが進む先のラベルをランダムに選択できるようになる。この命令文は、重み付けを使用してラベルへ進む確率を制御できるという点でSET文と類似している。
CHOOSE_F〜TESTからのフラグに基づいて条件付きで選択を行う。
【0159】
ストレージ要件を削減するために、オーディオファイルはトリミングした形で記憶され、すなわち個々の音声セグメントの前後には沈黙が存在しない。より実際的な発話を作成するために、トリミングしたオーディオファイルの後に置くことができる、長さの異なるいくつかの沈黙オーディオファイルが個々の語句又は単語の間に提供される。これらのオーディオファイルは、SAY文により他のオーディオファイルのいずれかと同様に参照される。
【0160】
SET文により変数を定義して人形の各々に関連するパラメータを記憶することができ、これについて以下でさらに詳細に説明する。定義できる変数には2つの形がある。
・ローカル変数〜これらは、個々の玩具/人形に関連する変数である。ローカル変数は、個々の人形のデータセット内で作成される。人形変数は、DEFINE VARIABLE_NAME文により作成される。
・グローバル変数〜これらは、「テーマ」に関連する変数であり、個々の人形とは関連性がない。グローバル変数は、DEFINE G_VARIABLE_NAME文により作成される。
【0161】
テーマ内で定義される変数は、会話中に値が割り当てられるまで、割り当てられた値を有していない。
【0162】
変数への値の設定
会話中、定義された変数に値を設定することが必要となる。これはSET文で遂行される。以下のように、SET文は、値のセットからランダムに取り出した値で変数を設定できるようにするランダム特徴で構成される。
SET VARIABLE_NAME([w1,value1],[w2,value2],..........,[wn,valuen])
【0163】
この命令文の動作は、VARIABLE_NAMEの値を乱数の結果に基づいてvalue1,value2,..........,valuenのうちの1つに設定することである。どの値が選択されるかの確率は、重み付けw1、w2、...、wnに基づく。
【0164】
例えば、
SET COLOUR([1,red],[1,blue],[1,green])
という命令文の場合、変数COLOURを等しい確率で赤色、青色又は緑色に設定することになる。人形の変数は、現在の人形との関連において設定される。
【0165】
また、TEST文がcondition_flagの状態を作成した場合に限り、SET_F文を使用して変数を設定する。この場合、condition_flagがアクティブな場合かつこの場合に限り変数が設定される。
【0166】
コンテキスト参照及び切り替え
ポインタを使用して発話者に関する情報を記憶するとともに、コントローラ人形が他の人形を参照できるようにする。会話を構築する場合、これらを使用して理にかなった会話を作成し、以下が使用するポインタである。
前の発話者(PREV)=前の発話者のID番号
現在の発話者(ME)=現在の玩具のID番号
次の発話者(NEXT)=選択された次の発話者のID番号
【0167】
人形の会話エンジンの重要な特徴は、どの人形が現在の発話者であるかというコンテキストである。このコンテキストは、現在の人形がアクセスした変数を参照する。前の人形、次の人形、現在の人形の変数のみがアクセスに利用可能である。上記で定義したように、コンテキストの概念は3つの参照ポインタにより処理される。
【0168】
コンテキストの制御は、SELECTコマンド及びSWITCHコマンドの使用により遂行される。SELECTコマンドのいくつかの変形が存在する。これらは以下の通りである。
・SELECT NOTME〜これは、ランダムに選択された人形のグループの現在の人形以外のいずれかとなるように次の発話者を選択する。
・SELECT NEXT〜これは、ランダムに選択された人形のグループのいずれかとなるように次の発話者を選択する。
・SELECT PREV〜これは、前の発話者と同じになるように次の発話者を選択する。
・SELECT NAME〜これは、名前NAMEを有する人形を次の発話者となるように選択する。このSELECTコマンドの変形は、台本通りの会話のためのものである。
【0169】
その後、コンテキストはSWITCHコマンドの使用により変更される。SWITCHコマンドには2つの変形が存在する。
・SWITCH SPEAKER label〜これは、発話者のコンテキスト及び分岐をラベルが指定する命令に切り替える。コンテキストを切り替えると、前の発話者(PREV)は現在の発話者(ME)に等しくなり、現在の発話者(ME)は次の発話者(NEXT)に等しくなり、次の発話者(NEXT)は未定義となる。
・SWITCH FINISH〜これは、会話を終了するために使用するコマンドである。
【0170】
条件付きフロー制御
時として、会話中、フローが様々な変数の値に左右される。これは、以下のコマンドで遂行される。
・TEST EQ value1 value2〜これは、value1がvalue2に等しい場合にcondition_flagを設定する。
・TEST NE value1 value2−これは、value1がvalue2に等しくない場合にconditionflagを設定する。
・&CONTEXT.VARIABLE_NAME参照を使用することにより、value1及び/又はvalue2によって変数を参照することができる。例えば、TEST EQ&ME.NAME&PREV.NAMEという命令は、現在の発話者(ME)の名前が前の発話者(PREV)の名前と同じ場合にcondition_flagを設定する。
・BRANCH_F label〜これは、condition_flagが設定されている場合にはラベルが指定する命令に分岐し、そうでない場合には次の命令を使用する。
・CHOOSE_F([w1,label1],[w2,label2],.........,[wn,labeln])〜これは、condition_flagが設定されている場合には重み付けw1,w2,...,wnを使用してランダム選択に基づいてlabel1,label2,...labelnが指定する命令に分岐し、そうでない場合には次の命令を使用する。
【0171】
人形が別の人形に関する変数の知識を必要とする度に、TEST文を使用して、変数が未定義であるか、又は特定の値であるかの問い合わせを行う。その後、これをフロー制御に使用することができ、例えば、PETという変数が未定義の場合、人形はどのような種類のペットを飼っているかを他の人形に尋ね、変数が設定されている場合にはペットが何色かなどを他の人形に尋ねる。
【0172】
無条件フロー制御
時として、命令のフローを無条件で変更できることが必要となる。この場合、TEST文は使用されずにBRANCH又はCHOOSE文が常に実行される。これは、以下の命令文を使用して遂行される。
・BRANCH label〜これは、ラベルが指定する命令に無条件で分岐する。
・CHOOSE([w1,label1][w2,label2][wn,labeln])〜これは、重み付けw1,w2,...,wnを使用してランダム選択に基づいてlabel1、label2、...、labelnが指定する命令に分岐する。
【0173】
発話語句
会話エンジンの重要な部分は語句の発話である。これは、以下の命令文で遂行される。
SAY(phrase1,phrase2,...,phrasen)コマンド。
このコマンドは、現在の発話者(ME)である人形に語句phrase1,phrase2,...,phrasenを発声させる。
【0174】
スクリプト例
以下は短いスクリプトの例である。
DEFINE COLOUR
DEFINE GARMENT
Loop:
SET COLOUR([1,red],[1,blue],[1,green])
SET GARMENT([1,dress],[1,blouse],[1,hat])
SAY(hello my name is, &ME.NAME, and I have a, &ME.COLOUR, &ME.GARMENT)
SELECT NOTME
SWITCH SPEAKER Loop
【0175】
この例では、3色のうちの1色を選んで3着の衣類のうちの1着に合わせることにより、存在する各人形ごとに9つの異なる事柄を発言することができる。
【0176】
会話は、多重分岐を使用して構築される。個々の分岐は、テーマに関する異なる会話の領域である。例えば、「Zoo(動物園)」というテーマでは、利用可能な分岐は「Gorillas(ゴリラ)」、「Reptiles(爬虫類)」及び「Ice cream(アイスクリーム)」である。個々の分岐はこれらに関連する語句/単語を有し、その後選択肢からランダムに選択される。人形の応答は、分岐、人形の性格型、及び考えられる応答の重み付けに依存する。
【0177】
例えば、選ぶべき次の分岐を決定することが選択に必要な場合、2体(又はそれ以上)の人形が同じ行く場所を続けて選択するまで会話が続く。これにより、選ぶべき分岐を選択する前に合意が必要となるので、より現実的な会話が行われる。
【0178】
コントローラ人形が別の選ぶべき分岐を選択できるセクションに達するまで分岐内で会話が続く。この時点で、選ぶべき分岐に関して別の決定が行われる。会話の長さを制限するために、使用されていなかった分岐のみを選択に利用することができる。
【0179】
分岐、語句、単語又は次の発話者などの、ランダムに選択できる個々の変数に重み付けが加えられる。語句/単語又は分岐などがランダムに選択される場合、これらの語句/単語の分岐などが選択される確率が重み付けにより変化する。例えば、全ての語句の重み付けが1の場合、これらは全て同じ選択される確率を有する。よりリアルな会話を作成するように重み付けを調整することができる。「今日、私は自転車から落ちた」などの語句は、「今朝、私は朝食を食べた」という語句よりも生じる可能性がはるかに低い。この結果、後者の語句は、前者よりもはるかに大きな重み付けを有するようになる。従って、会話エンジンの結果、ユニットはほんの時たましか「今日、私は自転車から落ちた」と言わないようになる。
【0180】
さらなる例では、使用する重み付けを前の人形に優先させることができ、従って2つの人形間のミニ会話を誘導することになる。
【0181】
会話の長さを制限するために、テーマの任意の1つの分岐の時間が制御される。これを別の重み付けパラメータとして使用して、例えば1つの分岐で費やされる時間を短縮し、別の分岐で費やされる時間を増やすことができる。これは、無限に続く可能性なく会話の最後に到達させるのに役立つ。
【0182】
会話の長さはランダムであってもよいが、場合によっては全ての変数が設定されるまで会話が続く。例えば、PETというテーマでは、全ての人形のペットが完全に説明されるまで会話が続く。これは、全ての変数が定義されているかどうかを判定するチェックを行うことにより遂行され、すべて定義済みである場合に限り会話を最後まで許可するものである。
【0183】
現在の発話者のみが前の発話者及び次の発話者というコンテキストを有するので、いつ全ての人形の変数が設定されたかを判定することがいつでも可能なわけではない。従って、別の例では、現在のコンテキストにおける3つの人形全て、すなわち、現在の人形、前の人形及び次の人形に関して全ての変数が設定されるまで会話が続く。或いは、続けて2又はそれ以上の組の人形に関して全ての変数が判明するまで会話が続く。
【0184】
会話エンジンは、複数の人形、及び2体のジェーンという人形などの同じ種類の潜在的に複数の人形に対処することができる。ネットワークが初期化された場合、ネットワークに参加する個々の人形にネットワークノードが関連付けられる。この結果、システムは、人形の名前ではなく関連するネットワークノードを使用して人形を参照する。これにより、同じ名前の複数の人形をエラーなく参照できるようになる。
【0185】
予め会話の全体を決定し、その後人形に直接ダウンロードすることもできる。例えば、シンプソン一家(登録商標)のエピソードをシンプソン一家(登録商標)の人形のグループにダウンロードすることができる。人間が会話を生成し、或いは会話エンジンが会話を生成して後から人間が編集できるので、会話を予め決定することにより、人形が特にリアルな会話を行えるようになる。予め決定される会話を作成する際には同じ命令が使用されるが、起動されるたびに会話が同じになるようにランダム要素は除去される。
【0186】
上記の会話エンジンを独立して使用して会話を生成することができる。例えば、漫画などのテレビ番組を書く自動スクリプトに上記の会話エンジンを使用することができる。
【0187】
1つの特定の実施形態では、テーマを生成するためにテーマをスクリプトで記述し、その後コンパイラを使用してスクリプトをコンパイルする。実行時エラーチェックを行って、テーマが終わりの無い会話又はその他のエラーを生成しないことを確実にし、その後サニティチェックを行って会話が全く無意味なものでないことを確実にする。その後、オーディオファイルが録音されると、テーマを玩具にダウンロードすることができる。以下でより詳細に説明する代替の実施形態では、テーマスクリプトの生成を容易にするオーサリングツールが提供される。しかしながら、依然としてテーマ内の会話の基本原理が適用される。例えば、両実施形態には、何を発言するかを選択する同じ方法が存在する。
【0188】
人形の選択
図3に示すように、会話エンジンは発話者セレクタ218を有する。発話者セレクタは、次の発話する玩具を選択する。次の発話する玩具を選択するには、ネットワーク内の玩具のいずれかをランダムに選択する、玩具を名前(ID番号)で選択する、及び現在の発話者を選択してもう一度発話させるという3つの可能性がある。従って、次の発話者を選択する第1のプロセスは、上記の3つの可能性のいずれを使用すべきかをランダムに選択することである。次の発話者を名前で選択する場合、その玩具がネットワーク内に存在するかどうかを判定するためのチェックを行う必要がある。
【0189】
上述したように、select文が次に誰が発話するかを選択する。次の発話者を決定する場合、選択肢としては、関連する発話で応答すること、別の人形を選択して話しかけること、或いは現在の発話者に関して何かを知らせることがある。
【0190】
発話者セレクタ218内でSELECT文を使用して、次の発話者のランダム選択を開始する。或いは、SELECT文が論理を使用して次の発話者への参照を決定することができる。例えば、発話するように選択された次の人形がジェーンである場合、現在の発話者が「ジェーン、あなたの好きなペットは何?」と尋ねることができる。ジェーンが次の発話者として設定されているので、ジェーンから回答が来ることになる。以下の例でわかるように、特定のパラメータが解らなくても&文を使用して次の発話者、又は他のいずれかの一般的パラメータを参照することができる。例えば、&NEXT.NAMEは次の発話者の変数NAMEを参照するものであるが、これを使用して次の発話者の名前を発言することができる。
【0191】
人形が続けて2回発話することはできないなどのさらなる選択肢が利用可能であり、従って、例えばジェーンが犬を飼っていると発表した場合、その直後にジェーンが発話するように選択されることはない。
【0192】
次の発話する人形を選択するために同様の方法がオーサリングツールにより利用され、これについて以下でさらに詳細に説明する。
【0193】
パラメータ記憶
パラメータ記憶メモリ216は、現在の会話に関する情報を記憶する。記憶された情報は、すでに使用された語句、使用された変数、フロー制御変数、及びネットワーク内に存在する人形などのその他のこのような情報を含む。情報は、コントローラ人形内にのみ記憶される。スレーブユニットは、次の発言事項に関する情報のみを受信する。
【0194】
会話において使用された変数は、後程会話内で参照できるように記憶される。変数は、人形を記述する情報であり、これを使用して性格を差別化する。
「私の犬はFluffyという」という語句から記憶される情報は、犬及びFluffyという情報である。この変数を使用して、人形が飼っているペットの種類を設定することができる。人形が特定の変数のサブセットのみを有することができるように変数を設定することができる。例えば、女の子の人形がヘビをペットとして有することはあり得ない。
【0195】
フロー制御変数を使用して、すでに使用された分岐に関する情報を記憶する。例えば、動物園にいる場合にはゴリラを見に行くように分岐を進めることができる。この情報を記憶して、会話が動物園に戻らないようにする。
【0196】
或いは、すでに使用された語句を記憶して、会話が永遠に続かないようにする。1回の会話内で特定の単語/語句を使用できる回数に限界値を設定することができ、この限界値は1回、2回、3回又はそれ以上であってもよい。これにより、会話が過度に反復的にならないことを確実にする。
【0197】
パラメータ記憶メモリ内に設定及び記憶できるグローバル変数も存在する。グローバル変数の例には、ネットワーク内の人形の全てに影響を与えるあらゆるものがあり、例えば「外は雨が降っている」であり、又は会話内で人形がずっと居た場所である。グローバル変数には、人形のコンテキストとは無関係にアクセスできるので、テーマ内のどの時点においてもこれを使用することができる。
【0198】
テーマ/人形に関する属性を記憶するために、パラメータもオーサリングツールを使用して定義され、これについて以下でさらに詳細に説明する。手短に言えば、テーマ属性/グローバル変数はテーマ全体に関連するパラメータを記憶し、あらゆる人形がいつでもこれにアクセスすることができ、人形属性/ローカル変数は個々の人形に関連するパラメータを記憶し、前の人形/現在の人形/次の人形のみがこれにアクセスすることができる。
【0199】
人形固有のダウンロード
図4は、人形がメモリに記憶されたテーマを変更又は更新できるプロセスの概略図である。人形300は、人形の識別に使用されるID番号302を含む。人形は、USB接続を介してPC304に接続され、PCは、標準的な接続方式を介してインターネット306に接続されている。インターネットは、ダウンロード可能なテーマ310を含むウェブサイト308にPCを接続することができる。テーマは、接続された人形によって変わるという理由で、ユーザが選択できないサブテーマ312を含む。例えば、人形のID番号を使用して識別されたジャックという人形にはジルのサブテーマは提示されない。テーマは、全ての性格型に対して一般的なものである。サブテーマは、テーマの表現が異なるとともに人形の性格型に依存する点を除き、メインテーマと同一である。従って、オーディオファイルは、異なる声、(同じ意味の)異なる言い回しなど、サブテーマごとに異なる。
【0200】
或いは、人形にダウンロードされる最初の性格を使用して、後からダウンロードされた性格を最初の種類と同じになるように制限することができる。例えば、人形がジャックと設定された場合、ウェブサイトは、この人形が接続されたときにジャックのサブテーマを認識し、ユーザにジャックのサブテーマのみを提示する。ウェブサイトは、人形の名前変数、すなわちジャックにアクセスしてこれをサブテーマの名前リストと比較することによりサブテーマを認識する。
【0201】
ダウンロードしたサブテーマは、「動物園」などの選択されたテーマのスクリプト、関連する性格型、人形が会話を発声できるようにする対応するオーディオファイル、及びネットワーク内の人形が全て同じテーマを有することを確実にするために使用されるテーマIDを含む。
【0202】
PC304は、テーマを効率的な態様でダウンロードできるように、人形300とウェブサイト310との間をインターフェイス接続するようになっている。さらに、テーマは人形にのみ記憶され、従ってテーマを必要とする個々の人形はウェブサイトに接続される必要がある。従って、1人のユーザが2つの人形を有し、個々の人形に同じテーマを求める場合、ユーザは個々の人形をウェブサイトに接続して適当なサブテーマをダウンロードする必要がある。
【0203】
これとは別に、人形は常に複数のテーマを記憶することができる。人形は、同時に1つのテーマを使用して通信するが、このテーマはコントローラによりいつでも変更することができる。従って、人形は「スポーツ」というテーマを使用して、その後「動物園」というテーマの使用に進むことができる。これにより、会話をより長く継続させることができ、人形の使い勝手を拡張するさらなる組み合わせが与えられる。
【0204】
人形は全て、他の人形と同じテーマを有していないときに手短に通信できるようにデフォルトテーマを有する。デフォルトテーマは2、3の基本的な語句を含み、ユーザをウェブサイトに接続してテーマをダウンロードするように導くことができる。
【0205】
テーマが安全であることを確実にするために、人形にダウンロードが行われる前に人形の一意のID番号を使用してデータを暗号化することができる。その後、個々の人形の一意のID番号を使用してテーマ内のデータを復号化することができる。これを使用して、全ての人形がウェブサイトに接続してテーマをダウンロードすることを確実にすることができる。例えば、個々のジェーンという人形が同じサブテーマを使用したいと思っても、データは特定の人形ごとに別様に符号化されており、従ってこの特定の人形以外にとっては事実上役に立たないものである。
【0206】
性格の表現及びテーマのスクリプト記述
前述したように、個々の異なるテーマは、異なる性格を表現できるようにする様々なサブテーマを有する。テーマごとのスクリプトは異なるものであり、これを使用してこのテーマに従う様々な会話を生成する。しかしながら、全てのテーマ内の個々のサブテーマは、会話を生成するための同じスクリプトを有するが、サブテーマ内で使用される言語は異なる。これにより、同じテーマに関して複数の性格を利用できるようにすることができる。
【0207】
会話の可変性を増加させるために、同じ質問を尋ねるための複数のランダム選択法が存在する。従って、例えば、単純な質問をする複数の方法が存在し、これは、例えば「次は何をしましょうか」、「次は何をするんだい」、「次は何ですか」のようにテーマ/サブテーマに依存するものであってもよい。個々のサブテーマは、同じ物事を意味するために使用する異なる表現を有することができる。例えば、1つのサブテーマでは「こんにちは、お元気ですか?」と言うことができ、別のテーマでは「やあ、調子はどうだい?」と言う。事実上語句の意味は同じものであるが、表現、従って性格が異なる。このようにして、変化に富んだ面白い会話を作成するために、各テーマがあらゆる数のサブテーマを有することができる。このようにして、ユーザ体験が高められるとともに大量のメモリを必要としないより多様なゲームプレイが可能となる。
【0208】
性格の特徴は、同一のテーマに起因することができる。従って、同じテーマのジャックバージョンとジルバージョンとを有することが可能である。ジャックバージョンはサブテーマであり、ジルバージョンもサブテーマである。
【0209】
人形の名前、すなわちジェーンが性格型と関連しているので、ジェーンという人形により表される性格は全てのテーマについて同じであり、テーマのコンテンツのみが変化する。これにより、人形は一定のままであることができ、異なる状況でも人形が同じ様に反応できるようになる。
【0210】
或いは、人形がウェブサイトにより最初に初期化されるときの人形の名前及び人形の性格を人形のユーザが選択することもできる。これにより、ユーザが人形との関わりをより深めることができる。このとき人形の名前及び性格型が人形内のメモリに記憶され、個々の属性がIDと関連付けられ、これが例えばさらなるサブテーマをダウンロードする際に使用される。
【0211】
ダウンロード可能なテーマは、表現とスクリプトとの組合せであり、会話の種類を決定付けるものである。
【0212】
人形の美的価値観(aesthetics)及び語彙を、ターゲットオーディエンスに応じた年齢となるようにカスタマイズすることもできる。様々なテーマは、年齢に応じた等級を有することができる。これにより、例えば10代の市場向けにはヒップホップをテーマにした人形が可能となる。
【0213】
さらに、別の人形セット(これは単一の人形であってもよい)のみが使用できる語句を提供することができる。この語句が選択された場合、現在の人形が使用できることを確実にするためのチェックが行われる。この人形がこの語句を使用できない場合には別の語句が選択される。
【0214】
同様に、命令の部分を別の人形セットのみに制限して、会話にさらなるランダム性を導入することができる。
【0215】
或いは、玩具が戦車又は他のこのような玩具の形をとる。この場合の玩具の性格の表現は、会話とは対照的に動きの形をとる。例えば、1つの玩具の戦車が「防御的」性格を有し、別の玩具の戦車が「攻撃的」性格を有することもできる。
【0216】
オーサリングツール
オーサリングツールとは、複数の人形に対して様々な会話テーマを作成するために使用できるアプリケーションのことである。上述したような会話は、会話が従うことができる可能性のある分岐が多数であるため、作成にかなりの量の時間が必要とされる。従って、プロセスをより効率化するために、オーサリングツールを提供してこのプロセスを支援する。クライアントアプリケーションは、図10に示すようなPC1000又はラップトップ1002などのパーソナルコンピュータなどで実行されるが、複数のユーザが同じテーマに取り組めるように、或いは単一のユーザが異なる場所から同じテーマに取り組めるように、データはサーバ1004上に記憶される。サーバ上では、データベースをクライアントアプリケーションとインターフェイス接続するためのウェブサービスが行われる。クライアントアプリケーションは、インターネット306を介してサーバ1004と通信する。クライアントアプリケーションはウェブサービス、ひいてはデータベースへの要求をXMLを使用してフォーマット化し、SOAPプロトコルを使用してデータを送信する。
【0217】
オーサリングツールの概要
図11は、オーサリングツールの概要を示す図である。テーマ開発者が玩具のために単純かつ効率的にテーマを出力できるようにするためにユーザインターフェイス1100が設けられる。設けられたユーザインターフェイスを使用して、開発者は以下のステップに従う。
1. テーマ生成エンジン1102を使用してテーマを作成
2. 玩具生成エンジン1104を使用してこのテーマに合わせた玩具を作成
3. コンテキスト入力ウィンドウ1106を使用して個々の玩具ごとに複数のコンテキストを作成
4. コード生成エンジン1108を使用して命令(「C」コード)を出力
5. 辞書生成エンジン1110を使用して個々の人形ごとに記録すべき語句の「辞書」を出力
6. 必要であれば、PCでテーマをテストする際に使用するシミュレーションエンジン1111を使用してシミュレーションとしてテーマを出力
【0218】
本明細書で使用する場合、用語コンテキストは、例えばテーマ別会話内の個々の位置ごとに、人形が何を発言するか、またどの人形が次に発話するかを決定する少なくとも1つのコンテキストが存在するように、テーマデータ内のコンテンツのサブセットを意味する。コンテキストは、テーマ/人形の属性を設定することもできる。
【0219】
コード生成エンジン及び辞書生成エンジン1110を使用して命令及び「辞書」がそれぞれ出力されると、記録手段を使用して語句が記録され、レコーダ1112を使用してオーディオファイルが作成され保存される。レコーダは、特定の作成中のテーマに必要な表現データの各々を生成するように関係者に促す。その後レコーダは、適当な表現データに対応するID番号を個々のオーディオファイルに割り当てる。使用時には、玩具のプロセッサが操作するコードにより、適当なID番号を使用してオーディオファイルが参照され、玩具のスピーカを使用して出力される。
【0220】
基本命令セット1114(玩具のプロセッサ用ファームウェア)が(コード生成エンジン1108により生成される)テーマ別命令セットと組み合わされ、テーマに従って玩具を動作させるために、コンパイラ1116を使用して玩具のプロセッサが使用するバイナリファイルにコンパイルされる。上述した先の実施形態では、基本の命令/ファームウェアのセットが玩具のプロセッサメモリに位置し、テーマが変更又は更新されるたびにテーマ別命令セット及びオーディオファイルのみが人形にダウンロードされた。
【0221】
命令がコンパイルされると、コンバイナエンジン1120を使用してこれらをオーディオファイルと共にバンドルし、個々の人形にダウンロードできるようにする(個々の人形は同じテーマ別命令を含む個別のダウンロードを有するが、これには個別のオーディオファイルが含まれる)。
【0222】
オーサリングツールは、テーマを記憶したサーバ1004及びデータベース1122へのアクセス権を有する。テーマは、テーマ開発者により確定されたかどうかに応じて異なるフォーマットで記憶される。未確定のテーマは、オーサリングツールが情報に容易にアクセスできるように記憶され、これは、テーマ名、玩具名、コンテキストなどの参照事項を含むデータベースの形をとる。テーマ開発者がテーマを確定させると、テーマは、未確定フォーマットに加え上述したような命令セットとしても記憶される。これにより、確定したテーマを修正するとともに、先に確定したテーマに基づいて新しいテーマを作成できるようになる。玩具のユーザが自分の玩具/人形1126にテーマ別データをダウンロードできるようにするウェブサイト1124が提供される。
【0223】
オーサリングツールは、上述したようなものを含むいくつかの機能を有する。
1)これを使用して、テーマ生成エンジン1102を使用して複数の人形のためのテーマ別会話を作成及び編集することができる。
2)これを使用して、シミュレーションエンジン1111を使用して会話プロセスをシミュレートし、結果として得られるテーマ別会話のテキスト出力を作成することができる。
3)これを使用して、辞書生成エンジン1110を使用して個々の人形に関する記録すべき全ての語句のリストをまとめることができる。
4)これを使用して、コード生成エンジン1108を用いて「C」コード出力(命令セット)を作成することができ、その後これをコンパイルして修正済みプロセッサファームウェアとリンクさせ、ダウンロードの準備が整っている個々の人形のためにバイナリデータファイルを作成することができる。
【0224】
会話データの入力
オーサリングツールのアプリケーションユーザインターフェイスを図12a〜図15に示す。個々のインターフェイスのウィンドウは、入力ウィンドウとインターフェイス接続するか、或いは次のインターフェイスウィンドウへ進むかのいずれかを行うための数多くのナビゲーションボタンを有する。ユーザインターフェイスは、プロセッサ1150及び関連メモリ1152を利用してテーマ開発者にユーザインターフェイスの様々な態様を表示し、受信機1153を利用してユーザが入力したコンテンツを受信する。プロセッサ1150及びメモリ1152は、PC1000又はラップトップ1002内に位置する。本明細書で使用する場合、用語コンテンツは、スクリプトデータ、表現データ、テーマデータ、人形データ及びユーザがオーサリングツールに入力できる他のあらゆるデータ型を意味する。
【0225】
図12aは、第1のインターフェイスウィンドウであり、以下の選択肢を有する。
テーマの追加(1100):これは新しいテーマを作成するために使用され、通常は使用される最初の選択肢である。図12b及び12cに示すように、以下の入力を必要とするテーマフォームを立ち上げる。
名前:テーマの名前。これは、spoken_text_stringのためのプレースホルダである。
人形の数:このテーマ内でサポートされる人形の総数
説明:テーマの説明
テーマ属性:位置などの、テーマのグローバル属性
人形属性:気分などの、人形のローカル属性
【0226】
これらの入力は、上述したような会話の構築で必要とされる入力と同等のものである。オーサリングツールの実施形態を参照しながら説明したように、テーマ及び人形属性は、上述のようにそれぞれグローバル変数及びローカル変数と同等のものである。しかしながら、オーサリングツールは、構造化された様々な入力ウィンドウをテーマ開発者に提供して情報を効率よく入力できるようにする。
【0227】
さらに詳細には、テーマ属性は、名前及び任意に値から成る。値は、spoken_text_stringのためのプレースホルダであってもよい。以下で説明するように、spoker_text_stringは、テーマが確定した後に作成される。spoken_text_stringとは、会話中にアクセスできるサウンドファイルのことである。例えば、テーマが動物園内に位置するとした場合、考えられるテーマ属性は、位置=「動物園」であり、人形がこれを使用して、例えば「やあ、動物園は本当に楽しいな」と言うことができ、この場合「動物園」という単語は、「位置」というテーマ属性を使用してアクセスされたものである。
【0228】
人形属性は、特定のテーマにおける個々の人形が属性に値を必要とするときにインターフェイスウィンドウ内に作成される。例えば、属性の設定が「気分」である場合、個々の人形のこの属性に「楽しい」「悲しい」、「怒っている」などの値が与えられる。会話中、会話エンジンは、人形属性(ローカル変数)のいずれかにアクセスしてその属性を会話で使用することができる。
編集(1202):これは既存のテーマを編集するために使用される。例えば、テーマAlon#1(1206)を選択して編集を押すことにより、ユーザがAlon#1のテーマの詳細を編集できるようになる。
除去(1204):これは選択したテーマを削除するために使用される。
【0229】
図12aは、3つのテーマ1208、1208及び1210が作成された後のウィンドウを示している。個々のテーマがテーマの詳細の概要を示しており、これにはテーマの短い説明、テーマに関連する人形の数及びそのID番号が含まれていることがわかる。テーマのフォームに入力された情報は、その後出力命令を生成する際に検索するためにサーバ1004内のデータベース1122に記憶される。
【0230】
テーマが作成されると、ユーザは次のウィンドウへ進んでテーマ内の人形を作成する。図13aは人形生成ウィンドウを示しており、ユーザが「人形追加」ボタン1300を押すと、図13bに示すウィンドウが表示される。このウィンドウを使用することにより、人形を作成し、名前をつけ、短い説明を付けることができるようになる。
【0231】
図13a及び図13bに示すウィンドウを使用して、必要なだけの人形を作成することができる。しかしながら、作成できる人形の数は、その特定のテーマに関して前もって決定した人形の最大数により制限される。これらの同じウィンドウを使用して既存の人形を編集することも可能である。このようにして個々の人形を作成することによりサブテーマが生成される。上述したように、サブテーマは個々の特定の人形のテーマである。例えば、会話を記録するために使用する音声は玩具ごとに異なり、コンテキストデータも異なる。この場合も、人形のフォームに入力された情報が、その後出力命令を生成する際に検索するためにサーバ1004内のデータベース1122に記憶される。
【0232】
図14は、テーマ内の個々の人形に対して異なるコンテキストを入力するコンテキスト定義ウィンドウを示している。図14に示すように、位置100に2つのコンテキスト1400及び1402が定義されており、1つはDoll#1のためのものであり、1つはDoll#2のためのものである。従って、会話内で位置100がアクセスを受けた場合、上述したような方法により人形が選択され、対応するコンテキストがアクセスを受ける。個々のコンテキストは、人形が何を発言すべきか、及び次にどの人形が発話すべきかに関する情報を保持する。この結果、会話を作成するための構造をテーマ開発者に提供することにより、上述したような会話構築のプロセスが容易化される。テーマ開発者は、もはやテーマ自体をコード化する必要はなく、むしろオーサリングツールが、テーマ開発者の入力に応じて必要なコードを生成する。
【0233】
図15は、テーマ内の個々の位置のためのコンテキスト生成ウィンドウを示す。図15に示す例では、これは位置100及びDoll#1のためのコンテキストである。個々のコンテキストは以下の情報を必要とする。
・Position(1500)〜図14に示すコンテキスト定義ウィンドウ内で新しいコンテキストが作成される際にオーサリングツールにより自動的に作成されるこの位置を表記するテキスト文字列。これは個々のコンテキスト行にとって便利なラベルである。これはいずれのテキストであってもよいが、デフォルトはコンテキスト行に100から始めて順に番号を付ける。テキストラベルの使用目的は、会話を作成及び編集している間に明暸さを助長することである。「C」コードの出力が必要な場合、全ての位置ラベルが、コンテキスト位置に対応するyoume_conversation_struct_t構造(この及び本明細書で説明するその他の構造に利用されるCコード命名規則)の配列の形のインデックスに変換される。
・Statement(1502)〜人形が発言できる文のリストであり、ランダム選択プロセスで使用する重み付けを伴う。文は、spoken_text_stringsである語句のリストを含む。これは、会話内のこのコンテキストポイントにおいて特定の人形が発言できる文のリストである。個々の文は角括弧で囲まれ、個々の文をコンマで分離し(例えば[statement1],[statement2],[statement3])、又は図15に示すようにコンテキスト入力ウィンドウの別々の行に入力することができる。文は、ランダム選択用の重み付け及び語句のリストから成る。この場合の重み付けは、SET制御、BRANCH制御又はCHOOSE制御などの条件付きフロー制御を参照しながら上述したような重み付けと同様の態様で機能する。個々の語句は、明示的なspoken_text_string、又はテーマ属性又は人形属性への参照のいずれかであり、例えば、文はテーマの位置又は人形の気分を参照することができる。明示的spoken_text_stringsは、(「こんにちは、お元気ですか」などの)2重引用符内のテキストとして定義される。参照は以下の形を取る
○ theme.attribute テーマ/グローバル属性に関する
○ me.attribute 現在の発話者人形属性に関する
○ prev.attribute 前の発話者人形属性に関する
○ next.attribute 次の発話者人形属性に関する
○ name.attribute 名前の付いた人形/ローカル属性に関する
以下は、Statementsフィールドへの有効な入力例である。
○ ブランク〜これは、この時点でこの人形による発言が存在しないことを意味する。
○ [1,“hello how are you”]〜この時点で「今日は、お元気ですか」と特定された1つの文のみがこの人形により話される。
○ [1,“hello”,prev.name、how are you]〜この時点で「今日は」の次に前の発話者名、その後「お元気ですか」がこの人形により話される。
○ [1,“hello”][1,“hi”]〜等しい重み付けの2つの文。default_say_procedureが使用された場合、この時点で50%の時間は「今日は」がこの人形により発言され、残りの50%の時間は「やあ」が発言される。
○ [3,“hello”][1,“howdy”]−等しくない重み付けの2つの文。default_say_procedureが使用された場合、この時点で75%の時間は「今日は」がこの人形により発言され、残りの25%の時間は「よう」が発言される。
・Say(1504)〜発言するために使用される手順。ブランクにした場合、default_say_procedureが使用される。default_say_procedureは、重み付けを使用して利用可能な文の1つをランダムに選択する。或いは、ドロップダウンリストを使用して、異なる言動を提供するあらゆる利用可能な用意されたsay手順を選択することができる。ドロップダウンリスト内に上述したようなsay手順を提供することができる。最終的に、特別な動作が必要な場合、必要なsay手順の「C」コードをここに入力することができる。
・Transition(1506)〜次の人形を選択するために使用される手順。NOTME、ANY、ME、PREV、FINISHを含む上述の手順のいずれであってもよく、或いは人形の名前の1つ又は何らかの「C」コードをここに入力することができる。ブランクにした場合、NOTME transitionであるdefault_transition_procedureが使用される。これとは別に、利用可能なtransition手順のプルダウンリストが存在する。このリストは、以下の用意されたtransitionで構成され、(各々について詳細に上述したような)ドロップダウンメニューを介してオーサリングツール内でアクセスされる。
○ NOTME 現在の発話者を除くいずれかの人形をランダムに選択する。
○ ANY いずれかの人形をランダムに選択する。
○ ME 現在の発話者を選択する。
○ PREV 前の発話者を選択する。
○ Doll’s name この人形を選択する。
また、特別なtransition動作が必要な場合、必要なtransition手順の「C」コードをここに入力することができる。
・Next(1508)〜ランダム選択プロセスにおいて使用される次にどこへ行くかについての分岐選択のリストであり、重み付けを伴う。これは、次のコンテキスト位置のための分岐選択のリストである。個々の分岐選択は角括弧で囲まれ、コンマで区切られる。分岐選択自体は位置ラベルのリストから成り、ランダム選択のための重み付けを伴う。上述したようなBRANCHコマンドとフォーマットが類似する。以下は、(各々について詳細に上述したような)このフィールドへの有効な入力例である。
○ [(1,label1),(1,label2)]〜等しい重み付けの2つのラベルの選択を含む1つの分岐選択。
○ [(1,label1),(1,label2)]![(2,label3),(3,label4)]〜2つの分岐選択、最初の方は等しい重み付けの2つのラベルの選択を含み、後の方は重み付け2及び3の2つのラベルの選択を含む。
・Branch(1510)〜分岐に影響を与えるために使用される手順、フォーマットは、会話構造を参照しながら上述したものと同じである。そうでなければ、何らかの「C」コードをここに入力することができる。このフィールドは、分岐手順を指定して分岐選択を処理するために使用される。ブランクにした場合、default_branch_procedureが使用される。default_branch_procedureは、Nextリスト内の最初の分岐選択を使用し、与えられた重み付けを使用してラベルの1つをランダムに選択する。その後、コンテキストは、その位置ラベルとして選択されたラベルを有するコンテキスト行に変更される。これとは別に、利用可能な用意された分岐手順のプルダウンリストが存在する。このドロップダウンリスト内に上述したような分岐手順を提供することができる。
・Attributes(1512)〜属性、seMlag、及びランダム選択のための値及び重み付けのリスト。このフィールドは、このコンテキストポイントにおいて値で設定を行うためのいずれかの属性を指定するために使用され、すなわちテーマ開発者は、「気分」という人形属性をハッピーに設定することができる。ブランクにした場合、属性は設定されない。設定される個々の属性は、角括弧で囲まれ、コンマで区切られる。角括弧内では、属性が指定された後に、属性を一旦設定すべきか、又はリセットすることができるかを指定するset_flagが続き、その後ランダム選択のための値及び重み付けのリストが続く。属性フィールドは、上述したようなSETコマンドの同等物である。以下は、属性フィールドへの有効な入力である。
○ ブランク 属性は設定されない。
○ [me.attribute1,set,(1,“hello”)] 1つの属性が設定され、未だ設定されていない場合、spoken_text_string“hello”の値に「ハロー」が設定される。
○ [me.attribute1,reset,(1,“hello”)(1,“hi”)],[me.attribute2,set,(1,“peter”)(1,“paul”)]
2つの属性が設定される。最初の属性は、すでに設定されていたとしても「ハロー」又は「ハイ」に設定される。次の属性は、未だ設定されていていない場合に「ピーター」又は「ポール」に設定される。
・Set(1514)〜属性値の設定に影響を与えるために使用される手順。ブランクにした場合、default_set_procedureが使用される。default_set_procedureは、set_flagを考慮して個々の指定された属性を適当な値の選択に設定する。「set」のset_flagは、まだ設定されていない場合に限り属性を設定できることを意味する。「reset」のset_flagは、属性を何度でもリセットできることを意味する。これとは別に、利用可能な用意されたset手順のプルダウンリストが存在する。最終的に、何らかの特別なカスタム設定した動作が必要な場合、必要なset手順の「C」コードをここに入力することができる。
【0234】
上述したように、Statements、Say、Transition、Next、Branch、Attributes、及びSetのフィールドが個々の人形ごとに反復される。Say、Transition、Next及びBranchのフィールドは全て、玩具/人形間の対話方法に寄与するパラメータであり、これらの全ては会話構造を参照しながら上述したようなコマンドと同等である。
【0235】
会話が完了するまで、Contextオプションを繰り返し使用して、会話にコンテキスト行を追加する。
【0236】
個々の人形及び個々のコンテキストの定義を含め、テーマが完了すると、オーサリングツールはセーブ機能を提供する。このオプションは会話を保存するために使用され、一例として以下のディレクトリを作成する。
c:\youme\themes\theme_name
c:\youme\themes\theme_name\doll_name〜個々の人形ごと
c:\youme\themes\theme_name\doll_name\audio〜個々の人形ごと
【0237】
従って、1つのテーマに必要なファイルは、全てマスターディレクトリフォルダ「theme_name」内に保存される。個々の人形ごとにサブフォルダを作成して、個々の人形のダウンロードを効率的に管理できるようにする。最終的に、個々の人形のサブフォルダは、この人形に必要なオーディオファイルを記憶するためのフォルダを有する。
【0238】
このオプションは以下のファイルも作成する。
c:\youme\themes\theme_name\theme.txt〜テキストファイルとしてテーマデータを含む。
c:\youme\themes\theme_name\doll_name\doll.txt〜テキストファイルとして人形データを含む。
c:\youme\themes\theme_name\doll_name\audio\A00001.wav
c:\youme\themes\theme_name\doll_name\audio\A00002.wav
...
...
...
c:\youme\themes\theme_name\doll_name\audio\A00010.wav
...
...
c:\youme\themes\theme_name\doll_name\audio\Annnnn.wav
【0239】
作成されるwavファイルは、個々の人形ごとにテーマ内で定義されるspoken_text_stringsの各々のプレースホルダである。spoken_text_stringsには、A00001.wavから開始する順番でA0000n.wavというファイル名が割り当てられる。ファイル名の中で使用されるnは、「C」コードの出力が必要な場合の語句のインデックスとしても使用される。1つの例では、レコーダ(1112)が、必要なspoken_text_stringを上演させるように関係者を促し、その後、次のspoken_text_stringで関係者を促す前に正しいファイル名でファイルを自動的に保存する。
【0240】
また、オーサリングツールは、会話に対応する「C」コードを生成するようになっている。「C」コードの大部分は予め定義され(基本命令セット)、玩具/人形のプロセッサのためのオペレーティングシステムとして機能する。会話に対応する「C」コード(テーマ別命令セット)が出力されると、予め定義された「C」コードと組み合わされ(図11を参照)、その後これがコンパイルされて人形又はPC内のプロセッサを操作するのに適したバイナリファイルが作成される。新しいテーマが作成されるたびに人形にオペレーティングシステム/ファームウェアを組み込むことにより、必要なときにいつでも人形の機能を単純かつ効率的に変更できるようになる。
【0241】
2種類の「C」コードを出力することができる。
1.ウィンドウ用「C」コード〜この「C」コードは以下の形で保存することができる。
c:\youme\themes\theme_name\theme_simulation.c、及び
c:\youme\themes\theme_name\theme_simulation.h
後でこのコードをコンパイルしてウィンドウベースの会話シミュレーションエンジンとリンクさせることができる。結果的に得られるアプリケーションを、c:\youme\themes\theme_name\simulation.exeの形で保存することができる。シミュレータにより、ユーザがどの人形を現在の及びアクティブな人形と考えるべきかを指定できるようになる。その後、シミュレータは、実際の人形で行われそうな形で会話例をシミュレートする。シミュレータは、アクティブな人形の1つを現在の発話者となるようにランダムに選択し、この人形の最初のコンテキスト行を処理する。その後、個々の新しい行を順に実行して、どの人形が発話しているか、及びこれらが何を発言しているかを出力する。シミュレータは、会話が終わるまで継続する。
2.プロセッサ用「C」コード〜後でこのコードをコンパイルし、修正済みのプレイヤとリンクさせて個々の人形ごとのバイナリデータファイルを生成することができる。これらの「C」コードファイルは、個々の人形ごとに以下の形で保存することができる。
c:\youme\themes\theme_name\dollname\youme_chat.c、及び、
c:\youme\themes\theme_name\dollname\youme_chat.h
結果的に得られるバイナリデータファイルを以下の形で保存することができる。
:c:\youme\themes\theme_name\doll_name\player.sb.
【0242】
バイナリデータファイルは、個々の人形において会話を実行するために必要な情報セット全体を含む。このバイナリデータファイルはプロセッサ用ファームウェアを含むので、ファームウェアを更新する追加のプロセスを必要とせずに、人形の機能に追加の特徴を組み入れることができる。
【0243】
人形用のwavファイルとして正しい語句を記録するために、図11に示すように、個々の人形ごとに全ての異なる語句(spoken_text_strings)のリストを作成し、辞書生成エンジン1110を使用して出力し、これが個々の人形にとって必要な語句の辞書となる。辞書生成エンジン1110は、サーバ1004内のデータベース1122と通信し、データベース内に記憶されたテーマに関する情報に基づいてリストをコンパイルする。この辞書は、事実上、表現/文と、この表現/文に割り当てられたID番号との間のルックアップテーブルである。
【0244】
個々の人形が使用する語句は、個々のコンテキスト行のStatementsフィールド及びAttributesフィールド内で定義される。これらは明示的に定義されたspoken_text_stringsであってもよく、或いはカスタム属性への参照であってもよい。明示的なspoken_text_stringが定義されるときには常に、A00001.wavから開始する順番のA00xxx.wavなどのファイル名がこれに割り当てられる。番号xxxもまた語句のインデックスである。spoken_text_stringsのリストは以下のファイル内に保存することができる。
c:\youme\themes\theme_name\phrases.txt〜これは、このテーマで使用される全ての語句のリストを含む。
c:\youme\themes\theme_name\doll_name\phrases.txt〜これらは、個々の人形が使用する全ての語句のリストを含む。
【0245】
これらのファイルは、以下のフォーマットのテキストを含む。
A00xxx テキストとしての関連語句
【0246】
このようにして、語句のリストを順番に記録し、適当なファイル名で保存し、人形内で使用するための、或いはPCが仮想人形として機能する場合にはPC内で使用するためのダウンロードに向けて準備することができるので、数多くのwavファイルを作成するプロセスが単純化される。
【0247】
図12aに示すように、ファイルを生成するプロセスは、ボタン1212「ファイルの生成」により起動される。ユーザは、完了している適当なテーマを選択してボタン1212を押す。これにより、上述したようなファイルが生成される。その後、ファイルのバンドル全体が人形にアップロードされ、このバンドルは、テーマ及び付随するオペレーティングシステムのバイナリファイル、発話のためのサウンド(wav)ファイル及びプロセッサ動作コード(ファームウェア)を含む。
【0248】
上述したように、youme_conversation_struct_tという会話構造の配列が会話の主な制御データである。概略的には、コントローラ人形において会話が操作される場合、最初の人形に関するこの配列のインデックス1により指定されたコンテキストにおいて会話エンジンが起動する。その後、以下の行動を行う。
1.現在のコンテキストのtransition手順を呼び出して、どの人形が次になるかを決定する。
2.現在のコンテキストのset手順を呼び出して、コンテキスト内で指定されたあらゆる属性の値を設定する。
3.現在のコンテキストのsay手順を呼び出して、コンテキスト内に指定されたデータに従ってどの文を発言すべきかを選択する。この結果、現在の人形がコントローラ人形でない場合、遠隔の人形との無線通信が行われる。いずれにせよ、エンジンは手順の前にオーディオ出力が完了するまで待機する。
4.コンテキストのbranch手順を呼び出して、次のインデックスを選択し、使用する会話配列に入れる。
5.前の人形ポインタ(prev)を現在の人形ポインタ(me)と同等に設定する。
6. 現在の人形ポインタ(me)を次の人形ポインタ(next)と同等に設定する。次の人形ポインタは、ステップ1において設定済みである。
7.その後、新しいインデックス及び新しい人形で再びステップ1から開始し、ステップ4の1つにおいてFINISH分岐にぶつかるまでこのプロセスを継続する。
【0249】
USB通信ドングル
さらなる実施形態では、PCが本明細書で説明するような玩具と無線で対話できるようにするUSB通信ドングルが提供される。図16は、PC304に取り付けられ、人形100と無線通信しているUSB通信ドングル1600の概略図である。ドングルは、無線モジュール104と、IR/RF送/受信機212と、インターフェイス1602とを含む。これらの構成要素は、インターフェイス1602を除き、上述したような人形100内に含まれるものと同じものである。しかしながら、PC304は、人形100が有するような独立したプロセッサを有するドングルの代わりにプロセッサ1604として利用され、従って事実上、PCが物理的人形100と通信できる仮想人形になる。仮想人形には、現実の人形と同様の外観を有することができる、PCのモニタに表示されるアニメ化したアバターが提供され、これによりアバターのアニメーションが人形の発話と同期化される。会話を実行するために、PCは、玩具のプロセッサをエミュレートするためのエミュレータをメモリ1606内に記憶している。或いは、上述したように、オーサリングツールがPCベースの仮想人形の特定のコードを出力する。いずれにせよ、テーマ別会話データを使用し、玩具/人形のファームウェアをエミュレートするPC上で実行されるアプリケーションを使用して会話が実行される。玩具/人形の発話は、PCのスピーカを介して出力される。
【0250】
インターフェイス1602はUSB接続であり、無線通信ドングル1600をPC304に接続するための効率的な方法を提供する。ドングルが使用する無線通信プロトコルは、本明細書で説明するような人形間で使用されるものと同じものであり、すなわちIEEE802.15.4.である。
【0251】
ユーザは、ウェブサイトに接続すると、USB通信ドングルを使用して物理的人形とウェブサイト内でアニメ化された仮想人形との間の会話を容易化することができる。このようにして、1人のユーザが、複数の物理的人形を必要とせずに人形の会話エンジンの機能を使用することができる。また、仮想人形は、複数の物理的人形との会話に参加することができる。2人のユーザが各々USB通信ドングルを取り付けたラップトップコンピュータを有する場合、仮想人形が他の仮想人形と対話することもできる。
【0252】
ゲームのプレイ
さらなる実施形態では、玩具が子供とゲームをプレイするようにもなっている。例えば、ヘビとはしご、ネズミ取り、ルード又はサイコロを使用してプレイすることができる他のあらゆる偶然に基づくゲームなどのボードゲームを玩具がプレイすることができる。
【0253】
玩具には、サイコロをシミュレートするために使用される乱数発生器が設けられる。さらに、玩具は、駒がボードに沿って進むことができるスペースの数を計数するようになっている。玩具は、駒を必要なスペースの数だけ移動させるように音で子供に合図する。子供が駒を移動させると、子供はボタンなどを押すことにより、次の玩具/子供の番であることを玩具に示す。或いは、ボードは対話型でもあり、プレイボードからカウンタの位置に関する情報を受信するセンサなどを含む。プレイは、勝者が出るまでこのように進行する。
【0254】
図5は、ゲームエンジン400をさらに含むコントローラ玩具200の概略図である。残りの構成要素は、図2及び図3で説明したものと同じである。ゲームエンジン400は、ボードメモリ402と、乱数発生器404と、位置RAM406と、確認応答受信機408とを含む。
【0255】
ボードメモリ402は、ヘビとはしご又はルードなどのボードゲームのレイアウトに関する情報を記憶する。乱数発生器は、サイコロをシミュレートするために使用され、数字1、2、3、4、5及び6(又は、ゲームに適した他のいずれかの数字セット)を生成するようになっている。位置RAMは、この場合はコントローラ及び3つのスレーブであるが、プレイヤの各々のボード上の位置に関する情報を記憶するために使用される。ボードメモリ及び仮想サイコロの転がりとともにこの情報を使用して、駒が移動するのに適した位置の数を計数し、駒が移動するスクウェアにはしごの底部又はヘビの頭部などの何らかの特別な関連性があるかどうかを識別する。
【0256】
会話エンジン204は、ゲームエンジンから得られる情報を利用してスペースの数を計数し、例えば最初の位置がスクウェア13であり、仮想サイコロを転がして4が出た場合、人形が「4が出て、14、15、16、17と移動したよ」)とスピーカ210を介して発声する。この例では、スクウェア17がヘビの頭部とした場合、人形は「あらら、スクウェア6までヘビを滑り落ちてしまった」と発声するであろう。計数メカニズムは、テキストを適当な回数循環し、そこで位置RAM406内の最終位置を思い出す。従って、例えば仮想サイコロを転がして4が出た場合、数字のリストに4回アクセスして最終結果を出す。
【0257】
また、人形は、子供が起動する外部乱数発生器から情報を受信することもできる。このようにして、子供が人形と一緒に遊ぶことができ、人形は、子供を含むプレイヤの駒の全ての経過を追っていつ勝者が出たかを判定することができる。
【0258】
図6は、ゲームをプレイするプロセスのフロー図である。ゲームはユーザにより開始され(ステップ500)、コントローラ人形がプレイヤの数を判定するためのチェックを行う(ステップ502)。次に、コントローラ人形が乱数発生器などを使用して最初のプレイヤを決める(ステップ504)。次に、コントローラ人形が最初のプレイヤのために仮想サイコロを転がし(ステップ506)、或いは子供が最初のプレイヤの場合には、コントローラ人形が子供にサイコロを転がすように求める。次に、コントローラ人形は、プレイヤにカウンタ/駒をボード上の対応するスクウェアの数だけ移動させるように指示し(ステップ508)、その後子供がカウンタを移動させたという確認応答を待つ(ステップ510)。ステップ512において、コントローラ人形は、子供にカウンタが移動したという確認応答を促すまで、2秒、3秒、5秒又は8秒などの所定の秒数待つ。コントローラ人形が確認応答を受信すると、プレイヤがゲームに勝ったかどうかを判定するためのチェックが行われる(ステップ514)。プレイヤがゲームに勝っていなかった場合、プレイは次のプレイヤへ進み(ステップ516)、プレイヤが勝つまで(ステップ518)ステップ506からプロセスが続く。
【0259】
ゲームエンジンは、上述した方法であらゆるルールに基づくゲームをプレイするようになっている。
【0260】
或いは、システムがC言語などの従来のプログラム言語を実行し、より複雑なアルゴリズムを実行してチェスなどのより複雑なゲームをプレイすることができる。上述したものと同じ言語を使用して会話を生成し、またこの言語がC言語プログラムから参照されるであろう。
【0261】
このような玩具及び人形は子供に異なる対話の機会を与え、子供たちのプレイを向上させる。
【0262】
テーマの例
付録Iには人形間のテーマ別会話の4つの例を提供する。これらの例は、会話を構築する異なる方法を提供するものである。動物園というテーマとペットというテーマのランダムに生成された会話の2つの例、X氏というテーマの台本通りの会話の1つの例、及びヘビとはしごというテーマによるゲームをプレイするというテーマの1つの例が存在する。
【0263】
ユニットのプロセッサ102を、会話コンパイラ206、会話データベース208及びパラメータ記憶装置216などのその他のモジュールとともに使用してテーマ内のスクリプトを解釈する。例えば、変数が定義された場合、パラメータ記憶装置内でメモリが割り当てられる。会話が開始されるたびに、パラメータ記憶装置内で変数が割り当てられる。これによりテーマを変更すること、すなわち動物園からペットへの変更ができるようになり、また前の会話からの変数と衝突することなく適当なメモリリソースに新しい変数を割り当てできるようになる。さらに、PREV、NEXT及びMEなどのパラメータにもパラメータ記憶装置内のメモリが割り当てられる。これにより、SELECT文がスクリプト内のパラメータを参照できるようになる。
【0264】
SAY文を使用する場合、コントローラ人形は、無線モジュール及び送信機を使用して関連する人形へコマンドを送信するために上述の通信プロトコルを使用するか、或いはコントローラ人形が現在の発話者である場合にはコントローラ人形の関連するモジュールを利用するかのいずれかを行う。発話するために必要な人形内の発話コンパイラ206を利用して、発話データベース208内の適当なオーディオファイルにアクセスする。例えば、動物園というテーマ内のSAY文を含む最初の行は、「SAY(i think we’ve seen everything now,p03,lets go home)」である。この文は、会話データベース内のオーディオファイルへの3つの参照で構成される。これらの参照は、「i think we’ve seen everything now」、「p03」、及び「lets go home」である。これらはすべてオーディオファイルを参照するが、「p03」という参照は特定の長さの休止を意味する。この休止は、オーディオファイルに適当に間隔をあけるために使用される空白のオーディオファイルである。その後、会話コンパイラ206がスピーカ210を使用してオーディオファイルを再生する。
【0265】
付録I内のテーマ例は、先に定義した文の使用のさらなる例を提供する。いずれの場合にも、プロセッサがコードを解釈し、適当なモジュールを利用して文を実行する。
【0266】
代替の実施形態では、本明細書で説明するように、プロセッサが内蔵インタプリタを使用せず、代わりに個々のテーマが、プロセッサが正しく機能できるようにする全てのプロセッサ制御命令を含むバイナリデータファイルで構成される。これにより、事実上必要なときにはいつでもプロセッサのファームウェアを新機能に更新できるようになる。以下で提供するテーマの例は、全てオーサリングツールを使用して生成することができる。しかしながら、玩具/人形を制御するための命令は、コンパイルされた「C」コードのバイナリファイルとなるであろう。
【0267】
プロセッサ及び関連電子部品
図8は、図2及び図3に示す概略図の潜在的生産バージョンのための回路図及びパーツリストの概略を示しており、付録IIが図8内の構成要素について詳述する。図9は代替の回路図の概略を示しており、付録IIIが図9内の構成要素について詳述する。生産回路に含めることができる選択肢が存在し、これらについては後で説明する。
【0268】
回路は以下を含む。
・Jennic無線コントローラ
生産回路はJennicICを使用し、RF回路を含み、ファームウェアとデータとを組み合わせて単一の大型フラッシュメモリICにする。Jennic無線コントローラは、例えばZigbee無線通信プロトコルを使用して人形間で通信を行うことができる。
・充電器
生産回路は、USBポートから充電するように特別に設計された部品を使用し、充電中に回路に給電も行う。
・音声増幅器
生産回路上の音声増幅器はD級オーディオアンプである。このアンプは非常に効率がよい(〜80%)。
【0269】
技術的選択肢
このセクションでは、図8の生産回路に含まれていない考えられる選択肢について説明する。
・USBインターフェイス
FTDI FT245RQ
この構成要素は、主にUSBドライバソフトウェアを備えたすぐに使用できるICとして選ばれたものであり、開発労力を低減させる。主な欠点は、Jennic上のほとんどのDIOx線を使用するという点である。これは現行の設計には問題ないが、会話圧縮ICなどの他の選択肢にDIOx線が必要とされる場合、この部品は不適当なものとなる。
【0270】
代替の実施形態
以下の両選択肢は、USB内蔵8ビットマイクロコントローラIC及びSPIスレーブインターフェイスである。これらはいずれもこれらを機能的にするために開発されたファームウェア及びソフトウェアドライバを有する必要があるが、両メーカは、このプロセスに役立てるためのリファレンス設計、利用上の注意などを提供している。これらの部品の利点は、JennicSPIインターフェイスとインターフェイス接続することができ、また1本のDIOx線しか必要とせずに他のDIOx線を他の用途のために解放する点である。
【0271】
玩具は、複雑なUSB要件を有しておらず、唯一の要件は、プログラムされるデータをフラッシュメモリにダウンロードすることである。装置は、メモリスティックなどのいかなる一般的な装置の機能にも対応する必要はない。これにより必要な開発労力が低減される。
【0272】
以下で特定する部品は、単純な低出力埋込み型アプリケーションを対象とするとともにSPIスレーブインターフェイスを有するものとして選んだものである。しかしながら、メーカのグループ又は他社メーカから得られる装置も同様に適している可能性が十分にある。
Cypress CY7C63833−LFXC
Atmel AT90USB82−16MU
【0273】
電池
リチウムイオン
図8及び図9に示す回路はリチウムイオン(Li+)電池を使用する。
3つの理由からLi+電池を選択した。
i)形状〜実証機のプロジェクトに便利であった平坦プリズム状パッケージの形で利用可能である。
ii)開発しやすさ〜Li+の充電要件は、特に充電器が追加の回路に同時に給電する必要がある場合に代替品よりも単純である。
iii)電力容量〜実証機起動時の控えめな電力要件の評価値が、利用可能な空間が狭くてもLi技術が十分な電力を与えることが示唆していた。
(後述を参照)。
代替の充電技術は、NiMH及びNiCadである。NiMHは、NiCad(Li+より複雑な)と同様の充電要件を有するが、Li+と同様の(より高い)出力密度(特定の物理体積に関しては保持電力が大きい)及び価格を有する。
【0274】
NiCad/NiMH
このセクションでは、Li+と比較したNiCad/NiMH電池の特性について考察する。説明を簡潔にするために、以下のセクションではNiMHをNiCadと表記する。
【0275】
i)形状
通常、NiCad電池には単三及び単四などの標準サイズがあるが、他の形状も利用可能である。小型の構成要素を使用でき、2ピース及び/又はフレキシブル回路/コネクタなどのより複雑なPCBの製造コストが抑制事項にならないと考えられる生産環境では、標準サイズの電池の使用を可能にすることができる。
【0276】
ii)開発しやすさ
新しいデータをダウンロードできるように、(USBポートから)電池を充電すると同時に(USBポートから)回路に電源を入れる必要がある(電池の充電と回路への給電とを同時に行うことはできない)。充電中に回路を電池から絶縁すること、或いは回路を接続したままにすることのいずれもが可能である。電池を絶縁するにはより複雑な回路を伴う。回路を接続したままにすることは、回路が制御している電池への通常の電流と、玩具の回路が受ける余分な電流との両方を充電器が見ることを意味する。
【0277】
Li+充電器の場合、回路を接続したままにすることはそれほど重大な問題ではない。主な欠点は、Li+電池が完全に充電されると充電器の電源を切ることが一般的であるという点である。この機能は禁止する必要があり、そうでなければ玩具の回路も同様に電源が切れてしまう。この結果、電池の寿命が短縮される。
【0278】
NiCad充電器の場合、回路を接続したままにすることは極めて重大な問題である。NiCad電池のほうが、特に充電の終了頃に充電プロファイルが複雑になる。このプロファイルが正しく検出されない場合、電池が二度と完全充電されないか、或いは電池が過充電された結果、電池への損傷及び過大な温度上昇が発生する。充電器は、このプロファイルを検出する2つの方法のうちの1つを使用する。第1の方法は、電池により引き込まれる電流の変化によるものである。残念ながら、現在の回路により引き込まれる電流では、充電器を混乱させた結果、危険な状況を生じる可能性がある。第2の方法は、電池の温度の変化を検出することによるものである。しかしながら、電池の充電部品も通常の使用中に高温になる。この用途では、信頼できる結果が得られるほど十分に電池を熱的に絶縁することは困難であると考えられる。
【0279】
電池を絶縁することは、図8の回路が採用する解決策である。充電器のICは、高性能の電力管理回路を組み込んで絶縁を行う。この統合電力管理は、既製品におけるNiCad技術には利用不可能である。従って、これは別個の構成要素又は特注のICにおいて実現されることになる。
【0280】
iii)電力容量
このセクションでは、人形の電子部品に関する電源要件について説明する。このセクションで使用される電池寿命は、以下の電池容量に基づくものである。
・単四アルカリ=1150mAh @1.5V
・単四NiCad=300mAh @1.2V
・単四NiMH=750mAh @1.2V
・Li+プリズム状=620mAh@3.7V
注:Li+電池は、同じ定格の場合他の電池の2倍の電力を保持するが、その理由は電圧が2倍の大きさだからである。2つの単四電池を直列で使用する必要があり、或いは1つの単四を昇圧型コンバータと共に使用してその能力を半分とする。
【0281】
図9に示す回路の電力評価
推定電力消費量=発話時136mA、その他の場合48mA。これは、以下で構成される。
・Jennicモジュール=48mA
・音声ドライバ
250mW最大8オームスピーカ出力=175mA、ただし、各々の人形が時間の半分ずつ発話する2つの人形間の会話において=>88mA
注:スピーカが時間全体にわたって最大電力で駆動されることはありそうにないが、オーディオアンプは100%効率ではないので、88mAが合理的な妥協点である。
・残りの回路=無視できる
【0282】
実証機の評価に基づく電池寿命。
実証機にとっては、単一のプリズム状Li+による解決策が当然の選択であった。
【0283】
図8に示す回路の電力要件。
全体的な電力消費量の中で音声電力が最も重要な因子であるため、より正確な値を得ることが重要である。最良の方法は直接測定であるが、これは音声パフォーマンスが一旦終了したときに限り可能である。
【0284】
しかしながら、音声電力が推定値ほど大きくないであろうことを示唆するいくつかの要素が存在する。
・発話の特性により、波形の平均電力はピーク振幅をかなり下回るものとなる。例えば、発話は多くの休止を含む。従って、回路が最大平均出力レベルを下回るレベルで駆動する可能性がある。
・生産回路で使用されるD級アンプは、図9に示す回路のものよりもはるかに良好な効率を有し、この結果大幅な節電となる。
【0285】
実証用の会話のさらに詳細な計算及び分析により、平均音声電力は会話中10mAにすぎず、従って2つの人形間の会話に関しては5mAという平均値になることが示唆されている。これにより、発話時に合計53mAで非発話時に48mAをもたらすJennic電力が優勢となる。
注:この音声電力レベルは、音楽ではなく発話音声に関するものである。
音声電力の改良評価に基づく電池寿命
【0286】
Jennicの電力消費量を削減する方法が存在する。現在、Jennicは常にオンであり、絶えずメッセージを探っている。ファームウェア及び人形が互いに通信する方法の変更により、絶えず探っている必要があるのは(最初に電源が入れられる)1つの人形のみとなる。他の人形は、発話する必要がある場合には定期的に第1の人形に確認することができ、この短時間の間のみ給電される必要がある。残りの時間は、Jennicは低電力スリープモードに入ることができる。10%の負荷サイクルが達成可能な場合、これにより非発話時に10倍の電力消費量が削減される。発話時にはJennicに給電する必要があるが、メッセージを探る必要がないので、RF部は非給電状態にすることができる。これによりJennicの電力消費量が4倍削減される。従って、全体的な電流消費量を発話時には14mAに、非発話時には4mAに低減させることが可能となる。
【0287】
ほとんどの人形がこの低減された電力要件を有するようになるが、(最初に電源を入れられる)1つの人形にはこの節電が行われないことになる。人形の起動方法の変更により、これも同様に低減させることが可能になると思われる。どのようなことが実現可能であるかを判定するためにはさらなる調査が必要である。
【0288】
低減されたJennicの電力要件に基づく電池寿命
これらの電力要件を実現できる場合、2本の単四標準、NiCad又はNiMH電池が使用可能になる。
【0289】
自動電源オフ機能
人形の電子部品の現在の仕様では、オン/オフスイッチが回路の作動を制御する。他の玩具とは異なり、人形は、アクティブな人形のいずれか1体のボタンが押されるのを待って受動的に座っているので、いつ人形のスイッチがオンになるかは明らかでない。これは、人形の電源をオフにするのを忘れる可能性が高いことを意味する。このため、(翌日などの)次回人形で遊ぶときには電池が切れてしまっている結果となる。
【0290】
回路がひとりでに『スタンバイ』モードに切り替わり、電流をほとんど引き出さないようにすることは可能であるが、これは現在の機能仕様には含まれていない。電子部品がいつこのスタンバイモードに入るか及びどのようにして再起動するかは、人形の全体的な挙動及びパフォーマンスに密接な関係がある。
【0291】
発話の圧縮
発話の圧縮により、同じメモリ量により多くの音声データを記憶できるようになる。現在の設計には発話圧縮技術は含まれていない。現在の設計では、結果として64kbps(ビット/秒)のデータ転送速度をもたらす8ビット8kHzの音声データが使用され、約1000秒(17分)の音声データを記憶できるようにする64Mbit直列フラッシュメモリが使用されている。会話の圧縮を使用して、このデータ転送速度を2kbpsと8kbpsとの間に下げることができるが、圧縮率を高くするほど音声品質は低くなる。つまり、8kbpsの場合、4Mbitフラッシュメモリは約500秒(8 1/2分)の音声データを保持することができる。
【0292】
圧縮音声データは、再生時に解凍を必要とする。これは、ソフトウェア又は専用ハードウェア内で行うことができる。2、3の選択肢を以下に示す。
【0293】
Jennicコントローラ上でのソフトウェア解凍
この選択肢は幅広く調査されていない。まず、適当な圧縮/解凍アルゴリズムのソースコードを発見し、このアルゴリズムをJennicコントローラに移植するできるようにする必要がある。次に、このアルゴリズムが必要とし、Jennicコントローラ上で利用可能な処理電力の分析を行う必要がある。
【0294】
Sensory社の音声合成IC
Sensory社は、マイクロコントローラのファミリを2つ有する。SC−6xファミリは、事前プログラムされたSC−691スレーブシンセサイザを有する。これは、Jennicとインターフェイス接続するのに9本のDIOx線を必要とする4ビットMCUインターフェイスを有し、32オームのスピーカを直接駆動させることができる。新しい方のRSC46xファミリは、事前プログラムされたスレーブシンセサイザを有していないので、カスタムファームウェアを開発することが必要となる。Jennicとは4ビット、又は8ビットMCUインターフェイス(9本又は15本のDOIx線)でインターフェイス接続するようになるであろう。しかしながら、こちらのほうがプロセッサは強力であり(音声認識アルゴリズムを処理することができる)、8オームのスピーカを直接駆動させることができる。Jennicは両方に対応する十分なDIOx線を有していないので、これらの部品のどちらもUSB FT245チップと共に使用することができない。スレーブSPI USBチップが必要となる(USBのセクションを参照)。
【0295】
かなりの処理電力を有するRSC−4xなどの音声合成マイクロコントローラを使用することは、代替のシステム構築の可能性を示唆する。メイン人形アルゴリズムを実行させるとともにスレーブマイクロプロセッサとして合成マイクロコントローラを使用して音声を単純に解凍するJennic無線マイクロコントローラの代わりに、合成マイクロコントローラがメイン人形アルゴリズムを実行するとともに無線通信のためにスレーブコプロセッサとして無線マイクロコントローラを使用することができる。さらなる詳細については無線マイクロコントローラのセクションを参照されたい。
【0296】
無線マイクロコントローラ
現在の設計は、2.4GHzIEEE802.15.4パーソナルエリアネットワーク通信規格に基づくものである。全ての低レベルRF通信に対応するために必要なRFハードウェア及びファームウェアを含む無線マイクロコントローラ製品が存在する。通信内のデータのみは、人形アプリケーションにより定義する必要がある。現在の設計は、Jennic無線マイクロコントローラを選択している。
【0297】
IEEE802.15.4製品は低レベルRF通信に対応するが、人形アプリケーションには良好に適合しない一面がある。IEEE 802.15.4はノードの階層構造に基づくものであり、多くの機能低減装置が全機能搭載装置と通信する。人形アプリケーションはピアツーピア構造を有し、全ての装置が同じものである。
【0298】
同じ2.4GHz又は異なるISM周波数帯で機能する他のRFトランシーバ製品が利用可能である。これらは必要なRFハードウェアを全て含むが、特定の低レベルプロトコルを強いるものではない。これらのトランシーバICは、汎用マイクロコントローラ又はRSC4倍速音声シンセサイザーなどの専用マイクロコントローラのスレーブとして機能する。これらの部品を使用して、専用のピアツーピア通信プロトコルを開発することができる。
【0299】
RFトランシーバの例には、Tl CC2500及びAtmel ATA542Xファミリがある。これらの部品は、JennicICよりも低い電力消費量及び単位原価を実現する可能性がある。
【0300】
言うまでもなく、本発明は、単なる例示として説明した上記実施形態の詳細に限定されることを意図されたものではなく、本発明の範囲内において詳細の修正を行うことができることを理解されたい。
【0301】
説明及び(必要に応じて)特許請求の範囲並びに図面において開示した個々の特徴は、単独で又はあらゆる適当な組み合せで提供することができる。
【符号の説明】
【0302】
200:制御装置
202:スレーブ
204:会話エンジン
206:発話コンパイラ
208:発話データベース
210:スピーカ
212:IR/RF送信機/受信機
214:ランダム発話セレクタ
216:パラメータ記憶装置
218:発話者セレクタ
付録I〜テーマの例
付録II〜図8に関する部品の詳細
付録III〜図9に関する部品の詳細
【技術分野】
【0001】
本発明は玩具に関する。特に、限定的な意味ではないが、本発明は互いに対話する人形などの玩具に関する。
【背景技術】
【0002】
組込み型コンピュータ及びマイクロプロセッサは、子供用玩具を進歩させてきた。これらは教育用玩具において最も広く使用されてきたが、対話型玩具においても使用されてきた。ActiMates(登録商標)Barney(登録商標)は、子供からの適切な発声による対話に応答するとともにビデオに合わせて歌うことができる対話型玩具の一例である。
【0003】
本明細書にはPCT特許出願WO2006/114625号が引用により組み入れられる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】PCT特許出願WO2006/114625号
【発明の概要】
【課題を解決するための手段】
【0005】
オーサリングツール
本発明の第1の態様によれば、玩具のテーマ別データを作成するためのオーサリングツールが提供され、該オーサリングツールは、特定のテーマに関連するコンテンツを受信する手段と、前記コンテンツを処理して前記特定のテーマ内で前記玩具を動作させるための命令セットを生成する手段と、前記命令セットを出力する手段とを含む。玩具を動作させるための命令セットを生成する手段を提供することにより、テーマ別の命令を生成するプロセスが実質的により効率化される。
【0006】
コンテンツを受信する効率性のために、前記受信手段は、特定のテーマに関連するスクリプトデータ及び前記玩具の性格を定義する表現データの両方を別個に含むコンテンツを受信するようになっていることが好ましい。前記受信手段は、コンテンツを別の部分の形で受信するようになっていることが好ましい。
【0007】
処理の効率性のために、オーサリングツールは、個々の表現データ部分に一意のID番号を割り当てる手段をさらに含むことが好ましい。前記処理手段は、前記命令セットにおいて前記表現データ部分への参照として前記一意のID番号を利用するようになっていることが好ましい。
【0008】
前記表現データは、テーマ名、玩具の名前、及び玩具が対話するために使用する文のうちの少なくとも1つを含むことが好ましい。
【0009】
前記スクリプトデータは、テーマ内で対話できる玩具の数、対話方法、テーマ関連パラメータ、及び玩具関連パラメータのうちの少なくとも1つを含むことが好ましい。
【0010】
処理の効率性のために、オーサリングツールは、特定のテーマに関連する前記スクリプトデータ及び表現データを共に配列の形で記憶する手段をさらに含むことが好ましい。前記処理手段は、前記配列から前記命令セットを生成するようになっていることがさらに好ましい。
【0011】
処理の効率性のために、前記処理手段は、表現データの少なくとも一部を含む少なくとも1つのリストをコンパイルする手段を含むことが好ましい。前記リストコンパイル手段は、前記特定のテーマ内で玩具ごとにそれぞれのリストをコンパイルするようになっていることがさらに好ましい。
【0012】
表現データはシンボルデータであることが好ましい。本明細書で使用するシンボルデータは、書かれた形の単語、音楽又は行動を意味する。
【0013】
オーサリングツールは、シンボルデータの上演(enacted)データバージョンを記録する記録手段をさらに含むことが好ましい。本明細書で使用する上演データとは、上演される形の単語、音楽又は行動を意味するものである。
【0014】
オーサリングツールは、関係者に上演データの必要な部分を生成するように促す手段を含むことが好ましい。
【0015】
前記プロセッサは、シンボルデータと上演データとの間のルックアップテーブルを生成するようになっていることが好ましい。
【0016】
前記処理手段は、表現データを出力するようになっていることが好ましい。前記処理手段はさらに、表現データ及び命令セットを別個に出力するようになっていることがさらに好ましい。
【0017】
前記処理手段は、玩具の基本機能を制御するための基本命令セットと、基本命令セットがテーマ内で玩具を制御するためのテーマ別命令セットとを含む命令セットを生成するようになっていることが好ましい。前記プロセッサは、前記基本命令セット及び前記テーマ別命令セットを共に組み合わせるようになっていることがさらに好ましい。
【0018】
オーサリングツールは、コンパイラをさらに含むことが好ましい。前記プロセッサは、前記基本命令セット及び前記テーマ別命令セットをコンパイルするようになっていることがさらに好ましい。
【0019】
前記プロセッサは、前記命令セットをコンピュータ可読コードに変換するようになっている符号化エンジンを含むことが好ましい。
【0020】
オーサリングツールの出力は、本明細書で説明するような会話エンジンで使用されるようになっていることが好ましい。
【0021】
玩具は、本明細書で説明するような玩具であることが好ましい。
【0022】
本発明の第2の態様によれば、玩具のテーマ別データを作成するオーサリングツールのためのユーザインターフェイスが提供され、該ユーザインターフェイスは、各々がテーマに関連する特定のコンテンツのサブセットの入力に対応する入力ウィンドウのセットをユーザに提供する手段と、テーマ別データの出力を開始する手段とを含む。
【0023】
前記コンテンツのサブセットは、テーマ関連データ、玩具関連データ及びコンテキスト関連データのうちの少なくとも1つを含むことが好ましい。
【0024】
コンテキスト関連データは、玩具が対話するために使用する文、対話方法、テーマ関連パラメータ及び玩具関連パラメータのうちの少なくとも1つを含むことが好ましい。
【0025】
本発明の第3の態様によれば、玩具のテーマ別データを生成するためのシステムが提供され、該システムは、テーマ別データにアクセスし、これを作成及び編集するオーサリングツールと、前記テーマ別データを記憶するためのデータベースを含むサーバとを備え、オーサリングツールは、インターネットを介してテーマ別データにアクセスするようになっている。
【0026】
オーサリングツールは、テーマ別データを処理して配列するようになっており、前記データベースは、前記テーマ別データを前記配列の形で記憶するようになっていることが好ましい。
【0027】
オーサリングツールは、本明細書で説明するようなオーサリングツールであることが好ましい。
【0028】
オーサリングツールは、ユーザインターフェイスをさらに含むことが好ましい。ユーザインターフェイスは、本明細書で説明するようなインターフェイスであることがさらに好ましい。
【0029】
USB通信ドングル
本発明のさらなる態様によれば、本明細書で説明するような少なくとも1つの玩具とコンピュータの間に無線通信を提供する装置が提供され、該装置は、装置をコンピュータに接続するための通信ポートと、コンピュータと前記又は各玩具との間にネットワークを確立する手段とを含み、コンピュータが別のこのような玩具であるかのように前記又は各玩具と通信できるようにする装置を提供する。
【0030】
前記装置は、コンピュータを仮想玩具として機能できるようにすることが好ましい。
【0031】
前記通信ポートはUSB通信ポートであることが好ましい。
【0032】
前記ネットワークは無線であることが好ましい。
【0033】
本発明のさらに別の態様によれば、本明細書で説明するような少なくとも1つの玩具と、各々が本明細書で説明するような無線通信を行う装置を有する少なくとも1つのコンピュータとを備えたシステムが提供され、前記コンピュータと装置とを組み合わせることにより本明細書で説明するような玩具であるかのように機能する。
【0034】
前記コンピュータは、仮想玩具を提供するようになっている視覚及び音声出力を含むことが好ましい。仮想玩具は、アバターであることがさらに好ましい。
【0035】
コントローラ人形
本発明のさらに別の態様によれば、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部と、少なくとも1つのさらなるこのような玩具とのネットワーク接続を確立する手段とを含む玩具が提供され、プロセッサは、ネットワーク接続が確立された各玩具の出力を制御する手段を含む。
【0036】
前記制御手段は、ネットワーク接続が確立された各玩具の複数の出力(好ましくは全ての出力)を制御する命令をネットワーク接続を介して送信するようになっていることが好ましい。
【0037】
前記ネットワーク接続が、パーソナルエリアネットワークの一部を形成することが好ましい。
【0038】
前記メモリは、データの少なくとも1つのグループを記憶するようになっており、個々の前記少なくとも1つのグループは特定のテーマを表すことが好ましい。
【0039】
玩具は、前記メモリに記憶された少なくとも1つのテーマを決定する手段をさらに含むことが好ましい。
【0040】
前記玩具は、別の玩具との接続を、前記メモリに記憶された少なくとも1つのテーマが両玩具において同じである場合にのみ確立するようになっていることが好ましい。
【0041】
前記制御手段は、制御メッセージを送信/受信して個々の前記玩具の出力を制御するようになっていることが好ましく、制御メッセージは、対象の玩具のID及びコマンドセグメントを含むことが好ましく、発信元玩具のID及び/又はメッセージIDをさらに含むことがより好ましい。
【0042】
前記制御メッセージは、参照データベースにアクセスしてタスクを実行する命令を含むことが好ましい。
【0043】
プロセッサは、前記送信/受信された制御メッセージの確認応答を送信/受信する手段を含むことが好ましく、前記送信/受信手段は、確認応答を受信しない場合に制御メッセージを再送するよう要求するようになっていることが好ましい。
【0044】
前記送信/受信手段は、このような玩具が制御メッセージに基づいて出力を生成するのに掛かるであろう時間に関連するパラメータを送信するようになっていることが好ましく、発信元玩具は、さらなる制御メッセージを送信するまで前記パラメータに関連する時間の間待機することが好ましい(このような玩具がこのような出力を生成するのに掛かる時間は、例えば玩具のテーマ又はサブテーマにより様々であってもよい)。
【0045】
プロセッサが、再送信制御メッセージの数をカウントする手段を含み、これにより前記制御メッセージの確認応答を行わない前記玩具との通信が、1,000〜2,000回、2,000〜5,000回、5,000〜10,000回又はそれ以上の試行後に停止されることが好ましい。
【0046】
前記プロセッサは、前記玩具間の会話を構築するようになっている会話エンジンをさらに含むことが好ましい。
【0047】
さらなるこのような玩具は、最初のこのような玩具と同一又は実質的に同一であることが好ましい。従って、「スポークハブ」構成は不要である。
【0048】
前記ネットワークを確立する手段はネットワークコントローラであることが好ましく、Zigbeeプロトコルを利用するネットワークコントローラであることが好ましい。
【0049】
パラメータ記憶
玩具は、別のこのような玩具と対話するようになっており、前記プロセッサは、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数をメモリに記憶する手段と、前記変数を使用して前記玩具の(対話型)出力を制御する手段とを含むことが好ましい。
【0050】
本発明のさらに別の態様によれば、別のこのような玩具と対話するようになっている玩具が提供され、該玩具は、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを備え、前記プロセッサは、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数をメモリに記憶する手段と、前記玩具の(対話型)出力に関連して変数を使用する手段とを含む(この結果より効率的に対話の経過を追い続けることが好ましい)。
【0051】
前記変数を複数回(より好ましくは数えきれないほど)使用して出力を制御することが好ましい。
【0052】
前記変数を使用して、前記対話の回数、種類又は性質を決定することが好ましく、前記変数が前記対話であることが好ましい。
【0053】
前記変数は、ランダムに又は疑似ランダム的に選択され、前記ランダム選択は重み付けにより影響されることが好ましい。
【0054】
玩具は、対話を生成する手段をさらに含むことが好ましい。対話を生成する手段は、記憶パラメータに基づいて対話を生成するようになっていることが好ましい。
【0055】
記憶手段は、各変数を玩具と関連づけることが好ましい。
【0056】
記憶手段は、玩具内に位置するメモリであることが好ましい。
【0057】
変数を使用する手段は、記憶手段から変数にアクセスするようになっていることが好ましい。
【0058】
前記対話は、玩具間の通信であることが好ましい。
【0059】
前記変数は、発話で利用される単語又は語句であることが好ましい。
【0060】
性格の表現及びテーマのスクリプト記述
前記プロセッサは、前記メモリにテーマ別データを記憶するようになっており、前記テーマはスクリプトデータ及び表現データを含み、前記表現データが前記玩具の性格を定義することが好ましい。
【0061】
本発明のさらに別の態様によれば、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを備えた玩具が提供され、前記プロセッサは、前記メモリにテーマ別データを記憶するようになっており、前記テーマはスクリプトデータ及び表現データを含み、前記表現データが玩具の性格を定義する(この結果、複数のテーマ別の玩具の性格がより効率的に提供されることが好ましい)。
【0062】
玩具は、少なくとも1つの他の同様の玩具と対話するようになっており、前記スクリプトデータが個々のこのような玩具により共有され、前記表現データが個々のこのような玩具間で異なることが好ましい。
【0063】
前記スクリプトデータは、前記表現データとは無関係であることが好ましい。
【0064】
プロセッサは、別のこのような玩具に制御メッセージとしてスクリプトデータを出力するようになっており、制御メッセージに個々の表現データで応答するようになっていることが好ましい。
【0065】
スクリプトデータは、各玩具ごとに同じものであり、各玩具の出力を制御することが好ましい。
【0066】
プロセッサは、スクリプトデータを利用して表現データを参照するようになっていることが好ましく、表現データは、異なるコンテンツを使用して同じ情報を通信することが好ましい。
【0067】
玩具の性格は、通信のコンテンツにより定義されることが好ましい。
【0068】
人形の選択
プロセッサは、対話するための玩具を予め定めたルールに基づいて選択する手段を含むことが好ましい。
【0069】
本発明のさらに別の態様によれば、他のこのような玩具と対話するようになっている玩具が提供され、該玩具は、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを備え、前記プロセッサは、対話する玩具を予め定めたルールに基づいて選択する手段を含み、前記選択される玩具は発信元玩具であってもよい。
【0070】
前記選択手段は、次の対話する玩具を選択するようになっていることが好ましい。
【0071】
前記予め定めたルールは、直接選択、ランダム選択、及び現在の対話玩具を選択して再び対話することを含むことが好ましい。
【0072】
プロセッサは、選択された玩具のID及び好ましくは発信元玩具のIDを含む制御メッセージを出力するようになっていることが好ましい。
【0073】
前記対話は通信を含むことが好ましく、該通信は発話及び指示を含むことが好ましい。
【0074】
ゲームのプレイ
玩具は、他の同様の玩具とゲームをプレイすることに適した生きているものの形をとり、前記プロセッサはゲームエンジンを含み、該ゲームエンジンは、前記玩具が生きているかのようにゲームをプレイ可能にするようになっていることが好ましい。
【0075】
本発明のさらに別の態様によれば、他の同様の玩具とゲームをプレイすることに適した生命があるものの形をした玩具が提供され、該玩具は、プロセッサと、該プロセッサに結合されたメモリと、前記プロセッサに結合された出力部とを含み、前記プロセッサは、個々の前記玩具を関連する生きているものであるかのようにゲームできるようにするゲームエンジンを含む。
【0076】
前記ゲームエンジンは、人間のゲームを可能にするようになっていることが好ましい。
【0077】
前記人間のゲームは、ゲーム機器でプレイされることが好ましい。
【0078】
前記ゲームエンジンは、人間がゲーム機器を調整してゲームをプレイできるようにする命令を出力するようになっていることが好ましい。
【0079】
前記玩具は、少なくとも1つのさらなるこのような玩具と通信する手段をさらに含むことが好ましい。
【0080】
前記ゲームエンジンはさらに、ルールに基づいたゲームをプレイするようになっていることが好ましい。
【0081】
前記ゲームエンジンは、前記メモリにゲームに関する情報を記憶するようになっていることが好ましい。
【0082】
前記情報はゲームのルールを含むことが好ましい。
【0083】
前記情報は、少なくとも1つのプレイボードのレイアウトをさらに含むことが好ましい。
【0084】
前記ゲームエンジンは、仮想サイコロになっている乱数発生器を含むことが好ましい。
【0085】
ゲームエンジンは、ゲームに関する外部入力を受信する手段を含むことが好ましい。
【0086】
前記外部入力は、ゲームの駒に関連付けられることが好ましい。
【0087】
前記外部入力は、プレイボード内の少なくとも1つのセンサであることが好ましい。
【0088】
前記外部入力は、玩具のユーザが使用するようになっているスイッチであることが好ましい。
【0089】
前記ルールに基づくゲームは、ヘビとはしご及びルードを含むことが好ましい。
【0090】
前記出力は変換器であることが好ましい。前記変換器はスピーカであることが好ましい。前記変換器はアクチュエータであることが好ましい。
【0091】
本発明のさらに別の態様によれば、複数のこのような玩具を含む組み合わせが提供される。
【0092】
前記複数の玩具の各々の1つが他の前記玩具を制御する手段を含むことにより、1つの玩具のみが他の前記玩具を同時に制御することが好ましい。
【0093】
前記メモリは、ゲームの状態に関連する情報を記憶するようになっていることが好ましい。ゲーム状態は、プレイボードのレイアウト、プレイボード上の少なくとも1つのカウンタの位置、玩具及び/又はユーザの全てに関するプレイの順序の少なくとも1つであってもよい。
【0094】
人形固有のダウンロード
本発明のさらに別の態様によれば、複数の玩具にテーマ別データを提供する装置が提供され、該装置は、各々が複数のサブテーマを含む前記テーマ別データを記憶する手段と、特定の玩具を識別する手段と、特定の玩具に基づいてサブテーマを選択する手段と、前記玩具に対して前記特定のサブテーマを出力する手段とを含む(この結果、テーマ別ダウンロードへのアクセスがより効率的に達成されることが好ましい)。
【0095】
玩具は、複数の異なるテーマを記憶する手段をさらに含むことが好ましい。
【0096】
玩具は、ユーザが複数のテーマのうちの1つを選択できるようにする手段をさらに含むことが好ましい。
【0097】
前記特定の玩具を特定する手段は、前記玩具の一意の識別番号を使用することが好ましい。
【0098】
玩具は、前記玩具に関連するパラメータに基づいて個々の前記サブテーマを暗号化する手段をさらに含むことが好ましい。前記パラメータは玩具の一意の識別番号であることが好ましい。
【0099】
装置は、プロセッサと、テーマ別データを記憶するとともに特定の玩具を識別する関連メモリとを含むことが好ましい。
【0100】
装置は、玩具にサブテーマを出力するための接続部をさらに含むことが好ましい。接続部は、インターネット及びUSBケーブルを含むことが好ましい。
【0101】
会話エンジン
本発明のさらに別の態様によれば、玩具などの装置のための会話エンジンが提供され、該会話エンジンは、会話のテーマを選択し、複数の起点から起点をランダムに選択し、変数に基づいて語句をランダムに選択し、変数に基づいて次の発話者をランダムに選択する手段を含む。
【0102】
前記語句選択はさらに、重み付けに基づくことが好ましい。
【0103】
玩具は、会話エンジンを組み込むことが好ましい。
【0104】
玩具又は会話エンジンは、ユーザから入力データを受信するようになっていることが好ましい。
【0105】
玩具又は会話エンジンは、ユーザにデータを出力するようになっていることが好ましい。
【0106】
会話エンジンはさらに、ユーザからの入力データをランダム選択処理の形で利用するようになっていることが好ましい。
【0107】
会話エンジンは、選択動作を実行するようになっているプロセッサを含むことが好ましい。
【0108】
玩具又は会話エンジンは、会話をリアルタイムに構築するようになっていることが好ましい。
【0109】
玩具又は会話エンジンは、会話を前処理するようになっていることが好ましい。玩具又は会話エンジンはさらに、前処理済みの会話を出力するようになっていることが好ましい。
【0110】
玩具又は会話エンジンは、会話を構築する際に、確立されたネットワーク内に存在する他の玩具のパラメータを変数として利用するようになっていることが好ましい。
【0111】
玩具又は会話エンジンは、重み付けに基づいてデータを出力するようになっていることが好ましい。
【0112】
玩具は、複数組のテーマ別データを記憶するようになっていることが好ましい。玩具はさらに、1つの会話中に複数組のテーマ別データのうちの少なくとも2つを利用するようになっていることが好ましい。
【0113】
玩具は、好ましくは2、3、4又はそれ以上の複数の他のこのような玩具とネットワークを確立できるようになっていることが好ましい。
【0114】
玩具は、生きているようになっていることが好ましい。
【0115】
玩具は、他のこのような玩具と通信するようになっており、前記通信は、発話、行動及びジェスチャを含むことが好ましい。
【0116】
玩具又は会話エンジンは、以下の特徴の1つ、いくつか、又は全てをいずれかの組合せで有することが好ましい。
・子供が玩具と対話式に遊ぶことができる
・オンザフライで構築される会話
・会話を開始する前に会話が前処理される
・会話がネットワーク内に存在する人形に基づく
・会話がネットワーク内に存在する人形の種類に基づく
・会話の長さ及び方向性の制御に使用される重み付け
・会話の半ばでテーマを切り替える能力
・2、3又はそれ以上の玩具
・玩具は生きているもの/人間/人形である
・対話は通信を含み、通信は広い意味で定められる
【0117】
要約すると、本発明は特に以下の発明に言及するものである。
・オーサリングツール〜玩具が読み込み可能なプログラムコードにコンパイルされる会話データを入力する機能を提供する。
・USB通信ドングル〜玩具とPCとの間の通信を可能にする装置を提供する。
・コントローラ人形〜3以上の人形であり、単一のコントローラとして最初に電源が入った人形を使用して制御が行われる。
・性格の表現〜人形の性格要素に基づいて、同じテーマが異なる表現を有する。
・テーマのスクリプト作成〜テーマは、ダウンロード可能な表現の組合せであり、スクリプト/スクリプト及び表現は、異なるテーマごとに不可欠な/異なるスクリプトである。
・パラメータ記憶〜現在の会話に関する情報を記憶する能力、例えば、「私の犬はFluffyと言います」という語句では、人形がその会話内の情報(ペット=「犬」及びペットの名前=「fluffy」)を後で使用するために記憶する。
・人形固有のダウンロード〜ウェブサイトダウンロードのみが、特定の性格に関する特定の言語を表現として有し、性格に従って表現がダウンロードされる。
・会話の構造〜人形は、関連する発話で応答するか、別の人形を選択して話しかけるか、或いは自分自身について何かを発表するかのいずれかを選択する。
・人形の選択〜コントローラは、次にどの人形が発話するかをランダムに決定し、ランダムに選択するものの、人形は2回続けて発話することができず、或いは特定の人形を名前で選択することもできない。
・ゲームのプレイ〜人形は人間のようにゲームをプレイする。
【0118】
本発明は、データ処理装置で実行された場合、構成要素の段階のいずれか又は全てを含む本明細書で説明する方法のいずれかを実行するようになっているコンピュータプログラム及びソフトウェアコードを含むコンピュータプログラム製品も提供する。
【0119】
本発明は、データ処理装置で実行された場合、本明細書で説明する装置の特徴のいずれかを含むコンピュータプログラム及びソフトウェアコードを含むコンピュータプログラム製品も提供する。
【0120】
本発明は、本明細書で説明する方法のいずれかを実行し及び/又は本明細書で説明する装置の特徴のいずれかを具体化するコンピュータプログラム及びコンピュータプログラムをサポートするオペレーティングシステムを有するコンピュータプログラム製品も提供する。
【0121】
本発明は、上述したようなコンピュータプログラムを記憶したコンピュータ可読媒体も提供する。
【0122】
本発明は、上述したようなコンピュータプログラムを保持する信号及びこのような信号を送信する方法も提供する。
【0123】
本発明は、実質的に添付図面を参照しながら本明細書で説明するような方法及び/又は装置にまで及ぶ。
【0124】
装置及び方法の特徴は適宜入れ替えることができ、また互いに独立して提供することができる。本発明の1つの態様におけるあらゆる特徴を、本発明の他の態様にあらゆる適当な組合せで適用することができ、同様に1つの本発明におけるあらゆる特徴を、本発明の他の態様にあらゆる適当な組合せで適用することができる。例えば、方法の態様を装置の態様に適用することができ、この逆もまた可能である。この場合も、例えば「コントローラ人形」のあらゆる特徴を「パラメータ記憶」のあらゆる特徴に適用することができる。
【0125】
さらに、ハードウェアで実行される特徴をソフトウェアで実行することができ、この逆もまた可能である。本明細書におけるソフトウェア及びハードウェアの特徴へのあらゆる言及については、以上に従って解釈すべきである。
【0126】
本明細書では、「〜する手段」に機能をプラスした用語の使用は、この機能を実行するようになっている適当なハードウェアコンポーネント(例えば、プロセッサ及び/又はメモリ)と置き換えることができる。
【0127】
以下、ほんの一例として、本発明の様々な実施形態について添付図面を参照しながら説明する。
【図面の簡単な説明】
【0128】
【図1】3種類の人形を示す図である。
【図2】人形の概略図である。
【図3】スレーブ玩具を含むコントローラ玩具の概略図である。
【図4】人形にテーマ/サブテーマをダウンロードできる、ウェブサイトに接続された人形の概略図である。
【図5】ゲームをプレイするようになっている人形の概略図である。
【図6】ゲームをプレイする処理のフロー図である。
【図7】代替実施形態の概略図である。
【図8】プロセッサ及び関連する電子機器の回路図の実施形態である。
【図9】プロセッサ及び関連する電子機器の回路図の代替実施形態である。
【図10】オーサリングツールサーバと通信しているユーザPCを示す図である。
【図11】オーサリングツール及び関連システムの概要を示す図である。
【図12a】会話デザイナーウィンドウを示す図である。
【図12b】テーマ生成ウィンドウを示す図である。
【図12c】データ入力したテーマ生成ウィンドウを示す図である。
【図13a】人形追加ウィンドウを示す図である。
【図13b】人形作成ウィンドウを示す図である。
【図14】人形コンテキストウィンドウを示す図である。
【図15】会話入力ウィンドウを示す図である。
【図16】複数の人形と通信しているUSBドングルを示す図である。
【発明を実施するための形態】
【0129】
図1は3種類の人形を示す図であり、10はテニスをしている人形、20はバレリーナ人形、30は犬の散歩中を示す一般的な人形、及び40は戦車の形をした玩具である。一般に、玩具は生きているように見えるようになっており、特に戦車などの場合は、人間のように又は人間が制御しているように見えるようになっている。図示の4つの玩具は、テーマ別玩具の種類の例である。玩具は、テーマ内の他のこのような玩具と無線で通信するようになっている。
【0130】
以下の説明は、他のこのような玩具と通信できるようにされた人形などの玩具に関するものであり、人形は、人形間で発話を調整するようになっている。別の実施形態では、玩具は戦車又は別のこのような車両であり、この場合も、人形間の発話の代わりに戦車が他のこのような戦車と無線で通信して戦車の挙動を調整するようになっている。
【0131】
図2は人形の概略図を示しており、人形が通信を行って他のこのようなタスクを実行できるようにするために必要なハードウェアコンポーネントを含む。図2に示すように、人形100は、無線モジュール104を含むプロセッサ102を含む。プロセッサは、メモリ106、ROM108及びRAM110と通信している。IR/RF送信機/受信機がプロセッサ/無線モジュールに接続され、他のこのような人形との間で信号を送信/受信できるようにされる。人形はスピーカ114にも接続される。USBコントローラ116を使用してメモリ106を更新し、充電器回路118を介して電池120の充電も行う。或いは、人形は、充電式電池ではなく交換式電池を使用するようにされる。
【0132】
メモリ106は、人形が行うことができる会話に関する情報を記憶し、プロセッサが発話をコンパイルしているときにプロセッサによりアクセスされる。ROM108を使用して、人形の名前及びID番号などの人形に関する恒久的情報を記憶する。この情報は、人形のネットワークを設定するときの初期化手順において使用される。RAM110は、現在の会話に関する情報を記憶し、例えばすでに使用された語句に関する情報を記憶することにより現実的な会話を作成するために使用される。
【0133】
個々の人形100は、メモリ106内に、人形の名前を含むデータセット及び会話中に定義されるその他の変数、会話を作成する命令セット、及び音声データセットを含む。会話中に定義される変数は、コントローラ人形にのみ記憶される。
【0134】
1つの実施形態では、プロセッサが、関連する(SDカードなどの)メモリインターフェイスを伴ってMP3復号で使用されるような形をとる。この実施形態は、かなりの量の処理能力(及びハードウェアベースの圧縮技術)を提供し、従って人形間の長く詳細な会話を可能にする。
【0135】
コントローラ人形
図3でわかるように、コントローラユニット200がいくつかのスレーブユニット(202)と通信している。コントローラは、会話エンジン204と、発話コンパイラ206と、発話データベース208と、スピーカ(変換器)210と、スレーブユニットからデータを送信及び受信できる送信機/受信機212とを含む。会話エンジンは、ランダム発話セレクタ214と、パラメータ記憶メモリ216と、発話者セレクタ218とを含む。スレーブユニットは、コントローラユニットの全ての構成要素を有しており、図3ではスレーブユニットの構成要素の全てを示しているわけではない。
【0136】
最初に電源が入るユニットがコントローラユニットとなるように初期化される。ユニットに電源が入ると、このユニットが既存のネットワークを検索し、ネットワークが存在しなければ、ネットワークを作成して他のユニットがネットワークに参加するのを待つ。さらなるユニットがオンになると、これらがネットワークに参加し、スレーブユニットとして初期化される。コントローラユニットは、両方の新しいユニットからの、ネットワークの詳細及び会話開始メッセージを求めることを示す通信を待つ。スレーブユニットは、ネットワークに参加すると、コントローラユニットからの命令を待つ。ユニット(玩具/人形)は、全てがコントローラユニットにも又はスレーブユニットにもなることができる限り全て同じものであることを理解されたい。
【0137】
ユニットは、「動物園」、「スポーツ」、「ギャングスタ」又は「ファッション」などのテーマ内で通信するようになっている。テーマにより、ユニットは、考えられる会話の話題全てに関する情報についての極めて大規模なデータベースを必要せずに詳細な会話を行えるようになる。ユーザは、テーマ/サブテーマをウェブサイトからユニットにダウンロードすることができる。
【0138】
以下のプロセスを使用して玩具のネットワークを開始する。
・人形がオンになったときに、参加する既存のネットワークが存在するかどうかを判定するためのチェックを行う〜これは送/受信機212を使用して遂行される。
・利用可能なネットワークが存在しない場合、この人形がコントローラになって自動的にネットワークを設定する〜必要な場合、無線モジュール104がネットワークを作成するようになっている。
・オンになった個々の後続の人形が、メモリに記憶した人形ID番号及びテーマ/複数のテーマID番号を送信する〜情報は送信機212により送信される。
・コントローラがテーマ/複数のテーマをチェックして、コントローラと同じ参加するテーマ/複数のテーマを有する人形のみを許可する〜コントローラユニットが、送信データとメモリに記憶されたデータとの比較を行う。
・2又はそれ以上の人形がネットワークに参加すると、会話を開始することが可能となる。
・ユーザがボタンを押すことなどにより会話を開始し、コントローラが、他の人形に何を発言すべきかを指示する会話を開始する。
・ユーザは、いつでも再びボタンを押して会話を停止することができる。
【0139】
コントローラユニットは会話を生成するプログラムを実行し、その後どのオーディオファイルにアクセスすべきかを知らせる情報をスレーブユニットへ送信する(このオーディオファイルは個々の性格型によって異なってもよいが、オーディオファイルの各々への参照はユニットごとに同じものである)。コントローラユニットは、スレーブユニットのメモリからアクセスするための単語/語句の識別子を送信する。スレーブユニットは、使用する語句及びこの語句を発言するのに要する予想される時間長を確認するメッセージを送信することにより、メッセージの受信についての確認応答を行う。次に、スレーブユニットは、会話コンパイラを使用して単語/語句をコンパイルし、その後スピーカを使用して語句を発言する。スレーブユニットは、語句を発言し終わると、文が終了し会話を続けることができる旨の信号をコントローラユニットへ送信する。
【0140】
その後、コントローラユニットが同じ方法で次の発話者に指示を行い、会話が終わるまでこれを継続する。会話構造に関するさらなる詳細を以下に示す。
【0141】
通信プロトコル
玩具は通信プロトコルを使用して通信し、メッセージのフォーマットは以下の通りである。
[MessageID,SendingToy_ID,ReceivingToy_ID,MessageType,Parameters]
【0142】
MessageIDとは、メッセージを識別する一意の番号のことである。制御玩具から送信される個々のメッセージは一意の識別番号を有する。
【0143】
SendingToy_IDは、メッセージを送信する玩具を示す。
【0144】
ReceivingToy_IDは、メッセージを受信する玩具を示す。
【0145】
MessageTypeは、START、STOP、SAYなどのメッセージの種類を示す。
【0146】
パラメータとは、メッセージタイプに関する他のあらゆる必要な情報のことである。SAYメッセージのみが、話される(単複の)語句を識別するパラメータを有する。
【0147】
従って、メッセージの範囲は以下を含む。
[MessageID,SendingToy_ID,ReceivingToy_ID,START]
[MessageID,SendingToy_ID,ReceivingToy_ID,STOP]
[MessageID,SendingToy_ID,ReceivingToy_ID,SAY,PhraseID]
【0148】
これらのメッセージの各々は、以下の形の確認応答を生成する。
[MessageID,SendingToy_ID,ReceivingToy_ID,Ack,Parameter]
【0149】
パラメータは、SAYメッセージへの確認応答のみに使用され、語句の持続時間を指定する。コントローラユニットは、語句パラメータの持続時間を使用して、次のメッセージを送信するまで適当な時間長の間待機する。
【0150】
従って、玩具1が玩具2と通信していると仮定した場合、各メッセージの通常のイベントのシーケンスは以下の通りになる。
[MessageID,1,2,START][MessageID,2,1,ACK]
[MessageID,1,2,SAY,PhraseID][MessageID,2,1,ACK,DURATION]
[MessageID,1,2,STOP][MessageID,2,1,ACK]
【0151】
STARTコマンドは、受信側玩具にさらなる到来メッセージの受信を予想するように指示する。次に、コントローラ人形が、スレーブ玩具が使用する必要がある語句のphraseIDを含む少なくとも1つのメッセージを送信する。個々のphraseIDがスレーブ玩具へ別個に送信され、従ってこの種の複数のメッセージを送信して文章全体を構築することができる。STOPコマンドを使用して、このシーケンスにこれ以上のメッセージが存在しない旨をスレーブ玩具に指示する。
【0152】
スレーブ玩具は、メッセージを受信すると、メッセージの受信を確認応答するメッセージをコントローラへ送信する。コントローラは、START及びSTOPの確認応答に対しては直ちに会話プログラムを続行するが、SAYコマンドについては、コントローラ人形は、SAYの確認応答に対応するDURATIONと等しい遅延後に続行する。確認応答が受信されない場合、確認応答が受信されるまでメッセージが再送される。この再送は何回も行われ、その時点で人形がリセットされて会話が停止し、例えば、メッセージは1000〜2000回、2000〜5000回、5000〜10,000回又はそれ以上再送される。
【0153】
個々の語句の最後には「語句終了フラグ」も添付されて、いつ語句が終わったかをスレーブユニットに通知する。この時点で、スレーブユニットは、発話が終了したことを示すメッセージをコントローラへ送信する。コントローラは、メッセージを受信すると次のユニットに発話するように指示するが、次の発話者はコントローラであっても、又は別のスレーブユニットであってもよい。
【0154】
コントローラ玩具が戦車である場合、発話を指示する代わりに、スレーブユニットに通信される命令は、スレーブユニット戦車が動くべきであるという指図の形をとる。従って、PhraseIDは、movementIDに置き換えられる。このようにして、コントローラ戦車が戦闘などのシミュレーションを行うことになる。玩具の戦車には、これらが協調して動くことができるように、ネットワーク内に他の玩具の戦車を位置決めする手段が設けられる。この手段は、玩具が通信している位置センサを有するプレイボード、又はカメラ、トランスポンダなどの他の位置決め手段の形をとることができる。
【0155】
会話の構築
会話エンジンは、会話をオンザフライで構築する。或いは、会話を開始する前に会話全体を構築してその後メモリに記憶し、その後事実上終了まで会話が実行される。しかしながら、いずれにしても、構築される会話は特定のランダム選択に基づくことになる。
【0156】
会話はネットワーク内に存在するユニットに基づき、従って存在するユニット数及び存在するユニットの種類が制御変数として使用される。玩具が人形である場合には「わーい動物園に来たよ、さあどうしよう」のように、個々の会話の最初の部分が固定される。しかしながら、複数の開始語句が存在する。その時点以降、会話はその後ランダムに選択されることになる。コントローラユニットは、発話する最初のユニットを選択し、その後開始語句のいずれかにランダムに分岐させる。
【0157】
システムは、以下のようないくつかの異なる種類のコマンドを含む命令セットを使用できるようにされる。
・変数の定義及び変数設定
・コンテキスト参照及びスイッチング
・条件付きフロー制御
・無条件フロー制御
・発話語句
【0158】
会話の流れを制御するために多くの命令文が定義され、これらは以下の通りである。
SELECT NEXT〜次の発話するユニットを選択する。この命令文には数多くの変形が存在し、これについて以下でさらに詳細に説明する。
SWITCH〜次のユニットに切り替える。
switch speaker〜発話者ポインタを別の発話者に移動させる。
switch finish〜この命令文を使用して会話を終える。
SAY〜ユニットに何かを発言するように指示する。
SET〜この命令文を使用して、「SET pet([1,dog])などの変数を設定する。SET文を使用して現在の発話者の変数を設定し、或いはこれを使用してグローバル変数を設定することができる。
TEST〜この命令文を使用して、例えば変数が設定されたかどうか、又は分岐が使用されたかどうかをテストする。TESTが真の場合、フラグが設定される。TEST命令文には2つの形がある。
TEST EQ〜この命令文は、2つの表現が等しいかどうかをテストして等しければ肯定的なフラグを作成し、例えば「TEST EQ&ME.PET&UNDEF」は、現在の発話者のペットの変数が未定義かどうかをテストして未定義であれば肯定的なフラグを作成する。
TEST NE〜この命令文は、2つの表現が等しいかどうかをテストして等しくなければ肯定的なフラグを作成する。
BRANCH〜この命令文を使用して別の会話のセクションに分岐する。例えば、「BRANCH gorillas:」は、「Gorillas」のラベルを付けられたテーマのセクションである、「Zoo(動物園)」というテーマのゴリラセクションに分岐する。この命令文は無条件文であり、プログラムが分岐文に至ったときには常に使用される。
BRANCH_F〜TESTからのフラグに基づいて条件付きで分岐する。従って、TEST文から作成されたフラグが肯定的であるときにのみ、分岐文が使用される。
CHOOSE〜この命令文により、コントローラが進む先のラベルをランダムに選択できるようになる。この命令文は、重み付けを使用してラベルへ進む確率を制御できるという点でSET文と類似している。
CHOOSE_F〜TESTからのフラグに基づいて条件付きで選択を行う。
【0159】
ストレージ要件を削減するために、オーディオファイルはトリミングした形で記憶され、すなわち個々の音声セグメントの前後には沈黙が存在しない。より実際的な発話を作成するために、トリミングしたオーディオファイルの後に置くことができる、長さの異なるいくつかの沈黙オーディオファイルが個々の語句又は単語の間に提供される。これらのオーディオファイルは、SAY文により他のオーディオファイルのいずれかと同様に参照される。
【0160】
SET文により変数を定義して人形の各々に関連するパラメータを記憶することができ、これについて以下でさらに詳細に説明する。定義できる変数には2つの形がある。
・ローカル変数〜これらは、個々の玩具/人形に関連する変数である。ローカル変数は、個々の人形のデータセット内で作成される。人形変数は、DEFINE VARIABLE_NAME文により作成される。
・グローバル変数〜これらは、「テーマ」に関連する変数であり、個々の人形とは関連性がない。グローバル変数は、DEFINE G_VARIABLE_NAME文により作成される。
【0161】
テーマ内で定義される変数は、会話中に値が割り当てられるまで、割り当てられた値を有していない。
【0162】
変数への値の設定
会話中、定義された変数に値を設定することが必要となる。これはSET文で遂行される。以下のように、SET文は、値のセットからランダムに取り出した値で変数を設定できるようにするランダム特徴で構成される。
SET VARIABLE_NAME([w1,value1],[w2,value2],..........,[wn,valuen])
【0163】
この命令文の動作は、VARIABLE_NAMEの値を乱数の結果に基づいてvalue1,value2,..........,valuenのうちの1つに設定することである。どの値が選択されるかの確率は、重み付けw1、w2、...、wnに基づく。
【0164】
例えば、
SET COLOUR([1,red],[1,blue],[1,green])
という命令文の場合、変数COLOURを等しい確率で赤色、青色又は緑色に設定することになる。人形の変数は、現在の人形との関連において設定される。
【0165】
また、TEST文がcondition_flagの状態を作成した場合に限り、SET_F文を使用して変数を設定する。この場合、condition_flagがアクティブな場合かつこの場合に限り変数が設定される。
【0166】
コンテキスト参照及び切り替え
ポインタを使用して発話者に関する情報を記憶するとともに、コントローラ人形が他の人形を参照できるようにする。会話を構築する場合、これらを使用して理にかなった会話を作成し、以下が使用するポインタである。
前の発話者(PREV)=前の発話者のID番号
現在の発話者(ME)=現在の玩具のID番号
次の発話者(NEXT)=選択された次の発話者のID番号
【0167】
人形の会話エンジンの重要な特徴は、どの人形が現在の発話者であるかというコンテキストである。このコンテキストは、現在の人形がアクセスした変数を参照する。前の人形、次の人形、現在の人形の変数のみがアクセスに利用可能である。上記で定義したように、コンテキストの概念は3つの参照ポインタにより処理される。
【0168】
コンテキストの制御は、SELECTコマンド及びSWITCHコマンドの使用により遂行される。SELECTコマンドのいくつかの変形が存在する。これらは以下の通りである。
・SELECT NOTME〜これは、ランダムに選択された人形のグループの現在の人形以外のいずれかとなるように次の発話者を選択する。
・SELECT NEXT〜これは、ランダムに選択された人形のグループのいずれかとなるように次の発話者を選択する。
・SELECT PREV〜これは、前の発話者と同じになるように次の発話者を選択する。
・SELECT NAME〜これは、名前NAMEを有する人形を次の発話者となるように選択する。このSELECTコマンドの変形は、台本通りの会話のためのものである。
【0169】
その後、コンテキストはSWITCHコマンドの使用により変更される。SWITCHコマンドには2つの変形が存在する。
・SWITCH SPEAKER label〜これは、発話者のコンテキスト及び分岐をラベルが指定する命令に切り替える。コンテキストを切り替えると、前の発話者(PREV)は現在の発話者(ME)に等しくなり、現在の発話者(ME)は次の発話者(NEXT)に等しくなり、次の発話者(NEXT)は未定義となる。
・SWITCH FINISH〜これは、会話を終了するために使用するコマンドである。
【0170】
条件付きフロー制御
時として、会話中、フローが様々な変数の値に左右される。これは、以下のコマンドで遂行される。
・TEST EQ value1 value2〜これは、value1がvalue2に等しい場合にcondition_flagを設定する。
・TEST NE value1 value2−これは、value1がvalue2に等しくない場合にconditionflagを設定する。
・&CONTEXT.VARIABLE_NAME参照を使用することにより、value1及び/又はvalue2によって変数を参照することができる。例えば、TEST EQ&ME.NAME&PREV.NAMEという命令は、現在の発話者(ME)の名前が前の発話者(PREV)の名前と同じ場合にcondition_flagを設定する。
・BRANCH_F label〜これは、condition_flagが設定されている場合にはラベルが指定する命令に分岐し、そうでない場合には次の命令を使用する。
・CHOOSE_F([w1,label1],[w2,label2],.........,[wn,labeln])〜これは、condition_flagが設定されている場合には重み付けw1,w2,...,wnを使用してランダム選択に基づいてlabel1,label2,...labelnが指定する命令に分岐し、そうでない場合には次の命令を使用する。
【0171】
人形が別の人形に関する変数の知識を必要とする度に、TEST文を使用して、変数が未定義であるか、又は特定の値であるかの問い合わせを行う。その後、これをフロー制御に使用することができ、例えば、PETという変数が未定義の場合、人形はどのような種類のペットを飼っているかを他の人形に尋ね、変数が設定されている場合にはペットが何色かなどを他の人形に尋ねる。
【0172】
無条件フロー制御
時として、命令のフローを無条件で変更できることが必要となる。この場合、TEST文は使用されずにBRANCH又はCHOOSE文が常に実行される。これは、以下の命令文を使用して遂行される。
・BRANCH label〜これは、ラベルが指定する命令に無条件で分岐する。
・CHOOSE([w1,label1][w2,label2][wn,labeln])〜これは、重み付けw1,w2,...,wnを使用してランダム選択に基づいてlabel1、label2、...、labelnが指定する命令に分岐する。
【0173】
発話語句
会話エンジンの重要な部分は語句の発話である。これは、以下の命令文で遂行される。
SAY(phrase1,phrase2,...,phrasen)コマンド。
このコマンドは、現在の発話者(ME)である人形に語句phrase1,phrase2,...,phrasenを発声させる。
【0174】
スクリプト例
以下は短いスクリプトの例である。
DEFINE COLOUR
DEFINE GARMENT
Loop:
SET COLOUR([1,red],[1,blue],[1,green])
SET GARMENT([1,dress],[1,blouse],[1,hat])
SAY(hello my name is, &ME.NAME, and I have a, &ME.COLOUR, &ME.GARMENT)
SELECT NOTME
SWITCH SPEAKER Loop
【0175】
この例では、3色のうちの1色を選んで3着の衣類のうちの1着に合わせることにより、存在する各人形ごとに9つの異なる事柄を発言することができる。
【0176】
会話は、多重分岐を使用して構築される。個々の分岐は、テーマに関する異なる会話の領域である。例えば、「Zoo(動物園)」というテーマでは、利用可能な分岐は「Gorillas(ゴリラ)」、「Reptiles(爬虫類)」及び「Ice cream(アイスクリーム)」である。個々の分岐はこれらに関連する語句/単語を有し、その後選択肢からランダムに選択される。人形の応答は、分岐、人形の性格型、及び考えられる応答の重み付けに依存する。
【0177】
例えば、選ぶべき次の分岐を決定することが選択に必要な場合、2体(又はそれ以上)の人形が同じ行く場所を続けて選択するまで会話が続く。これにより、選ぶべき分岐を選択する前に合意が必要となるので、より現実的な会話が行われる。
【0178】
コントローラ人形が別の選ぶべき分岐を選択できるセクションに達するまで分岐内で会話が続く。この時点で、選ぶべき分岐に関して別の決定が行われる。会話の長さを制限するために、使用されていなかった分岐のみを選択に利用することができる。
【0179】
分岐、語句、単語又は次の発話者などの、ランダムに選択できる個々の変数に重み付けが加えられる。語句/単語又は分岐などがランダムに選択される場合、これらの語句/単語の分岐などが選択される確率が重み付けにより変化する。例えば、全ての語句の重み付けが1の場合、これらは全て同じ選択される確率を有する。よりリアルな会話を作成するように重み付けを調整することができる。「今日、私は自転車から落ちた」などの語句は、「今朝、私は朝食を食べた」という語句よりも生じる可能性がはるかに低い。この結果、後者の語句は、前者よりもはるかに大きな重み付けを有するようになる。従って、会話エンジンの結果、ユニットはほんの時たましか「今日、私は自転車から落ちた」と言わないようになる。
【0180】
さらなる例では、使用する重み付けを前の人形に優先させることができ、従って2つの人形間のミニ会話を誘導することになる。
【0181】
会話の長さを制限するために、テーマの任意の1つの分岐の時間が制御される。これを別の重み付けパラメータとして使用して、例えば1つの分岐で費やされる時間を短縮し、別の分岐で費やされる時間を増やすことができる。これは、無限に続く可能性なく会話の最後に到達させるのに役立つ。
【0182】
会話の長さはランダムであってもよいが、場合によっては全ての変数が設定されるまで会話が続く。例えば、PETというテーマでは、全ての人形のペットが完全に説明されるまで会話が続く。これは、全ての変数が定義されているかどうかを判定するチェックを行うことにより遂行され、すべて定義済みである場合に限り会話を最後まで許可するものである。
【0183】
現在の発話者のみが前の発話者及び次の発話者というコンテキストを有するので、いつ全ての人形の変数が設定されたかを判定することがいつでも可能なわけではない。従って、別の例では、現在のコンテキストにおける3つの人形全て、すなわち、現在の人形、前の人形及び次の人形に関して全ての変数が設定されるまで会話が続く。或いは、続けて2又はそれ以上の組の人形に関して全ての変数が判明するまで会話が続く。
【0184】
会話エンジンは、複数の人形、及び2体のジェーンという人形などの同じ種類の潜在的に複数の人形に対処することができる。ネットワークが初期化された場合、ネットワークに参加する個々の人形にネットワークノードが関連付けられる。この結果、システムは、人形の名前ではなく関連するネットワークノードを使用して人形を参照する。これにより、同じ名前の複数の人形をエラーなく参照できるようになる。
【0185】
予め会話の全体を決定し、その後人形に直接ダウンロードすることもできる。例えば、シンプソン一家(登録商標)のエピソードをシンプソン一家(登録商標)の人形のグループにダウンロードすることができる。人間が会話を生成し、或いは会話エンジンが会話を生成して後から人間が編集できるので、会話を予め決定することにより、人形が特にリアルな会話を行えるようになる。予め決定される会話を作成する際には同じ命令が使用されるが、起動されるたびに会話が同じになるようにランダム要素は除去される。
【0186】
上記の会話エンジンを独立して使用して会話を生成することができる。例えば、漫画などのテレビ番組を書く自動スクリプトに上記の会話エンジンを使用することができる。
【0187】
1つの特定の実施形態では、テーマを生成するためにテーマをスクリプトで記述し、その後コンパイラを使用してスクリプトをコンパイルする。実行時エラーチェックを行って、テーマが終わりの無い会話又はその他のエラーを生成しないことを確実にし、その後サニティチェックを行って会話が全く無意味なものでないことを確実にする。その後、オーディオファイルが録音されると、テーマを玩具にダウンロードすることができる。以下でより詳細に説明する代替の実施形態では、テーマスクリプトの生成を容易にするオーサリングツールが提供される。しかしながら、依然としてテーマ内の会話の基本原理が適用される。例えば、両実施形態には、何を発言するかを選択する同じ方法が存在する。
【0188】
人形の選択
図3に示すように、会話エンジンは発話者セレクタ218を有する。発話者セレクタは、次の発話する玩具を選択する。次の発話する玩具を選択するには、ネットワーク内の玩具のいずれかをランダムに選択する、玩具を名前(ID番号)で選択する、及び現在の発話者を選択してもう一度発話させるという3つの可能性がある。従って、次の発話者を選択する第1のプロセスは、上記の3つの可能性のいずれを使用すべきかをランダムに選択することである。次の発話者を名前で選択する場合、その玩具がネットワーク内に存在するかどうかを判定するためのチェックを行う必要がある。
【0189】
上述したように、select文が次に誰が発話するかを選択する。次の発話者を決定する場合、選択肢としては、関連する発話で応答すること、別の人形を選択して話しかけること、或いは現在の発話者に関して何かを知らせることがある。
【0190】
発話者セレクタ218内でSELECT文を使用して、次の発話者のランダム選択を開始する。或いは、SELECT文が論理を使用して次の発話者への参照を決定することができる。例えば、発話するように選択された次の人形がジェーンである場合、現在の発話者が「ジェーン、あなたの好きなペットは何?」と尋ねることができる。ジェーンが次の発話者として設定されているので、ジェーンから回答が来ることになる。以下の例でわかるように、特定のパラメータが解らなくても&文を使用して次の発話者、又は他のいずれかの一般的パラメータを参照することができる。例えば、&NEXT.NAMEは次の発話者の変数NAMEを参照するものであるが、これを使用して次の発話者の名前を発言することができる。
【0191】
人形が続けて2回発話することはできないなどのさらなる選択肢が利用可能であり、従って、例えばジェーンが犬を飼っていると発表した場合、その直後にジェーンが発話するように選択されることはない。
【0192】
次の発話する人形を選択するために同様の方法がオーサリングツールにより利用され、これについて以下でさらに詳細に説明する。
【0193】
パラメータ記憶
パラメータ記憶メモリ216は、現在の会話に関する情報を記憶する。記憶された情報は、すでに使用された語句、使用された変数、フロー制御変数、及びネットワーク内に存在する人形などのその他のこのような情報を含む。情報は、コントローラ人形内にのみ記憶される。スレーブユニットは、次の発言事項に関する情報のみを受信する。
【0194】
会話において使用された変数は、後程会話内で参照できるように記憶される。変数は、人形を記述する情報であり、これを使用して性格を差別化する。
「私の犬はFluffyという」という語句から記憶される情報は、犬及びFluffyという情報である。この変数を使用して、人形が飼っているペットの種類を設定することができる。人形が特定の変数のサブセットのみを有することができるように変数を設定することができる。例えば、女の子の人形がヘビをペットとして有することはあり得ない。
【0195】
フロー制御変数を使用して、すでに使用された分岐に関する情報を記憶する。例えば、動物園にいる場合にはゴリラを見に行くように分岐を進めることができる。この情報を記憶して、会話が動物園に戻らないようにする。
【0196】
或いは、すでに使用された語句を記憶して、会話が永遠に続かないようにする。1回の会話内で特定の単語/語句を使用できる回数に限界値を設定することができ、この限界値は1回、2回、3回又はそれ以上であってもよい。これにより、会話が過度に反復的にならないことを確実にする。
【0197】
パラメータ記憶メモリ内に設定及び記憶できるグローバル変数も存在する。グローバル変数の例には、ネットワーク内の人形の全てに影響を与えるあらゆるものがあり、例えば「外は雨が降っている」であり、又は会話内で人形がずっと居た場所である。グローバル変数には、人形のコンテキストとは無関係にアクセスできるので、テーマ内のどの時点においてもこれを使用することができる。
【0198】
テーマ/人形に関する属性を記憶するために、パラメータもオーサリングツールを使用して定義され、これについて以下でさらに詳細に説明する。手短に言えば、テーマ属性/グローバル変数はテーマ全体に関連するパラメータを記憶し、あらゆる人形がいつでもこれにアクセスすることができ、人形属性/ローカル変数は個々の人形に関連するパラメータを記憶し、前の人形/現在の人形/次の人形のみがこれにアクセスすることができる。
【0199】
人形固有のダウンロード
図4は、人形がメモリに記憶されたテーマを変更又は更新できるプロセスの概略図である。人形300は、人形の識別に使用されるID番号302を含む。人形は、USB接続を介してPC304に接続され、PCは、標準的な接続方式を介してインターネット306に接続されている。インターネットは、ダウンロード可能なテーマ310を含むウェブサイト308にPCを接続することができる。テーマは、接続された人形によって変わるという理由で、ユーザが選択できないサブテーマ312を含む。例えば、人形のID番号を使用して識別されたジャックという人形にはジルのサブテーマは提示されない。テーマは、全ての性格型に対して一般的なものである。サブテーマは、テーマの表現が異なるとともに人形の性格型に依存する点を除き、メインテーマと同一である。従って、オーディオファイルは、異なる声、(同じ意味の)異なる言い回しなど、サブテーマごとに異なる。
【0200】
或いは、人形にダウンロードされる最初の性格を使用して、後からダウンロードされた性格を最初の種類と同じになるように制限することができる。例えば、人形がジャックと設定された場合、ウェブサイトは、この人形が接続されたときにジャックのサブテーマを認識し、ユーザにジャックのサブテーマのみを提示する。ウェブサイトは、人形の名前変数、すなわちジャックにアクセスしてこれをサブテーマの名前リストと比較することによりサブテーマを認識する。
【0201】
ダウンロードしたサブテーマは、「動物園」などの選択されたテーマのスクリプト、関連する性格型、人形が会話を発声できるようにする対応するオーディオファイル、及びネットワーク内の人形が全て同じテーマを有することを確実にするために使用されるテーマIDを含む。
【0202】
PC304は、テーマを効率的な態様でダウンロードできるように、人形300とウェブサイト310との間をインターフェイス接続するようになっている。さらに、テーマは人形にのみ記憶され、従ってテーマを必要とする個々の人形はウェブサイトに接続される必要がある。従って、1人のユーザが2つの人形を有し、個々の人形に同じテーマを求める場合、ユーザは個々の人形をウェブサイトに接続して適当なサブテーマをダウンロードする必要がある。
【0203】
これとは別に、人形は常に複数のテーマを記憶することができる。人形は、同時に1つのテーマを使用して通信するが、このテーマはコントローラによりいつでも変更することができる。従って、人形は「スポーツ」というテーマを使用して、その後「動物園」というテーマの使用に進むことができる。これにより、会話をより長く継続させることができ、人形の使い勝手を拡張するさらなる組み合わせが与えられる。
【0204】
人形は全て、他の人形と同じテーマを有していないときに手短に通信できるようにデフォルトテーマを有する。デフォルトテーマは2、3の基本的な語句を含み、ユーザをウェブサイトに接続してテーマをダウンロードするように導くことができる。
【0205】
テーマが安全であることを確実にするために、人形にダウンロードが行われる前に人形の一意のID番号を使用してデータを暗号化することができる。その後、個々の人形の一意のID番号を使用してテーマ内のデータを復号化することができる。これを使用して、全ての人形がウェブサイトに接続してテーマをダウンロードすることを確実にすることができる。例えば、個々のジェーンという人形が同じサブテーマを使用したいと思っても、データは特定の人形ごとに別様に符号化されており、従ってこの特定の人形以外にとっては事実上役に立たないものである。
【0206】
性格の表現及びテーマのスクリプト記述
前述したように、個々の異なるテーマは、異なる性格を表現できるようにする様々なサブテーマを有する。テーマごとのスクリプトは異なるものであり、これを使用してこのテーマに従う様々な会話を生成する。しかしながら、全てのテーマ内の個々のサブテーマは、会話を生成するための同じスクリプトを有するが、サブテーマ内で使用される言語は異なる。これにより、同じテーマに関して複数の性格を利用できるようにすることができる。
【0207】
会話の可変性を増加させるために、同じ質問を尋ねるための複数のランダム選択法が存在する。従って、例えば、単純な質問をする複数の方法が存在し、これは、例えば「次は何をしましょうか」、「次は何をするんだい」、「次は何ですか」のようにテーマ/サブテーマに依存するものであってもよい。個々のサブテーマは、同じ物事を意味するために使用する異なる表現を有することができる。例えば、1つのサブテーマでは「こんにちは、お元気ですか?」と言うことができ、別のテーマでは「やあ、調子はどうだい?」と言う。事実上語句の意味は同じものであるが、表現、従って性格が異なる。このようにして、変化に富んだ面白い会話を作成するために、各テーマがあらゆる数のサブテーマを有することができる。このようにして、ユーザ体験が高められるとともに大量のメモリを必要としないより多様なゲームプレイが可能となる。
【0208】
性格の特徴は、同一のテーマに起因することができる。従って、同じテーマのジャックバージョンとジルバージョンとを有することが可能である。ジャックバージョンはサブテーマであり、ジルバージョンもサブテーマである。
【0209】
人形の名前、すなわちジェーンが性格型と関連しているので、ジェーンという人形により表される性格は全てのテーマについて同じであり、テーマのコンテンツのみが変化する。これにより、人形は一定のままであることができ、異なる状況でも人形が同じ様に反応できるようになる。
【0210】
或いは、人形がウェブサイトにより最初に初期化されるときの人形の名前及び人形の性格を人形のユーザが選択することもできる。これにより、ユーザが人形との関わりをより深めることができる。このとき人形の名前及び性格型が人形内のメモリに記憶され、個々の属性がIDと関連付けられ、これが例えばさらなるサブテーマをダウンロードする際に使用される。
【0211】
ダウンロード可能なテーマは、表現とスクリプトとの組合せであり、会話の種類を決定付けるものである。
【0212】
人形の美的価値観(aesthetics)及び語彙を、ターゲットオーディエンスに応じた年齢となるようにカスタマイズすることもできる。様々なテーマは、年齢に応じた等級を有することができる。これにより、例えば10代の市場向けにはヒップホップをテーマにした人形が可能となる。
【0213】
さらに、別の人形セット(これは単一の人形であってもよい)のみが使用できる語句を提供することができる。この語句が選択された場合、現在の人形が使用できることを確実にするためのチェックが行われる。この人形がこの語句を使用できない場合には別の語句が選択される。
【0214】
同様に、命令の部分を別の人形セットのみに制限して、会話にさらなるランダム性を導入することができる。
【0215】
或いは、玩具が戦車又は他のこのような玩具の形をとる。この場合の玩具の性格の表現は、会話とは対照的に動きの形をとる。例えば、1つの玩具の戦車が「防御的」性格を有し、別の玩具の戦車が「攻撃的」性格を有することもできる。
【0216】
オーサリングツール
オーサリングツールとは、複数の人形に対して様々な会話テーマを作成するために使用できるアプリケーションのことである。上述したような会話は、会話が従うことができる可能性のある分岐が多数であるため、作成にかなりの量の時間が必要とされる。従って、プロセスをより効率化するために、オーサリングツールを提供してこのプロセスを支援する。クライアントアプリケーションは、図10に示すようなPC1000又はラップトップ1002などのパーソナルコンピュータなどで実行されるが、複数のユーザが同じテーマに取り組めるように、或いは単一のユーザが異なる場所から同じテーマに取り組めるように、データはサーバ1004上に記憶される。サーバ上では、データベースをクライアントアプリケーションとインターフェイス接続するためのウェブサービスが行われる。クライアントアプリケーションは、インターネット306を介してサーバ1004と通信する。クライアントアプリケーションはウェブサービス、ひいてはデータベースへの要求をXMLを使用してフォーマット化し、SOAPプロトコルを使用してデータを送信する。
【0217】
オーサリングツールの概要
図11は、オーサリングツールの概要を示す図である。テーマ開発者が玩具のために単純かつ効率的にテーマを出力できるようにするためにユーザインターフェイス1100が設けられる。設けられたユーザインターフェイスを使用して、開発者は以下のステップに従う。
1. テーマ生成エンジン1102を使用してテーマを作成
2. 玩具生成エンジン1104を使用してこのテーマに合わせた玩具を作成
3. コンテキスト入力ウィンドウ1106を使用して個々の玩具ごとに複数のコンテキストを作成
4. コード生成エンジン1108を使用して命令(「C」コード)を出力
5. 辞書生成エンジン1110を使用して個々の人形ごとに記録すべき語句の「辞書」を出力
6. 必要であれば、PCでテーマをテストする際に使用するシミュレーションエンジン1111を使用してシミュレーションとしてテーマを出力
【0218】
本明細書で使用する場合、用語コンテキストは、例えばテーマ別会話内の個々の位置ごとに、人形が何を発言するか、またどの人形が次に発話するかを決定する少なくとも1つのコンテキストが存在するように、テーマデータ内のコンテンツのサブセットを意味する。コンテキストは、テーマ/人形の属性を設定することもできる。
【0219】
コード生成エンジン及び辞書生成エンジン1110を使用して命令及び「辞書」がそれぞれ出力されると、記録手段を使用して語句が記録され、レコーダ1112を使用してオーディオファイルが作成され保存される。レコーダは、特定の作成中のテーマに必要な表現データの各々を生成するように関係者に促す。その後レコーダは、適当な表現データに対応するID番号を個々のオーディオファイルに割り当てる。使用時には、玩具のプロセッサが操作するコードにより、適当なID番号を使用してオーディオファイルが参照され、玩具のスピーカを使用して出力される。
【0220】
基本命令セット1114(玩具のプロセッサ用ファームウェア)が(コード生成エンジン1108により生成される)テーマ別命令セットと組み合わされ、テーマに従って玩具を動作させるために、コンパイラ1116を使用して玩具のプロセッサが使用するバイナリファイルにコンパイルされる。上述した先の実施形態では、基本の命令/ファームウェアのセットが玩具のプロセッサメモリに位置し、テーマが変更又は更新されるたびにテーマ別命令セット及びオーディオファイルのみが人形にダウンロードされた。
【0221】
命令がコンパイルされると、コンバイナエンジン1120を使用してこれらをオーディオファイルと共にバンドルし、個々の人形にダウンロードできるようにする(個々の人形は同じテーマ別命令を含む個別のダウンロードを有するが、これには個別のオーディオファイルが含まれる)。
【0222】
オーサリングツールは、テーマを記憶したサーバ1004及びデータベース1122へのアクセス権を有する。テーマは、テーマ開発者により確定されたかどうかに応じて異なるフォーマットで記憶される。未確定のテーマは、オーサリングツールが情報に容易にアクセスできるように記憶され、これは、テーマ名、玩具名、コンテキストなどの参照事項を含むデータベースの形をとる。テーマ開発者がテーマを確定させると、テーマは、未確定フォーマットに加え上述したような命令セットとしても記憶される。これにより、確定したテーマを修正するとともに、先に確定したテーマに基づいて新しいテーマを作成できるようになる。玩具のユーザが自分の玩具/人形1126にテーマ別データをダウンロードできるようにするウェブサイト1124が提供される。
【0223】
オーサリングツールは、上述したようなものを含むいくつかの機能を有する。
1)これを使用して、テーマ生成エンジン1102を使用して複数の人形のためのテーマ別会話を作成及び編集することができる。
2)これを使用して、シミュレーションエンジン1111を使用して会話プロセスをシミュレートし、結果として得られるテーマ別会話のテキスト出力を作成することができる。
3)これを使用して、辞書生成エンジン1110を使用して個々の人形に関する記録すべき全ての語句のリストをまとめることができる。
4)これを使用して、コード生成エンジン1108を用いて「C」コード出力(命令セット)を作成することができ、その後これをコンパイルして修正済みプロセッサファームウェアとリンクさせ、ダウンロードの準備が整っている個々の人形のためにバイナリデータファイルを作成することができる。
【0224】
会話データの入力
オーサリングツールのアプリケーションユーザインターフェイスを図12a〜図15に示す。個々のインターフェイスのウィンドウは、入力ウィンドウとインターフェイス接続するか、或いは次のインターフェイスウィンドウへ進むかのいずれかを行うための数多くのナビゲーションボタンを有する。ユーザインターフェイスは、プロセッサ1150及び関連メモリ1152を利用してテーマ開発者にユーザインターフェイスの様々な態様を表示し、受信機1153を利用してユーザが入力したコンテンツを受信する。プロセッサ1150及びメモリ1152は、PC1000又はラップトップ1002内に位置する。本明細書で使用する場合、用語コンテンツは、スクリプトデータ、表現データ、テーマデータ、人形データ及びユーザがオーサリングツールに入力できる他のあらゆるデータ型を意味する。
【0225】
図12aは、第1のインターフェイスウィンドウであり、以下の選択肢を有する。
テーマの追加(1100):これは新しいテーマを作成するために使用され、通常は使用される最初の選択肢である。図12b及び12cに示すように、以下の入力を必要とするテーマフォームを立ち上げる。
名前:テーマの名前。これは、spoken_text_stringのためのプレースホルダである。
人形の数:このテーマ内でサポートされる人形の総数
説明:テーマの説明
テーマ属性:位置などの、テーマのグローバル属性
人形属性:気分などの、人形のローカル属性
【0226】
これらの入力は、上述したような会話の構築で必要とされる入力と同等のものである。オーサリングツールの実施形態を参照しながら説明したように、テーマ及び人形属性は、上述のようにそれぞれグローバル変数及びローカル変数と同等のものである。しかしながら、オーサリングツールは、構造化された様々な入力ウィンドウをテーマ開発者に提供して情報を効率よく入力できるようにする。
【0227】
さらに詳細には、テーマ属性は、名前及び任意に値から成る。値は、spoken_text_stringのためのプレースホルダであってもよい。以下で説明するように、spoker_text_stringは、テーマが確定した後に作成される。spoken_text_stringとは、会話中にアクセスできるサウンドファイルのことである。例えば、テーマが動物園内に位置するとした場合、考えられるテーマ属性は、位置=「動物園」であり、人形がこれを使用して、例えば「やあ、動物園は本当に楽しいな」と言うことができ、この場合「動物園」という単語は、「位置」というテーマ属性を使用してアクセスされたものである。
【0228】
人形属性は、特定のテーマにおける個々の人形が属性に値を必要とするときにインターフェイスウィンドウ内に作成される。例えば、属性の設定が「気分」である場合、個々の人形のこの属性に「楽しい」「悲しい」、「怒っている」などの値が与えられる。会話中、会話エンジンは、人形属性(ローカル変数)のいずれかにアクセスしてその属性を会話で使用することができる。
編集(1202):これは既存のテーマを編集するために使用される。例えば、テーマAlon#1(1206)を選択して編集を押すことにより、ユーザがAlon#1のテーマの詳細を編集できるようになる。
除去(1204):これは選択したテーマを削除するために使用される。
【0229】
図12aは、3つのテーマ1208、1208及び1210が作成された後のウィンドウを示している。個々のテーマがテーマの詳細の概要を示しており、これにはテーマの短い説明、テーマに関連する人形の数及びそのID番号が含まれていることがわかる。テーマのフォームに入力された情報は、その後出力命令を生成する際に検索するためにサーバ1004内のデータベース1122に記憶される。
【0230】
テーマが作成されると、ユーザは次のウィンドウへ進んでテーマ内の人形を作成する。図13aは人形生成ウィンドウを示しており、ユーザが「人形追加」ボタン1300を押すと、図13bに示すウィンドウが表示される。このウィンドウを使用することにより、人形を作成し、名前をつけ、短い説明を付けることができるようになる。
【0231】
図13a及び図13bに示すウィンドウを使用して、必要なだけの人形を作成することができる。しかしながら、作成できる人形の数は、その特定のテーマに関して前もって決定した人形の最大数により制限される。これらの同じウィンドウを使用して既存の人形を編集することも可能である。このようにして個々の人形を作成することによりサブテーマが生成される。上述したように、サブテーマは個々の特定の人形のテーマである。例えば、会話を記録するために使用する音声は玩具ごとに異なり、コンテキストデータも異なる。この場合も、人形のフォームに入力された情報が、その後出力命令を生成する際に検索するためにサーバ1004内のデータベース1122に記憶される。
【0232】
図14は、テーマ内の個々の人形に対して異なるコンテキストを入力するコンテキスト定義ウィンドウを示している。図14に示すように、位置100に2つのコンテキスト1400及び1402が定義されており、1つはDoll#1のためのものであり、1つはDoll#2のためのものである。従って、会話内で位置100がアクセスを受けた場合、上述したような方法により人形が選択され、対応するコンテキストがアクセスを受ける。個々のコンテキストは、人形が何を発言すべきか、及び次にどの人形が発話すべきかに関する情報を保持する。この結果、会話を作成するための構造をテーマ開発者に提供することにより、上述したような会話構築のプロセスが容易化される。テーマ開発者は、もはやテーマ自体をコード化する必要はなく、むしろオーサリングツールが、テーマ開発者の入力に応じて必要なコードを生成する。
【0233】
図15は、テーマ内の個々の位置のためのコンテキスト生成ウィンドウを示す。図15に示す例では、これは位置100及びDoll#1のためのコンテキストである。個々のコンテキストは以下の情報を必要とする。
・Position(1500)〜図14に示すコンテキスト定義ウィンドウ内で新しいコンテキストが作成される際にオーサリングツールにより自動的に作成されるこの位置を表記するテキスト文字列。これは個々のコンテキスト行にとって便利なラベルである。これはいずれのテキストであってもよいが、デフォルトはコンテキスト行に100から始めて順に番号を付ける。テキストラベルの使用目的は、会話を作成及び編集している間に明暸さを助長することである。「C」コードの出力が必要な場合、全ての位置ラベルが、コンテキスト位置に対応するyoume_conversation_struct_t構造(この及び本明細書で説明するその他の構造に利用されるCコード命名規則)の配列の形のインデックスに変換される。
・Statement(1502)〜人形が発言できる文のリストであり、ランダム選択プロセスで使用する重み付けを伴う。文は、spoken_text_stringsである語句のリストを含む。これは、会話内のこのコンテキストポイントにおいて特定の人形が発言できる文のリストである。個々の文は角括弧で囲まれ、個々の文をコンマで分離し(例えば[statement1],[statement2],[statement3])、又は図15に示すようにコンテキスト入力ウィンドウの別々の行に入力することができる。文は、ランダム選択用の重み付け及び語句のリストから成る。この場合の重み付けは、SET制御、BRANCH制御又はCHOOSE制御などの条件付きフロー制御を参照しながら上述したような重み付けと同様の態様で機能する。個々の語句は、明示的なspoken_text_string、又はテーマ属性又は人形属性への参照のいずれかであり、例えば、文はテーマの位置又は人形の気分を参照することができる。明示的spoken_text_stringsは、(「こんにちは、お元気ですか」などの)2重引用符内のテキストとして定義される。参照は以下の形を取る
○ theme.attribute テーマ/グローバル属性に関する
○ me.attribute 現在の発話者人形属性に関する
○ prev.attribute 前の発話者人形属性に関する
○ next.attribute 次の発話者人形属性に関する
○ name.attribute 名前の付いた人形/ローカル属性に関する
以下は、Statementsフィールドへの有効な入力例である。
○ ブランク〜これは、この時点でこの人形による発言が存在しないことを意味する。
○ [1,“hello how are you”]〜この時点で「今日は、お元気ですか」と特定された1つの文のみがこの人形により話される。
○ [1,“hello”,prev.name、how are you]〜この時点で「今日は」の次に前の発話者名、その後「お元気ですか」がこの人形により話される。
○ [1,“hello”][1,“hi”]〜等しい重み付けの2つの文。default_say_procedureが使用された場合、この時点で50%の時間は「今日は」がこの人形により発言され、残りの50%の時間は「やあ」が発言される。
○ [3,“hello”][1,“howdy”]−等しくない重み付けの2つの文。default_say_procedureが使用された場合、この時点で75%の時間は「今日は」がこの人形により発言され、残りの25%の時間は「よう」が発言される。
・Say(1504)〜発言するために使用される手順。ブランクにした場合、default_say_procedureが使用される。default_say_procedureは、重み付けを使用して利用可能な文の1つをランダムに選択する。或いは、ドロップダウンリストを使用して、異なる言動を提供するあらゆる利用可能な用意されたsay手順を選択することができる。ドロップダウンリスト内に上述したようなsay手順を提供することができる。最終的に、特別な動作が必要な場合、必要なsay手順の「C」コードをここに入力することができる。
・Transition(1506)〜次の人形を選択するために使用される手順。NOTME、ANY、ME、PREV、FINISHを含む上述の手順のいずれであってもよく、或いは人形の名前の1つ又は何らかの「C」コードをここに入力することができる。ブランクにした場合、NOTME transitionであるdefault_transition_procedureが使用される。これとは別に、利用可能なtransition手順のプルダウンリストが存在する。このリストは、以下の用意されたtransitionで構成され、(各々について詳細に上述したような)ドロップダウンメニューを介してオーサリングツール内でアクセスされる。
○ NOTME 現在の発話者を除くいずれかの人形をランダムに選択する。
○ ANY いずれかの人形をランダムに選択する。
○ ME 現在の発話者を選択する。
○ PREV 前の発話者を選択する。
○ Doll’s name この人形を選択する。
また、特別なtransition動作が必要な場合、必要なtransition手順の「C」コードをここに入力することができる。
・Next(1508)〜ランダム選択プロセスにおいて使用される次にどこへ行くかについての分岐選択のリストであり、重み付けを伴う。これは、次のコンテキスト位置のための分岐選択のリストである。個々の分岐選択は角括弧で囲まれ、コンマで区切られる。分岐選択自体は位置ラベルのリストから成り、ランダム選択のための重み付けを伴う。上述したようなBRANCHコマンドとフォーマットが類似する。以下は、(各々について詳細に上述したような)このフィールドへの有効な入力例である。
○ [(1,label1),(1,label2)]〜等しい重み付けの2つのラベルの選択を含む1つの分岐選択。
○ [(1,label1),(1,label2)]![(2,label3),(3,label4)]〜2つの分岐選択、最初の方は等しい重み付けの2つのラベルの選択を含み、後の方は重み付け2及び3の2つのラベルの選択を含む。
・Branch(1510)〜分岐に影響を与えるために使用される手順、フォーマットは、会話構造を参照しながら上述したものと同じである。そうでなければ、何らかの「C」コードをここに入力することができる。このフィールドは、分岐手順を指定して分岐選択を処理するために使用される。ブランクにした場合、default_branch_procedureが使用される。default_branch_procedureは、Nextリスト内の最初の分岐選択を使用し、与えられた重み付けを使用してラベルの1つをランダムに選択する。その後、コンテキストは、その位置ラベルとして選択されたラベルを有するコンテキスト行に変更される。これとは別に、利用可能な用意された分岐手順のプルダウンリストが存在する。このドロップダウンリスト内に上述したような分岐手順を提供することができる。
・Attributes(1512)〜属性、seMlag、及びランダム選択のための値及び重み付けのリスト。このフィールドは、このコンテキストポイントにおいて値で設定を行うためのいずれかの属性を指定するために使用され、すなわちテーマ開発者は、「気分」という人形属性をハッピーに設定することができる。ブランクにした場合、属性は設定されない。設定される個々の属性は、角括弧で囲まれ、コンマで区切られる。角括弧内では、属性が指定された後に、属性を一旦設定すべきか、又はリセットすることができるかを指定するset_flagが続き、その後ランダム選択のための値及び重み付けのリストが続く。属性フィールドは、上述したようなSETコマンドの同等物である。以下は、属性フィールドへの有効な入力である。
○ ブランク 属性は設定されない。
○ [me.attribute1,set,(1,“hello”)] 1つの属性が設定され、未だ設定されていない場合、spoken_text_string“hello”の値に「ハロー」が設定される。
○ [me.attribute1,reset,(1,“hello”)(1,“hi”)],[me.attribute2,set,(1,“peter”)(1,“paul”)]
2つの属性が設定される。最初の属性は、すでに設定されていたとしても「ハロー」又は「ハイ」に設定される。次の属性は、未だ設定されていていない場合に「ピーター」又は「ポール」に設定される。
・Set(1514)〜属性値の設定に影響を与えるために使用される手順。ブランクにした場合、default_set_procedureが使用される。default_set_procedureは、set_flagを考慮して個々の指定された属性を適当な値の選択に設定する。「set」のset_flagは、まだ設定されていない場合に限り属性を設定できることを意味する。「reset」のset_flagは、属性を何度でもリセットできることを意味する。これとは別に、利用可能な用意されたset手順のプルダウンリストが存在する。最終的に、何らかの特別なカスタム設定した動作が必要な場合、必要なset手順の「C」コードをここに入力することができる。
【0234】
上述したように、Statements、Say、Transition、Next、Branch、Attributes、及びSetのフィールドが個々の人形ごとに反復される。Say、Transition、Next及びBranchのフィールドは全て、玩具/人形間の対話方法に寄与するパラメータであり、これらの全ては会話構造を参照しながら上述したようなコマンドと同等である。
【0235】
会話が完了するまで、Contextオプションを繰り返し使用して、会話にコンテキスト行を追加する。
【0236】
個々の人形及び個々のコンテキストの定義を含め、テーマが完了すると、オーサリングツールはセーブ機能を提供する。このオプションは会話を保存するために使用され、一例として以下のディレクトリを作成する。
c:\youme\themes\theme_name
c:\youme\themes\theme_name\doll_name〜個々の人形ごと
c:\youme\themes\theme_name\doll_name\audio〜個々の人形ごと
【0237】
従って、1つのテーマに必要なファイルは、全てマスターディレクトリフォルダ「theme_name」内に保存される。個々の人形ごとにサブフォルダを作成して、個々の人形のダウンロードを効率的に管理できるようにする。最終的に、個々の人形のサブフォルダは、この人形に必要なオーディオファイルを記憶するためのフォルダを有する。
【0238】
このオプションは以下のファイルも作成する。
c:\youme\themes\theme_name\theme.txt〜テキストファイルとしてテーマデータを含む。
c:\youme\themes\theme_name\doll_name\doll.txt〜テキストファイルとして人形データを含む。
c:\youme\themes\theme_name\doll_name\audio\A00001.wav
c:\youme\themes\theme_name\doll_name\audio\A00002.wav
...
...
...
c:\youme\themes\theme_name\doll_name\audio\A00010.wav
...
...
c:\youme\themes\theme_name\doll_name\audio\Annnnn.wav
【0239】
作成されるwavファイルは、個々の人形ごとにテーマ内で定義されるspoken_text_stringsの各々のプレースホルダである。spoken_text_stringsには、A00001.wavから開始する順番でA0000n.wavというファイル名が割り当てられる。ファイル名の中で使用されるnは、「C」コードの出力が必要な場合の語句のインデックスとしても使用される。1つの例では、レコーダ(1112)が、必要なspoken_text_stringを上演させるように関係者を促し、その後、次のspoken_text_stringで関係者を促す前に正しいファイル名でファイルを自動的に保存する。
【0240】
また、オーサリングツールは、会話に対応する「C」コードを生成するようになっている。「C」コードの大部分は予め定義され(基本命令セット)、玩具/人形のプロセッサのためのオペレーティングシステムとして機能する。会話に対応する「C」コード(テーマ別命令セット)が出力されると、予め定義された「C」コードと組み合わされ(図11を参照)、その後これがコンパイルされて人形又はPC内のプロセッサを操作するのに適したバイナリファイルが作成される。新しいテーマが作成されるたびに人形にオペレーティングシステム/ファームウェアを組み込むことにより、必要なときにいつでも人形の機能を単純かつ効率的に変更できるようになる。
【0241】
2種類の「C」コードを出力することができる。
1.ウィンドウ用「C」コード〜この「C」コードは以下の形で保存することができる。
c:\youme\themes\theme_name\theme_simulation.c、及び
c:\youme\themes\theme_name\theme_simulation.h
後でこのコードをコンパイルしてウィンドウベースの会話シミュレーションエンジンとリンクさせることができる。結果的に得られるアプリケーションを、c:\youme\themes\theme_name\simulation.exeの形で保存することができる。シミュレータにより、ユーザがどの人形を現在の及びアクティブな人形と考えるべきかを指定できるようになる。その後、シミュレータは、実際の人形で行われそうな形で会話例をシミュレートする。シミュレータは、アクティブな人形の1つを現在の発話者となるようにランダムに選択し、この人形の最初のコンテキスト行を処理する。その後、個々の新しい行を順に実行して、どの人形が発話しているか、及びこれらが何を発言しているかを出力する。シミュレータは、会話が終わるまで継続する。
2.プロセッサ用「C」コード〜後でこのコードをコンパイルし、修正済みのプレイヤとリンクさせて個々の人形ごとのバイナリデータファイルを生成することができる。これらの「C」コードファイルは、個々の人形ごとに以下の形で保存することができる。
c:\youme\themes\theme_name\dollname\youme_chat.c、及び、
c:\youme\themes\theme_name\dollname\youme_chat.h
結果的に得られるバイナリデータファイルを以下の形で保存することができる。
:c:\youme\themes\theme_name\doll_name\player.sb.
【0242】
バイナリデータファイルは、個々の人形において会話を実行するために必要な情報セット全体を含む。このバイナリデータファイルはプロセッサ用ファームウェアを含むので、ファームウェアを更新する追加のプロセスを必要とせずに、人形の機能に追加の特徴を組み入れることができる。
【0243】
人形用のwavファイルとして正しい語句を記録するために、図11に示すように、個々の人形ごとに全ての異なる語句(spoken_text_strings)のリストを作成し、辞書生成エンジン1110を使用して出力し、これが個々の人形にとって必要な語句の辞書となる。辞書生成エンジン1110は、サーバ1004内のデータベース1122と通信し、データベース内に記憶されたテーマに関する情報に基づいてリストをコンパイルする。この辞書は、事実上、表現/文と、この表現/文に割り当てられたID番号との間のルックアップテーブルである。
【0244】
個々の人形が使用する語句は、個々のコンテキスト行のStatementsフィールド及びAttributesフィールド内で定義される。これらは明示的に定義されたspoken_text_stringsであってもよく、或いはカスタム属性への参照であってもよい。明示的なspoken_text_stringが定義されるときには常に、A00001.wavから開始する順番のA00xxx.wavなどのファイル名がこれに割り当てられる。番号xxxもまた語句のインデックスである。spoken_text_stringsのリストは以下のファイル内に保存することができる。
c:\youme\themes\theme_name\phrases.txt〜これは、このテーマで使用される全ての語句のリストを含む。
c:\youme\themes\theme_name\doll_name\phrases.txt〜これらは、個々の人形が使用する全ての語句のリストを含む。
【0245】
これらのファイルは、以下のフォーマットのテキストを含む。
A00xxx テキストとしての関連語句
【0246】
このようにして、語句のリストを順番に記録し、適当なファイル名で保存し、人形内で使用するための、或いはPCが仮想人形として機能する場合にはPC内で使用するためのダウンロードに向けて準備することができるので、数多くのwavファイルを作成するプロセスが単純化される。
【0247】
図12aに示すように、ファイルを生成するプロセスは、ボタン1212「ファイルの生成」により起動される。ユーザは、完了している適当なテーマを選択してボタン1212を押す。これにより、上述したようなファイルが生成される。その後、ファイルのバンドル全体が人形にアップロードされ、このバンドルは、テーマ及び付随するオペレーティングシステムのバイナリファイル、発話のためのサウンド(wav)ファイル及びプロセッサ動作コード(ファームウェア)を含む。
【0248】
上述したように、youme_conversation_struct_tという会話構造の配列が会話の主な制御データである。概略的には、コントローラ人形において会話が操作される場合、最初の人形に関するこの配列のインデックス1により指定されたコンテキストにおいて会話エンジンが起動する。その後、以下の行動を行う。
1.現在のコンテキストのtransition手順を呼び出して、どの人形が次になるかを決定する。
2.現在のコンテキストのset手順を呼び出して、コンテキスト内で指定されたあらゆる属性の値を設定する。
3.現在のコンテキストのsay手順を呼び出して、コンテキスト内に指定されたデータに従ってどの文を発言すべきかを選択する。この結果、現在の人形がコントローラ人形でない場合、遠隔の人形との無線通信が行われる。いずれにせよ、エンジンは手順の前にオーディオ出力が完了するまで待機する。
4.コンテキストのbranch手順を呼び出して、次のインデックスを選択し、使用する会話配列に入れる。
5.前の人形ポインタ(prev)を現在の人形ポインタ(me)と同等に設定する。
6. 現在の人形ポインタ(me)を次の人形ポインタ(next)と同等に設定する。次の人形ポインタは、ステップ1において設定済みである。
7.その後、新しいインデックス及び新しい人形で再びステップ1から開始し、ステップ4の1つにおいてFINISH分岐にぶつかるまでこのプロセスを継続する。
【0249】
USB通信ドングル
さらなる実施形態では、PCが本明細書で説明するような玩具と無線で対話できるようにするUSB通信ドングルが提供される。図16は、PC304に取り付けられ、人形100と無線通信しているUSB通信ドングル1600の概略図である。ドングルは、無線モジュール104と、IR/RF送/受信機212と、インターフェイス1602とを含む。これらの構成要素は、インターフェイス1602を除き、上述したような人形100内に含まれるものと同じものである。しかしながら、PC304は、人形100が有するような独立したプロセッサを有するドングルの代わりにプロセッサ1604として利用され、従って事実上、PCが物理的人形100と通信できる仮想人形になる。仮想人形には、現実の人形と同様の外観を有することができる、PCのモニタに表示されるアニメ化したアバターが提供され、これによりアバターのアニメーションが人形の発話と同期化される。会話を実行するために、PCは、玩具のプロセッサをエミュレートするためのエミュレータをメモリ1606内に記憶している。或いは、上述したように、オーサリングツールがPCベースの仮想人形の特定のコードを出力する。いずれにせよ、テーマ別会話データを使用し、玩具/人形のファームウェアをエミュレートするPC上で実行されるアプリケーションを使用して会話が実行される。玩具/人形の発話は、PCのスピーカを介して出力される。
【0250】
インターフェイス1602はUSB接続であり、無線通信ドングル1600をPC304に接続するための効率的な方法を提供する。ドングルが使用する無線通信プロトコルは、本明細書で説明するような人形間で使用されるものと同じものであり、すなわちIEEE802.15.4.である。
【0251】
ユーザは、ウェブサイトに接続すると、USB通信ドングルを使用して物理的人形とウェブサイト内でアニメ化された仮想人形との間の会話を容易化することができる。このようにして、1人のユーザが、複数の物理的人形を必要とせずに人形の会話エンジンの機能を使用することができる。また、仮想人形は、複数の物理的人形との会話に参加することができる。2人のユーザが各々USB通信ドングルを取り付けたラップトップコンピュータを有する場合、仮想人形が他の仮想人形と対話することもできる。
【0252】
ゲームのプレイ
さらなる実施形態では、玩具が子供とゲームをプレイするようにもなっている。例えば、ヘビとはしご、ネズミ取り、ルード又はサイコロを使用してプレイすることができる他のあらゆる偶然に基づくゲームなどのボードゲームを玩具がプレイすることができる。
【0253】
玩具には、サイコロをシミュレートするために使用される乱数発生器が設けられる。さらに、玩具は、駒がボードに沿って進むことができるスペースの数を計数するようになっている。玩具は、駒を必要なスペースの数だけ移動させるように音で子供に合図する。子供が駒を移動させると、子供はボタンなどを押すことにより、次の玩具/子供の番であることを玩具に示す。或いは、ボードは対話型でもあり、プレイボードからカウンタの位置に関する情報を受信するセンサなどを含む。プレイは、勝者が出るまでこのように進行する。
【0254】
図5は、ゲームエンジン400をさらに含むコントローラ玩具200の概略図である。残りの構成要素は、図2及び図3で説明したものと同じである。ゲームエンジン400は、ボードメモリ402と、乱数発生器404と、位置RAM406と、確認応答受信機408とを含む。
【0255】
ボードメモリ402は、ヘビとはしご又はルードなどのボードゲームのレイアウトに関する情報を記憶する。乱数発生器は、サイコロをシミュレートするために使用され、数字1、2、3、4、5及び6(又は、ゲームに適した他のいずれかの数字セット)を生成するようになっている。位置RAMは、この場合はコントローラ及び3つのスレーブであるが、プレイヤの各々のボード上の位置に関する情報を記憶するために使用される。ボードメモリ及び仮想サイコロの転がりとともにこの情報を使用して、駒が移動するのに適した位置の数を計数し、駒が移動するスクウェアにはしごの底部又はヘビの頭部などの何らかの特別な関連性があるかどうかを識別する。
【0256】
会話エンジン204は、ゲームエンジンから得られる情報を利用してスペースの数を計数し、例えば最初の位置がスクウェア13であり、仮想サイコロを転がして4が出た場合、人形が「4が出て、14、15、16、17と移動したよ」)とスピーカ210を介して発声する。この例では、スクウェア17がヘビの頭部とした場合、人形は「あらら、スクウェア6までヘビを滑り落ちてしまった」と発声するであろう。計数メカニズムは、テキストを適当な回数循環し、そこで位置RAM406内の最終位置を思い出す。従って、例えば仮想サイコロを転がして4が出た場合、数字のリストに4回アクセスして最終結果を出す。
【0257】
また、人形は、子供が起動する外部乱数発生器から情報を受信することもできる。このようにして、子供が人形と一緒に遊ぶことができ、人形は、子供を含むプレイヤの駒の全ての経過を追っていつ勝者が出たかを判定することができる。
【0258】
図6は、ゲームをプレイするプロセスのフロー図である。ゲームはユーザにより開始され(ステップ500)、コントローラ人形がプレイヤの数を判定するためのチェックを行う(ステップ502)。次に、コントローラ人形が乱数発生器などを使用して最初のプレイヤを決める(ステップ504)。次に、コントローラ人形が最初のプレイヤのために仮想サイコロを転がし(ステップ506)、或いは子供が最初のプレイヤの場合には、コントローラ人形が子供にサイコロを転がすように求める。次に、コントローラ人形は、プレイヤにカウンタ/駒をボード上の対応するスクウェアの数だけ移動させるように指示し(ステップ508)、その後子供がカウンタを移動させたという確認応答を待つ(ステップ510)。ステップ512において、コントローラ人形は、子供にカウンタが移動したという確認応答を促すまで、2秒、3秒、5秒又は8秒などの所定の秒数待つ。コントローラ人形が確認応答を受信すると、プレイヤがゲームに勝ったかどうかを判定するためのチェックが行われる(ステップ514)。プレイヤがゲームに勝っていなかった場合、プレイは次のプレイヤへ進み(ステップ516)、プレイヤが勝つまで(ステップ518)ステップ506からプロセスが続く。
【0259】
ゲームエンジンは、上述した方法であらゆるルールに基づくゲームをプレイするようになっている。
【0260】
或いは、システムがC言語などの従来のプログラム言語を実行し、より複雑なアルゴリズムを実行してチェスなどのより複雑なゲームをプレイすることができる。上述したものと同じ言語を使用して会話を生成し、またこの言語がC言語プログラムから参照されるであろう。
【0261】
このような玩具及び人形は子供に異なる対話の機会を与え、子供たちのプレイを向上させる。
【0262】
テーマの例
付録Iには人形間のテーマ別会話の4つの例を提供する。これらの例は、会話を構築する異なる方法を提供するものである。動物園というテーマとペットというテーマのランダムに生成された会話の2つの例、X氏というテーマの台本通りの会話の1つの例、及びヘビとはしごというテーマによるゲームをプレイするというテーマの1つの例が存在する。
【0263】
ユニットのプロセッサ102を、会話コンパイラ206、会話データベース208及びパラメータ記憶装置216などのその他のモジュールとともに使用してテーマ内のスクリプトを解釈する。例えば、変数が定義された場合、パラメータ記憶装置内でメモリが割り当てられる。会話が開始されるたびに、パラメータ記憶装置内で変数が割り当てられる。これによりテーマを変更すること、すなわち動物園からペットへの変更ができるようになり、また前の会話からの変数と衝突することなく適当なメモリリソースに新しい変数を割り当てできるようになる。さらに、PREV、NEXT及びMEなどのパラメータにもパラメータ記憶装置内のメモリが割り当てられる。これにより、SELECT文がスクリプト内のパラメータを参照できるようになる。
【0264】
SAY文を使用する場合、コントローラ人形は、無線モジュール及び送信機を使用して関連する人形へコマンドを送信するために上述の通信プロトコルを使用するか、或いはコントローラ人形が現在の発話者である場合にはコントローラ人形の関連するモジュールを利用するかのいずれかを行う。発話するために必要な人形内の発話コンパイラ206を利用して、発話データベース208内の適当なオーディオファイルにアクセスする。例えば、動物園というテーマ内のSAY文を含む最初の行は、「SAY(i think we’ve seen everything now,p03,lets go home)」である。この文は、会話データベース内のオーディオファイルへの3つの参照で構成される。これらの参照は、「i think we’ve seen everything now」、「p03」、及び「lets go home」である。これらはすべてオーディオファイルを参照するが、「p03」という参照は特定の長さの休止を意味する。この休止は、オーディオファイルに適当に間隔をあけるために使用される空白のオーディオファイルである。その後、会話コンパイラ206がスピーカ210を使用してオーディオファイルを再生する。
【0265】
付録I内のテーマ例は、先に定義した文の使用のさらなる例を提供する。いずれの場合にも、プロセッサがコードを解釈し、適当なモジュールを利用して文を実行する。
【0266】
代替の実施形態では、本明細書で説明するように、プロセッサが内蔵インタプリタを使用せず、代わりに個々のテーマが、プロセッサが正しく機能できるようにする全てのプロセッサ制御命令を含むバイナリデータファイルで構成される。これにより、事実上必要なときにはいつでもプロセッサのファームウェアを新機能に更新できるようになる。以下で提供するテーマの例は、全てオーサリングツールを使用して生成することができる。しかしながら、玩具/人形を制御するための命令は、コンパイルされた「C」コードのバイナリファイルとなるであろう。
【0267】
プロセッサ及び関連電子部品
図8は、図2及び図3に示す概略図の潜在的生産バージョンのための回路図及びパーツリストの概略を示しており、付録IIが図8内の構成要素について詳述する。図9は代替の回路図の概略を示しており、付録IIIが図9内の構成要素について詳述する。生産回路に含めることができる選択肢が存在し、これらについては後で説明する。
【0268】
回路は以下を含む。
・Jennic無線コントローラ
生産回路はJennicICを使用し、RF回路を含み、ファームウェアとデータとを組み合わせて単一の大型フラッシュメモリICにする。Jennic無線コントローラは、例えばZigbee無線通信プロトコルを使用して人形間で通信を行うことができる。
・充電器
生産回路は、USBポートから充電するように特別に設計された部品を使用し、充電中に回路に給電も行う。
・音声増幅器
生産回路上の音声増幅器はD級オーディオアンプである。このアンプは非常に効率がよい(〜80%)。
【0269】
技術的選択肢
このセクションでは、図8の生産回路に含まれていない考えられる選択肢について説明する。
・USBインターフェイス
FTDI FT245RQ
この構成要素は、主にUSBドライバソフトウェアを備えたすぐに使用できるICとして選ばれたものであり、開発労力を低減させる。主な欠点は、Jennic上のほとんどのDIOx線を使用するという点である。これは現行の設計には問題ないが、会話圧縮ICなどの他の選択肢にDIOx線が必要とされる場合、この部品は不適当なものとなる。
【0270】
代替の実施形態
以下の両選択肢は、USB内蔵8ビットマイクロコントローラIC及びSPIスレーブインターフェイスである。これらはいずれもこれらを機能的にするために開発されたファームウェア及びソフトウェアドライバを有する必要があるが、両メーカは、このプロセスに役立てるためのリファレンス設計、利用上の注意などを提供している。これらの部品の利点は、JennicSPIインターフェイスとインターフェイス接続することができ、また1本のDIOx線しか必要とせずに他のDIOx線を他の用途のために解放する点である。
【0271】
玩具は、複雑なUSB要件を有しておらず、唯一の要件は、プログラムされるデータをフラッシュメモリにダウンロードすることである。装置は、メモリスティックなどのいかなる一般的な装置の機能にも対応する必要はない。これにより必要な開発労力が低減される。
【0272】
以下で特定する部品は、単純な低出力埋込み型アプリケーションを対象とするとともにSPIスレーブインターフェイスを有するものとして選んだものである。しかしながら、メーカのグループ又は他社メーカから得られる装置も同様に適している可能性が十分にある。
Cypress CY7C63833−LFXC
Atmel AT90USB82−16MU
【0273】
電池
リチウムイオン
図8及び図9に示す回路はリチウムイオン(Li+)電池を使用する。
3つの理由からLi+電池を選択した。
i)形状〜実証機のプロジェクトに便利であった平坦プリズム状パッケージの形で利用可能である。
ii)開発しやすさ〜Li+の充電要件は、特に充電器が追加の回路に同時に給電する必要がある場合に代替品よりも単純である。
iii)電力容量〜実証機起動時の控えめな電力要件の評価値が、利用可能な空間が狭くてもLi技術が十分な電力を与えることが示唆していた。
(後述を参照)。
代替の充電技術は、NiMH及びNiCadである。NiMHは、NiCad(Li+より複雑な)と同様の充電要件を有するが、Li+と同様の(より高い)出力密度(特定の物理体積に関しては保持電力が大きい)及び価格を有する。
【0274】
NiCad/NiMH
このセクションでは、Li+と比較したNiCad/NiMH電池の特性について考察する。説明を簡潔にするために、以下のセクションではNiMHをNiCadと表記する。
【0275】
i)形状
通常、NiCad電池には単三及び単四などの標準サイズがあるが、他の形状も利用可能である。小型の構成要素を使用でき、2ピース及び/又はフレキシブル回路/コネクタなどのより複雑なPCBの製造コストが抑制事項にならないと考えられる生産環境では、標準サイズの電池の使用を可能にすることができる。
【0276】
ii)開発しやすさ
新しいデータをダウンロードできるように、(USBポートから)電池を充電すると同時に(USBポートから)回路に電源を入れる必要がある(電池の充電と回路への給電とを同時に行うことはできない)。充電中に回路を電池から絶縁すること、或いは回路を接続したままにすることのいずれもが可能である。電池を絶縁するにはより複雑な回路を伴う。回路を接続したままにすることは、回路が制御している電池への通常の電流と、玩具の回路が受ける余分な電流との両方を充電器が見ることを意味する。
【0277】
Li+充電器の場合、回路を接続したままにすることはそれほど重大な問題ではない。主な欠点は、Li+電池が完全に充電されると充電器の電源を切ることが一般的であるという点である。この機能は禁止する必要があり、そうでなければ玩具の回路も同様に電源が切れてしまう。この結果、電池の寿命が短縮される。
【0278】
NiCad充電器の場合、回路を接続したままにすることは極めて重大な問題である。NiCad電池のほうが、特に充電の終了頃に充電プロファイルが複雑になる。このプロファイルが正しく検出されない場合、電池が二度と完全充電されないか、或いは電池が過充電された結果、電池への損傷及び過大な温度上昇が発生する。充電器は、このプロファイルを検出する2つの方法のうちの1つを使用する。第1の方法は、電池により引き込まれる電流の変化によるものである。残念ながら、現在の回路により引き込まれる電流では、充電器を混乱させた結果、危険な状況を生じる可能性がある。第2の方法は、電池の温度の変化を検出することによるものである。しかしながら、電池の充電部品も通常の使用中に高温になる。この用途では、信頼できる結果が得られるほど十分に電池を熱的に絶縁することは困難であると考えられる。
【0279】
電池を絶縁することは、図8の回路が採用する解決策である。充電器のICは、高性能の電力管理回路を組み込んで絶縁を行う。この統合電力管理は、既製品におけるNiCad技術には利用不可能である。従って、これは別個の構成要素又は特注のICにおいて実現されることになる。
【0280】
iii)電力容量
このセクションでは、人形の電子部品に関する電源要件について説明する。このセクションで使用される電池寿命は、以下の電池容量に基づくものである。
・単四アルカリ=1150mAh @1.5V
・単四NiCad=300mAh @1.2V
・単四NiMH=750mAh @1.2V
・Li+プリズム状=620mAh@3.7V
注:Li+電池は、同じ定格の場合他の電池の2倍の電力を保持するが、その理由は電圧が2倍の大きさだからである。2つの単四電池を直列で使用する必要があり、或いは1つの単四を昇圧型コンバータと共に使用してその能力を半分とする。
【0281】
図9に示す回路の電力評価
推定電力消費量=発話時136mA、その他の場合48mA。これは、以下で構成される。
・Jennicモジュール=48mA
・音声ドライバ
250mW最大8オームスピーカ出力=175mA、ただし、各々の人形が時間の半分ずつ発話する2つの人形間の会話において=>88mA
注:スピーカが時間全体にわたって最大電力で駆動されることはありそうにないが、オーディオアンプは100%効率ではないので、88mAが合理的な妥協点である。
・残りの回路=無視できる
【0282】
実証機の評価に基づく電池寿命。
実証機にとっては、単一のプリズム状Li+による解決策が当然の選択であった。
【0283】
図8に示す回路の電力要件。
全体的な電力消費量の中で音声電力が最も重要な因子であるため、より正確な値を得ることが重要である。最良の方法は直接測定であるが、これは音声パフォーマンスが一旦終了したときに限り可能である。
【0284】
しかしながら、音声電力が推定値ほど大きくないであろうことを示唆するいくつかの要素が存在する。
・発話の特性により、波形の平均電力はピーク振幅をかなり下回るものとなる。例えば、発話は多くの休止を含む。従って、回路が最大平均出力レベルを下回るレベルで駆動する可能性がある。
・生産回路で使用されるD級アンプは、図9に示す回路のものよりもはるかに良好な効率を有し、この結果大幅な節電となる。
【0285】
実証用の会話のさらに詳細な計算及び分析により、平均音声電力は会話中10mAにすぎず、従って2つの人形間の会話に関しては5mAという平均値になることが示唆されている。これにより、発話時に合計53mAで非発話時に48mAをもたらすJennic電力が優勢となる。
注:この音声電力レベルは、音楽ではなく発話音声に関するものである。
音声電力の改良評価に基づく電池寿命
【0286】
Jennicの電力消費量を削減する方法が存在する。現在、Jennicは常にオンであり、絶えずメッセージを探っている。ファームウェア及び人形が互いに通信する方法の変更により、絶えず探っている必要があるのは(最初に電源が入れられる)1つの人形のみとなる。他の人形は、発話する必要がある場合には定期的に第1の人形に確認することができ、この短時間の間のみ給電される必要がある。残りの時間は、Jennicは低電力スリープモードに入ることができる。10%の負荷サイクルが達成可能な場合、これにより非発話時に10倍の電力消費量が削減される。発話時にはJennicに給電する必要があるが、メッセージを探る必要がないので、RF部は非給電状態にすることができる。これによりJennicの電力消費量が4倍削減される。従って、全体的な電流消費量を発話時には14mAに、非発話時には4mAに低減させることが可能となる。
【0287】
ほとんどの人形がこの低減された電力要件を有するようになるが、(最初に電源を入れられる)1つの人形にはこの節電が行われないことになる。人形の起動方法の変更により、これも同様に低減させることが可能になると思われる。どのようなことが実現可能であるかを判定するためにはさらなる調査が必要である。
【0288】
低減されたJennicの電力要件に基づく電池寿命
これらの電力要件を実現できる場合、2本の単四標準、NiCad又はNiMH電池が使用可能になる。
【0289】
自動電源オフ機能
人形の電子部品の現在の仕様では、オン/オフスイッチが回路の作動を制御する。他の玩具とは異なり、人形は、アクティブな人形のいずれか1体のボタンが押されるのを待って受動的に座っているので、いつ人形のスイッチがオンになるかは明らかでない。これは、人形の電源をオフにするのを忘れる可能性が高いことを意味する。このため、(翌日などの)次回人形で遊ぶときには電池が切れてしまっている結果となる。
【0290】
回路がひとりでに『スタンバイ』モードに切り替わり、電流をほとんど引き出さないようにすることは可能であるが、これは現在の機能仕様には含まれていない。電子部品がいつこのスタンバイモードに入るか及びどのようにして再起動するかは、人形の全体的な挙動及びパフォーマンスに密接な関係がある。
【0291】
発話の圧縮
発話の圧縮により、同じメモリ量により多くの音声データを記憶できるようになる。現在の設計には発話圧縮技術は含まれていない。現在の設計では、結果として64kbps(ビット/秒)のデータ転送速度をもたらす8ビット8kHzの音声データが使用され、約1000秒(17分)の音声データを記憶できるようにする64Mbit直列フラッシュメモリが使用されている。会話の圧縮を使用して、このデータ転送速度を2kbpsと8kbpsとの間に下げることができるが、圧縮率を高くするほど音声品質は低くなる。つまり、8kbpsの場合、4Mbitフラッシュメモリは約500秒(8 1/2分)の音声データを保持することができる。
【0292】
圧縮音声データは、再生時に解凍を必要とする。これは、ソフトウェア又は専用ハードウェア内で行うことができる。2、3の選択肢を以下に示す。
【0293】
Jennicコントローラ上でのソフトウェア解凍
この選択肢は幅広く調査されていない。まず、適当な圧縮/解凍アルゴリズムのソースコードを発見し、このアルゴリズムをJennicコントローラに移植するできるようにする必要がある。次に、このアルゴリズムが必要とし、Jennicコントローラ上で利用可能な処理電力の分析を行う必要がある。
【0294】
Sensory社の音声合成IC
Sensory社は、マイクロコントローラのファミリを2つ有する。SC−6xファミリは、事前プログラムされたSC−691スレーブシンセサイザを有する。これは、Jennicとインターフェイス接続するのに9本のDIOx線を必要とする4ビットMCUインターフェイスを有し、32オームのスピーカを直接駆動させることができる。新しい方のRSC46xファミリは、事前プログラムされたスレーブシンセサイザを有していないので、カスタムファームウェアを開発することが必要となる。Jennicとは4ビット、又は8ビットMCUインターフェイス(9本又は15本のDOIx線)でインターフェイス接続するようになるであろう。しかしながら、こちらのほうがプロセッサは強力であり(音声認識アルゴリズムを処理することができる)、8オームのスピーカを直接駆動させることができる。Jennicは両方に対応する十分なDIOx線を有していないので、これらの部品のどちらもUSB FT245チップと共に使用することができない。スレーブSPI USBチップが必要となる(USBのセクションを参照)。
【0295】
かなりの処理電力を有するRSC−4xなどの音声合成マイクロコントローラを使用することは、代替のシステム構築の可能性を示唆する。メイン人形アルゴリズムを実行させるとともにスレーブマイクロプロセッサとして合成マイクロコントローラを使用して音声を単純に解凍するJennic無線マイクロコントローラの代わりに、合成マイクロコントローラがメイン人形アルゴリズムを実行するとともに無線通信のためにスレーブコプロセッサとして無線マイクロコントローラを使用することができる。さらなる詳細については無線マイクロコントローラのセクションを参照されたい。
【0296】
無線マイクロコントローラ
現在の設計は、2.4GHzIEEE802.15.4パーソナルエリアネットワーク通信規格に基づくものである。全ての低レベルRF通信に対応するために必要なRFハードウェア及びファームウェアを含む無線マイクロコントローラ製品が存在する。通信内のデータのみは、人形アプリケーションにより定義する必要がある。現在の設計は、Jennic無線マイクロコントローラを選択している。
【0297】
IEEE802.15.4製品は低レベルRF通信に対応するが、人形アプリケーションには良好に適合しない一面がある。IEEE 802.15.4はノードの階層構造に基づくものであり、多くの機能低減装置が全機能搭載装置と通信する。人形アプリケーションはピアツーピア構造を有し、全ての装置が同じものである。
【0298】
同じ2.4GHz又は異なるISM周波数帯で機能する他のRFトランシーバ製品が利用可能である。これらは必要なRFハードウェアを全て含むが、特定の低レベルプロトコルを強いるものではない。これらのトランシーバICは、汎用マイクロコントローラ又はRSC4倍速音声シンセサイザーなどの専用マイクロコントローラのスレーブとして機能する。これらの部品を使用して、専用のピアツーピア通信プロトコルを開発することができる。
【0299】
RFトランシーバの例には、Tl CC2500及びAtmel ATA542Xファミリがある。これらの部品は、JennicICよりも低い電力消費量及び単位原価を実現する可能性がある。
【0300】
言うまでもなく、本発明は、単なる例示として説明した上記実施形態の詳細に限定されることを意図されたものではなく、本発明の範囲内において詳細の修正を行うことができることを理解されたい。
【0301】
説明及び(必要に応じて)特許請求の範囲並びに図面において開示した個々の特徴は、単独で又はあらゆる適当な組み合せで提供することができる。
【符号の説明】
【0302】
200:制御装置
202:スレーブ
204:会話エンジン
206:発話コンパイラ
208:発話データベース
210:スピーカ
212:IR/RF送信機/受信機
214:ランダム発話セレクタ
216:パラメータ記憶装置
218:発話者セレクタ
付録I〜テーマの例
付録II〜図8に関する部品の詳細
付録III〜図9に関する部品の詳細
【特許請求の範囲】
【請求項1】
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
少なくとも1つのさらなるこのような玩具とのネットワーク接続を確立する手段と、
を含み、
前記プロセッサが、ネットワーク接続が確立された個々の玩具の出力を制御する手段を含む、
ことを特徴とする玩具。
【請求項2】
前記制御手段が、ネットワーク接続が確立された個々の玩具の複数の前記出力(好ましくは全ての前記出力)を制御する命令を前記ネットワーク接続を介して送信するようにされた、
ことを特徴とする請求項1に記載の玩具。
【請求項3】
前記ネットワーク接続が、パーソナルエリアネットワークの一部を形成する、
ことを特徴とする請求項1又は請求項2に記載の玩具。
【請求項4】
前記メモリが、少なくとも1つのデータのグループを記憶するようになっており、個々の前記少なくとも1つのグループが特定のテーマを表す、
ことを特徴とする請求項1、請求項2又は請求項3に記載のいずれかに記載の玩具。
【請求項5】
前記メモリに記憶された前記少なくとも1つのテーマを決定する手段をさらに含む、
ことを特徴とする請求項4に記載の玩具。
【請求項6】
前記玩具が、別の玩具との接続を、前記メモリに記憶された少なくとも1つのテーマが両玩具において同じであるときにのみ確立するようにされた、
ことを特徴とする請求項5に記載の玩具。
【請求項7】
前記制御手段が、個々の前記玩具の前記出力を制御する制御メッセージを送信/受信するようになっており、好ましくは前記制御メッセージが、対象とする前記玩具のIDとコマンドセグメントとを含み、より好ましくは前記発信元玩具のID及び/又はメッセージIDをさらに含む、
ことを特徴とする請求項1から請求項6のいずれかに記載の玩具。
【請求項8】
前記制御メッセージが、参照データベースにアクセスしてタスクを実行するための命令を含む、
ことを特徴とする請求項7に記載の玩具。
【請求項9】
前記プロセッサが、送信/受信された制御メッセージの確認応答を送信する手段を含み、好ましくは前記送信/受信手段が、確認応答を受信しない場合に前記制御メッセージが再送されるよう要求するようにされた、
ことを特徴とする請求項1から請求項8のいずれかに記載の玩具。
【請求項10】
前記送信/受信手段が、このような玩具が前記制御メッセージに応じて出力を生成するのに掛かるであろう時間に関連するパラメータを送信するようになっており、好ましくは前記発信元玩具が、さらなる制御メッセージを送信するまで前記パラメータに関連する時間の間待機する(このような玩具がこのような出力を生成するのに掛かるであろう前記時間は、例えば前記玩具のテーマ又はサブテーマにより様々であってもよい)、
ことを特徴とする請求項9に記載の玩具。
【請求項11】
前記プロセッサが、再送された制御メッセージの数を計数する手段を含み、これにより前記制御メッセージの確認応答を行わない前記玩具との通信が、1,000〜2,000回、2,000〜5,000回、5,000〜10,000回又はそれ以上の試行後に停止される、
ことを特徴とする請求項8、請求項9又は請求項10に記載の玩具。
【請求項12】
前記プロセッサが、前記玩具間の会話を構築するようになっている会話エンジンをさらに含む、
ことを特徴とする請求項1から請求項11のいずれかに記載の玩具。
【請求項13】
玩具のテーマ別データを作成するためのオーサリングツールであって、
特定のテーマに関するコンテンツを受信する手段と、
前記コンテンツを処理して、前記特定のテーマ内の前記玩具を動作させる命令セットを生成する手段と、
前記命令セットを出力する手段と、
を含むことを特徴とするオーサリングツール。
【請求項14】
前記受信手段が、前記特定のテーマに関するスクリプトデータと、前記玩具の性格を定義する表現データとの両方を別個に含むコンテンツを受信するようにされた、
ことを特徴とする請求項13に記載のオーサリングツール。
【請求項15】
前記受信手段が、コンテンツを別の部分の形で受信するようにされた、
ことを特徴とする請求項14に記載のオーサリングツール。
【請求項16】
個々の表現データ部分に一意のID番号を割り当てる手段をさらに含む、
ことを特徴とする請求項15に記載のオーサリングツール。
【請求項17】
前記処理手段が、前記命令セット内の前記表現データ部分への参照として前記一意のID番号を利用するようにされた、
ことを特徴とする請求項16に記載のオーサリングツール。
【請求項18】
前記表現データが、テーマ名、前記玩具の名前、及び前記玩具が対話するために使用する文のうちの少なくとも1つを含む、
ことを特徴とする請求項14から請求項17のいずれかに記載のオーサリングツール。
【請求項19】
前記スクリプトデータが、前記テーマ内で対話できる玩具の数、対話方法、テーマ関連パラメータ、及び玩具関連パラメータのうちの少なくとも1つを含む、
ことを特徴とする請求項14から請求項18のいずれかに記載のオーサリングツール。
【請求項20】
特定のテーマに関する前記スクリプトデータと表現データとを配列の形でともに記憶する手段をさらに含む、
ことを特徴とする請求項14から請求項19のいずれかに記載のオーサリングツール。
【請求項21】
前記処理手段が、前記配列から前記命令セットを生成するようにされた、
ことを特徴とする請求項20に記載のオーサリングツール。
【請求項22】
前記処理手段が、前記表現データの少なくとも一部を含む少なくとも1つのリストをコンパイルする手段を含む、
ことを特徴とする請求項14から請求項21のいずれかに記載のオーサリングツール。
【請求項23】
前記リストコンパイル手段が、前記特定のテーマにおける個々の玩具ごとにそれぞれのリストをコンパイルするようにされた、
ことを特徴とする請求項22に記載のオーサリングツール。
【請求項24】
前記表現データがシンボルデータである、
ことを特徴とする請求項14から請求項25のいずれかに記載のオーサリングツール。
【請求項25】
前記シンボルデータの上演データバージョンを記録する記録手段をさらに含む、
ことを特徴とする請求項24に記載のオーサリングツール。
【請求項26】
関係者に、上演データの必要な部分を生成するように促す手段をさらに含む、
ことを特徴とする請求項25に記載のオーサリングツール。
【請求項27】
前記プロセッサが、前記シンボルデータと上演データとの間のルックアップテーブルを生成するようにされた、
ことを特徴とする請求項25又は請求項26に記載のオーサリングツール。
【請求項28】
前記処理手段が、前記表現データを出力するようにされた、
ことを特徴とする請求項14から請求項27のいずれかに記載のオーサリングツール。
【請求項29】
前記処理手段がさらに、前記表現データと命令セットとを別個に出力するようにされた、
ことを特徴とする請求項28に記載のオーサリングツール。
【請求項30】
前記処理手段が、前記玩具の基本機能を制御するための基本命令セットと、該基本命令セットが前記テーマ内の前記玩具を制御するためのテーマ別命令セットとを含む命令セットを生成するようにされた、
ことを特徴とする請求項13から請求項29のいずれかに記載のオーサリングツール。
【請求項31】
前記プロセッサが、前記基本命令セット及び前記テーマ別命令セットを共に組み合わせるようにされた、
ことを特徴とする請求項30に記載のオーサリングツール。
【請求項32】
コンパイラをさらに含む、
ことを特徴とする請求項30又は請求項31に記載のオーサリングツール。
【請求項33】
前記コンパイラが、前記基本命令セット及び前記テーマ別命令セットをコンパイルするようにされた、
ことを特徴とする請求項32に記載のオーサリングツール。
【請求項34】
前記プロセッサが、前記命令セットをコンピュータ可読コードに変換するようになっている符号化エンジンを含む、
ことを特徴とする請求項1から請求項33のいずれかに記載のオーサリングツール。
【請求項35】
前記オーサリングツールの前記出力が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の会話エンジン内で使用されるようにされた、
ことを特徴とする請求項13から請求項34のいずれかに記載のオーサリングツール。
【請求項36】
前記玩具が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具である、
ことを特徴とする請求項1から請求項23のいずれかに記載のオーサリングツール。
【請求項37】
玩具のテーマ別データを作成するオーサリングツールのためのユーザインターフェイスであって、
各々がテーマに関するコンテンツの特定のサブセットの入力に対応する入力ウィンドウのセットをユーザに提供する手段と、
前記テーマ別データの出力を開始する手段と、
を含むことを特徴とするユーザインターフェイス。
【請求項38】
前記コンテンツのサブセットが、テーマ関連データ、玩具関連データ及びコンテキスト関連データのうちの少なくとも1つを含む、
ことを特徴とする請求項37に記載のユーザインターフェイス。
【請求項39】
前記コンテキスト関連データが、前記玩具が対話するために使用する文、対話方法、テーマ関連パラメータ及び玩具関連パラメータのうちの少なくとも1つを含む、
ことを特徴とする請求項38に記載のユーザインターフェイス。
【請求項40】
玩具のテーマ別データを生成するためのシステムであって、
前記テーマ別データにアクセスし、これを作成及び編集するためのオーサリングツールと、
前記テーマ別データを記憶するためのデータベースを含むサーバと、
を含み、
前記オーサリングツールが、インターネットを介して前記テーマ別データにアクセスするようにされた、
ことを特徴とするシステム。
【請求項41】
前記オーサリングツールが、前記テーマ別データを処理して配列するようにされ、前記データベースが、前記テーマ別データを前記配列の形で記憶するようにされた、
ことを特徴とする請求項40に記載のシステム。
【請求項42】
前記オーサリングツールが、請求項13から請求項36のいずれかに記載のオーサリングツールである、
ことを特徴とする請求項41に記載のシステム。
【請求項43】
前記玩具が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具である、
ことを特徴とする請求項41に記載のシステム。
【請求項44】
ユーザインターフェイスをさらに含む、
ことを特徴とする請求項41から請求項43のいずれかに記載の玩具。
【請求項45】
前記インターフェイスが、請求項25から請求項27のいずれかに記載のインターフェイスである、
ことを特徴とする請求項44に記載のシステム。
【請求項46】
別のこのような玩具と対話するようになっており、前記プロセッサが、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数を前記メモリに記憶する手段と、前記変数を使用して前記玩具の(対話型)出力を制御する手段とを含む、
ことを特徴とする請求項1から請求項12のいずれかに記載の玩具。
【請求項47】
別のこのような玩具と対話するようになっている玩具であって、
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数を前記メモリに記憶する手段と、前記玩具の(対話型)出力に関連して前記変数を使用する手段と、
を含むことを特徴とする玩具。
【請求項48】
前記変数を複数回(より好ましくは数えきれないほど)使用して前記出力を制御する、
ことを特徴とする請求項46又は請求項47に記載の玩具。
【請求項49】
前記変数を使用して前記対話の前記回数、種類又は性質を決定し、好ましくは前記変数が前記対話である、
ことを特徴とする請求項46、請求項47又は請求項48に記載の玩具。
【請求項50】
前記変数がランダムに又は疑似ランダム的に選択され、前記ランダム選択が重み付けにより影響される、
ことを特徴とする請求項46から請求項49のいずれかに記載の玩具。
【請求項51】
前記プロセッサが、前記テーマ別データを前記メモリに記憶するようになっており、前記テーマがスクリプトデータ及び表現データを含み、前記表現データが前記玩具の前記性格を定義する、
ことを特徴とする請求項34から請求項50のいずれかに記載の玩具。
【請求項52】
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが前記テーマ別データを前記メモリに記憶するようになっており、
前記テーマがスクリプトデータ及び表現データを含み、前記表現データが前記玩具の前記性格を定義する、
ことを特徴とする玩具。
【請求項53】
少なくとも1つの他の同様の玩具と対話するようになっており、前記スクリプトデータが個々のこのような玩具により共有され、前記表現データが個々のこのような玩具間で異なる、
ことを特徴とする請求項51又は請求項52に記載の玩具。
【請求項54】
前記スクリプトデータが、前記表現データとは無関係である、
ことを特徴とする請求項51、請求項52又は請求項53に記載の玩具。
【請求項55】
前記プロセッサが、別のこのような玩具に制御メッセージとして前記スクリプトデータを出力するようにされ、制御メッセージに個々の表現データで応答するようにされた、
ことを特徴とする請求項53又は請求項54に記載の玩具。
【請求項56】
前記プロセッサが、対話する玩具を予め定めたルールに基づいて選択する手段を含む、
ことを特徴とする請求項1から請求項12、又は請求項46から請求項55のいずれかに記載の玩具。
【請求項57】
他のこのような玩具と対話するようになっている玩具であって、
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが、対話する玩具を予め定めたルールに基づいて選択する手段を含み、前記選択された玩具を前記発信元玩具とすることができる、
ことを特徴とする玩具。
【請求項58】
前記選択手段が、次の対話する玩具を選択するようにされた、
ことを特徴とする請求項56又は請求項57に記載の玩具。
【請求項59】
前記予め定めたルールが、直接選択、ランダム選択、及び前記現在の対話玩具を選択して再び対話することを含む、
こと特徴とする請求項58に記載の玩具。
【請求項60】
前記プロセッサが、前記選択された玩具のID及び好ましくは前記発信元玩具のIDを含む制御メッセージを出力するようにされた、
ことを特徴とする請求項56から請求項59のいずれかに記載の玩具。
【請求項61】
前記対話が通信を含み、好ましくは前記通信が発話及び指示を含む、
ことを特徴とする請求項56から請求項60のいずれかに記載の玩具。
【請求項62】
他の同様の玩具とゲームをプレイすることに適した生きているものの形をとり、前記プロセッサがゲームエンジンを含み、該ゲームエンジンが、前記玩具が生きているかのようにゲームをプレイ可能にするようにされた、
ことを特徴とする請求項1から請求項12、又は、請求項46から請求項61のいずれかに記載の玩具。
【請求項63】
他の同様の玩具とゲームをプレイすることに適した生きているものの形をとる玩具であって、
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが、前記玩具が関連する生きているものであるかのように個々の前記玩具がゲームできるようにするゲームエンジンを含む、
ことを特徴とする玩具。
【請求項64】
前記ゲームエンジンが、人間のゲームを可能にするようにされた、
ことを特徴とする請求項62又は請求項63に記載の玩具。
【請求項65】
前記人間のゲームがゲーム機器でプレイされる、
ことを特徴とする請求項64に記載の玩具。
【請求項66】
前記ゲームエンジンが、人間が前記ゲーム機器を調整して前記ゲームをプレイできるようにする命令を出力するようにされた、
ことを特徴とする請求項65に記載の玩具。
【請求項67】
前記玩具が、少なくとも1つのさらなるこのような玩具と通信する手段をさらに含む、
ことを特徴とする請求項62から請求項66のいずれかに記載の玩具。
【請求項68】
前記ゲームエンジンがさらに、ルールに基づくゲームをプレイするようにされた、
ことを特徴とする請求項62から請求項67のいずれかに記載の玩具。
【請求項69】
前記ゲームエンジンが、前記ゲームに関する情報を前記メモリに記憶するようにされた、
ことを特徴とする請求項62から請求項68のいずれかに記載の玩具。
【請求項70】
前記情報が、前記ゲームの前記ルールを含む、
ことを特徴とする請求項69に記載の玩具。
【請求項71】
前記情報が、少なくとも1つのプレイボードのレイアウトをさらに含む、
ことを特徴とする請求項69又は請求項70に記載の玩具。
【請求項72】
前記ゲームエンジンが、仮想サイコロになっている乱数発生器を含む、
ことを特徴とする請求項62から請求項71のいずれかに記載の玩具。
【請求項73】
前記ゲームエンジンが、前記ゲームに関する外部入力を受信する手段を含む、
ことを特徴とする請求項62から請求項72のいずれかに記載の玩具。
【請求項74】
前記外部入力が、前記ゲームの駒に関連付けられる、
ことを特徴とする請求項73に記載の玩具。
【請求項75】
前記外部入力が、前記プレイボード内の少なくとも1つのセンサである、
ことを特徴とする請求項73又は請求項74に記載の玩具。
【請求項76】
前記外部入力が、前記玩具のユーザが使用するようにされたスイッチである、
ことを特徴とする請求項73、請求項74又は請求項75に記載の玩具。
【請求項77】
前記ルールに基づくゲームが、ヘビとはしご及びルードを含む、
ことを特徴とする請求項68から請求項76のいずれかに記載の玩具。
【請求項78】
前記出力が変換器である、
ことを特徴とする請求項1から請求項77のいずれかに記載の玩具。
【請求項79】
前記変換器がスピーカである、
ことを特徴とする請求項78に記載の玩具。
【請求項80】
前記変換器がアクチュエータである、
ことを特徴とする請求項78又は請求項79に記載の玩具。
【請求項81】
各々が請求項1から請求項12、又は請求項46から請求項80のいずれかに記載された複数の玩具を含む、
ことを特徴とする組み合わせ。
【請求項82】
前記複数の玩具の各々が他の前記玩具を制御する手段を含み、1つの玩具のみが他の前記玩具を同時に制御する、
ことを特徴とする請求項81に記載の組み合わせ。
【請求項83】
複数の玩具にテーマ別データを提供する装置であって、
各々が複数のサブテーマを含む前記テーマ別データを記憶する手段と、
特定の玩具を識別する手段と、
前記特定の玩具に基づいてサブテーマを選択する手段と、
前記玩具に前記特定のサブテーマを出力する手段と、
を含むことを特徴とする装置。
【請求項84】
複数の異なるテーマを記憶する手段をさらに含む、
ことを特徴とする請求項83に記載の玩具。
【請求項85】
ユーザが前記複数のテーマの1つを選択できるようにする手段をさらに含む、
ことを特徴とする請求項84に記載の玩具。
【請求項86】
前記特定の玩具を識別する手段が、前記玩具の一意の識別番号を使用する、
ことを特徴とする請求項83、請求項84又は請求項85のいずれかに記載の装置。
【請求項87】
前記玩具に関連するパラメータに基づいて個々の前記サブテーマを暗号化する手段を含む、
ことを特徴とする請求項83から請求項86のいずれかに記載の装置。
【請求項88】
前記パラメータが、前記玩具の一意の識別番号である、
ことを特徴とする請求項87に記載の玩具。
【請求項89】
玩具などの装置のための会話エンジンであって、
前記会話のテーマを選択し、
複数の起点から起点をランダムに選択し、
変数に基づいて語句をランダムに選択し、
変数に基づいて次の発話者をランダムに選択する、
ための手段を含むことを特徴とする会話エンジン。
【請求項90】
前記語句選択がさらに、重み付けに基づく、
ことを特徴とする請求項89に記載の会話エンジン。
【請求項91】
請求項89又は請求項90に記載の会話エンジンを組み込んだ、
ことを特徴とする玩具。
【請求項92】
前記玩具が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具である、
ことを特徴とする請求項91に記載の玩具。
【請求項93】
請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の少なくとも1つの玩具とコンピュータとの間に無線通信を提供するための装置であって、
前記装置を前記コンピュータに接続する通信ポートと、
前記コンピュータと前記又は各玩具との間にネットワークを確立する手段と、
を含み、
前記装置が、前記コンピュータが別のこのような玩具であるかのように前記又は各玩具と通信できるようにする、
ことを特徴とする装置。
【請求項94】
前記装置が、前記コンピュータを仮想玩具として機能できるようにする、
ことを特徴とする請求項93に記載の玩具。
【請求項95】
前記通信ポートがUSB通信ポートである、
ことを特徴とする請求項93又は請求項94に記載の玩具。
【請求項96】
前記ネットワークが無線である、
ことを特徴とする請求項93、請求項94又は請求項95に記載の玩具。
【請求項97】
請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の少なくとも1つの玩具と、
各々が請求項93から請求項96のいずれかに記載の装置を含む少なくとも1つのコンピュータと、
を含み、
前記コンピュータと装置との組み合わせが、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具であるかのように機能する、
ことを特徴とするシステム。
【請求項98】
前記コンピュータが、仮想玩具を提供するようになっている視覚及び音声出力を含む、
ことを特徴とする請求項97に記載のシステム。
【請求項99】
前記仮想玩具がアバターである、
ことを特徴とする請求項98に記載のシステム。
【請求項1】
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
少なくとも1つのさらなるこのような玩具とのネットワーク接続を確立する手段と、
を含み、
前記プロセッサが、ネットワーク接続が確立された個々の玩具の出力を制御する手段を含む、
ことを特徴とする玩具。
【請求項2】
前記制御手段が、ネットワーク接続が確立された個々の玩具の複数の前記出力(好ましくは全ての前記出力)を制御する命令を前記ネットワーク接続を介して送信するようにされた、
ことを特徴とする請求項1に記載の玩具。
【請求項3】
前記ネットワーク接続が、パーソナルエリアネットワークの一部を形成する、
ことを特徴とする請求項1又は請求項2に記載の玩具。
【請求項4】
前記メモリが、少なくとも1つのデータのグループを記憶するようになっており、個々の前記少なくとも1つのグループが特定のテーマを表す、
ことを特徴とする請求項1、請求項2又は請求項3に記載のいずれかに記載の玩具。
【請求項5】
前記メモリに記憶された前記少なくとも1つのテーマを決定する手段をさらに含む、
ことを特徴とする請求項4に記載の玩具。
【請求項6】
前記玩具が、別の玩具との接続を、前記メモリに記憶された少なくとも1つのテーマが両玩具において同じであるときにのみ確立するようにされた、
ことを特徴とする請求項5に記載の玩具。
【請求項7】
前記制御手段が、個々の前記玩具の前記出力を制御する制御メッセージを送信/受信するようになっており、好ましくは前記制御メッセージが、対象とする前記玩具のIDとコマンドセグメントとを含み、より好ましくは前記発信元玩具のID及び/又はメッセージIDをさらに含む、
ことを特徴とする請求項1から請求項6のいずれかに記載の玩具。
【請求項8】
前記制御メッセージが、参照データベースにアクセスしてタスクを実行するための命令を含む、
ことを特徴とする請求項7に記載の玩具。
【請求項9】
前記プロセッサが、送信/受信された制御メッセージの確認応答を送信する手段を含み、好ましくは前記送信/受信手段が、確認応答を受信しない場合に前記制御メッセージが再送されるよう要求するようにされた、
ことを特徴とする請求項1から請求項8のいずれかに記載の玩具。
【請求項10】
前記送信/受信手段が、このような玩具が前記制御メッセージに応じて出力を生成するのに掛かるであろう時間に関連するパラメータを送信するようになっており、好ましくは前記発信元玩具が、さらなる制御メッセージを送信するまで前記パラメータに関連する時間の間待機する(このような玩具がこのような出力を生成するのに掛かるであろう前記時間は、例えば前記玩具のテーマ又はサブテーマにより様々であってもよい)、
ことを特徴とする請求項9に記載の玩具。
【請求項11】
前記プロセッサが、再送された制御メッセージの数を計数する手段を含み、これにより前記制御メッセージの確認応答を行わない前記玩具との通信が、1,000〜2,000回、2,000〜5,000回、5,000〜10,000回又はそれ以上の試行後に停止される、
ことを特徴とする請求項8、請求項9又は請求項10に記載の玩具。
【請求項12】
前記プロセッサが、前記玩具間の会話を構築するようになっている会話エンジンをさらに含む、
ことを特徴とする請求項1から請求項11のいずれかに記載の玩具。
【請求項13】
玩具のテーマ別データを作成するためのオーサリングツールであって、
特定のテーマに関するコンテンツを受信する手段と、
前記コンテンツを処理して、前記特定のテーマ内の前記玩具を動作させる命令セットを生成する手段と、
前記命令セットを出力する手段と、
を含むことを特徴とするオーサリングツール。
【請求項14】
前記受信手段が、前記特定のテーマに関するスクリプトデータと、前記玩具の性格を定義する表現データとの両方を別個に含むコンテンツを受信するようにされた、
ことを特徴とする請求項13に記載のオーサリングツール。
【請求項15】
前記受信手段が、コンテンツを別の部分の形で受信するようにされた、
ことを特徴とする請求項14に記載のオーサリングツール。
【請求項16】
個々の表現データ部分に一意のID番号を割り当てる手段をさらに含む、
ことを特徴とする請求項15に記載のオーサリングツール。
【請求項17】
前記処理手段が、前記命令セット内の前記表現データ部分への参照として前記一意のID番号を利用するようにされた、
ことを特徴とする請求項16に記載のオーサリングツール。
【請求項18】
前記表現データが、テーマ名、前記玩具の名前、及び前記玩具が対話するために使用する文のうちの少なくとも1つを含む、
ことを特徴とする請求項14から請求項17のいずれかに記載のオーサリングツール。
【請求項19】
前記スクリプトデータが、前記テーマ内で対話できる玩具の数、対話方法、テーマ関連パラメータ、及び玩具関連パラメータのうちの少なくとも1つを含む、
ことを特徴とする請求項14から請求項18のいずれかに記載のオーサリングツール。
【請求項20】
特定のテーマに関する前記スクリプトデータと表現データとを配列の形でともに記憶する手段をさらに含む、
ことを特徴とする請求項14から請求項19のいずれかに記載のオーサリングツール。
【請求項21】
前記処理手段が、前記配列から前記命令セットを生成するようにされた、
ことを特徴とする請求項20に記載のオーサリングツール。
【請求項22】
前記処理手段が、前記表現データの少なくとも一部を含む少なくとも1つのリストをコンパイルする手段を含む、
ことを特徴とする請求項14から請求項21のいずれかに記載のオーサリングツール。
【請求項23】
前記リストコンパイル手段が、前記特定のテーマにおける個々の玩具ごとにそれぞれのリストをコンパイルするようにされた、
ことを特徴とする請求項22に記載のオーサリングツール。
【請求項24】
前記表現データがシンボルデータである、
ことを特徴とする請求項14から請求項25のいずれかに記載のオーサリングツール。
【請求項25】
前記シンボルデータの上演データバージョンを記録する記録手段をさらに含む、
ことを特徴とする請求項24に記載のオーサリングツール。
【請求項26】
関係者に、上演データの必要な部分を生成するように促す手段をさらに含む、
ことを特徴とする請求項25に記載のオーサリングツール。
【請求項27】
前記プロセッサが、前記シンボルデータと上演データとの間のルックアップテーブルを生成するようにされた、
ことを特徴とする請求項25又は請求項26に記載のオーサリングツール。
【請求項28】
前記処理手段が、前記表現データを出力するようにされた、
ことを特徴とする請求項14から請求項27のいずれかに記載のオーサリングツール。
【請求項29】
前記処理手段がさらに、前記表現データと命令セットとを別個に出力するようにされた、
ことを特徴とする請求項28に記載のオーサリングツール。
【請求項30】
前記処理手段が、前記玩具の基本機能を制御するための基本命令セットと、該基本命令セットが前記テーマ内の前記玩具を制御するためのテーマ別命令セットとを含む命令セットを生成するようにされた、
ことを特徴とする請求項13から請求項29のいずれかに記載のオーサリングツール。
【請求項31】
前記プロセッサが、前記基本命令セット及び前記テーマ別命令セットを共に組み合わせるようにされた、
ことを特徴とする請求項30に記載のオーサリングツール。
【請求項32】
コンパイラをさらに含む、
ことを特徴とする請求項30又は請求項31に記載のオーサリングツール。
【請求項33】
前記コンパイラが、前記基本命令セット及び前記テーマ別命令セットをコンパイルするようにされた、
ことを特徴とする請求項32に記載のオーサリングツール。
【請求項34】
前記プロセッサが、前記命令セットをコンピュータ可読コードに変換するようになっている符号化エンジンを含む、
ことを特徴とする請求項1から請求項33のいずれかに記載のオーサリングツール。
【請求項35】
前記オーサリングツールの前記出力が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の会話エンジン内で使用されるようにされた、
ことを特徴とする請求項13から請求項34のいずれかに記載のオーサリングツール。
【請求項36】
前記玩具が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具である、
ことを特徴とする請求項1から請求項23のいずれかに記載のオーサリングツール。
【請求項37】
玩具のテーマ別データを作成するオーサリングツールのためのユーザインターフェイスであって、
各々がテーマに関するコンテンツの特定のサブセットの入力に対応する入力ウィンドウのセットをユーザに提供する手段と、
前記テーマ別データの出力を開始する手段と、
を含むことを特徴とするユーザインターフェイス。
【請求項38】
前記コンテンツのサブセットが、テーマ関連データ、玩具関連データ及びコンテキスト関連データのうちの少なくとも1つを含む、
ことを特徴とする請求項37に記載のユーザインターフェイス。
【請求項39】
前記コンテキスト関連データが、前記玩具が対話するために使用する文、対話方法、テーマ関連パラメータ及び玩具関連パラメータのうちの少なくとも1つを含む、
ことを特徴とする請求項38に記載のユーザインターフェイス。
【請求項40】
玩具のテーマ別データを生成するためのシステムであって、
前記テーマ別データにアクセスし、これを作成及び編集するためのオーサリングツールと、
前記テーマ別データを記憶するためのデータベースを含むサーバと、
を含み、
前記オーサリングツールが、インターネットを介して前記テーマ別データにアクセスするようにされた、
ことを特徴とするシステム。
【請求項41】
前記オーサリングツールが、前記テーマ別データを処理して配列するようにされ、前記データベースが、前記テーマ別データを前記配列の形で記憶するようにされた、
ことを特徴とする請求項40に記載のシステム。
【請求項42】
前記オーサリングツールが、請求項13から請求項36のいずれかに記載のオーサリングツールである、
ことを特徴とする請求項41に記載のシステム。
【請求項43】
前記玩具が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具である、
ことを特徴とする請求項41に記載のシステム。
【請求項44】
ユーザインターフェイスをさらに含む、
ことを特徴とする請求項41から請求項43のいずれかに記載の玩具。
【請求項45】
前記インターフェイスが、請求項25から請求項27のいずれかに記載のインターフェイスである、
ことを特徴とする請求項44に記載のシステム。
【請求項46】
別のこのような玩具と対話するようになっており、前記プロセッサが、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数を前記メモリに記憶する手段と、前記変数を使用して前記玩具の(対話型)出力を制御する手段とを含む、
ことを特徴とする請求項1から請求項12のいずれかに記載の玩具。
【請求項47】
別のこのような玩具と対話するようになっている玩具であって、
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが、前記対話に関連する少なくとも1つの変数を定義する手段と、前記変数を前記メモリに記憶する手段と、前記玩具の(対話型)出力に関連して前記変数を使用する手段と、
を含むことを特徴とする玩具。
【請求項48】
前記変数を複数回(より好ましくは数えきれないほど)使用して前記出力を制御する、
ことを特徴とする請求項46又は請求項47に記載の玩具。
【請求項49】
前記変数を使用して前記対話の前記回数、種類又は性質を決定し、好ましくは前記変数が前記対話である、
ことを特徴とする請求項46、請求項47又は請求項48に記載の玩具。
【請求項50】
前記変数がランダムに又は疑似ランダム的に選択され、前記ランダム選択が重み付けにより影響される、
ことを特徴とする請求項46から請求項49のいずれかに記載の玩具。
【請求項51】
前記プロセッサが、前記テーマ別データを前記メモリに記憶するようになっており、前記テーマがスクリプトデータ及び表現データを含み、前記表現データが前記玩具の前記性格を定義する、
ことを特徴とする請求項34から請求項50のいずれかに記載の玩具。
【請求項52】
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが前記テーマ別データを前記メモリに記憶するようになっており、
前記テーマがスクリプトデータ及び表現データを含み、前記表現データが前記玩具の前記性格を定義する、
ことを特徴とする玩具。
【請求項53】
少なくとも1つの他の同様の玩具と対話するようになっており、前記スクリプトデータが個々のこのような玩具により共有され、前記表現データが個々のこのような玩具間で異なる、
ことを特徴とする請求項51又は請求項52に記載の玩具。
【請求項54】
前記スクリプトデータが、前記表現データとは無関係である、
ことを特徴とする請求項51、請求項52又は請求項53に記載の玩具。
【請求項55】
前記プロセッサが、別のこのような玩具に制御メッセージとして前記スクリプトデータを出力するようにされ、制御メッセージに個々の表現データで応答するようにされた、
ことを特徴とする請求項53又は請求項54に記載の玩具。
【請求項56】
前記プロセッサが、対話する玩具を予め定めたルールに基づいて選択する手段を含む、
ことを特徴とする請求項1から請求項12、又は請求項46から請求項55のいずれかに記載の玩具。
【請求項57】
他のこのような玩具と対話するようになっている玩具であって、
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが、対話する玩具を予め定めたルールに基づいて選択する手段を含み、前記選択された玩具を前記発信元玩具とすることができる、
ことを特徴とする玩具。
【請求項58】
前記選択手段が、次の対話する玩具を選択するようにされた、
ことを特徴とする請求項56又は請求項57に記載の玩具。
【請求項59】
前記予め定めたルールが、直接選択、ランダム選択、及び前記現在の対話玩具を選択して再び対話することを含む、
こと特徴とする請求項58に記載の玩具。
【請求項60】
前記プロセッサが、前記選択された玩具のID及び好ましくは前記発信元玩具のIDを含む制御メッセージを出力するようにされた、
ことを特徴とする請求項56から請求項59のいずれかに記載の玩具。
【請求項61】
前記対話が通信を含み、好ましくは前記通信が発話及び指示を含む、
ことを特徴とする請求項56から請求項60のいずれかに記載の玩具。
【請求項62】
他の同様の玩具とゲームをプレイすることに適した生きているものの形をとり、前記プロセッサがゲームエンジンを含み、該ゲームエンジンが、前記玩具が生きているかのようにゲームをプレイ可能にするようにされた、
ことを特徴とする請求項1から請求項12、又は、請求項46から請求項61のいずれかに記載の玩具。
【請求項63】
他の同様の玩具とゲームをプレイすることに適した生きているものの形をとる玩具であって、
プロセッサと、
前記プロセッサに結合されたメモリと、
前記プロセッサに結合された出力部と、
を含み、
前記プロセッサが、前記玩具が関連する生きているものであるかのように個々の前記玩具がゲームできるようにするゲームエンジンを含む、
ことを特徴とする玩具。
【請求項64】
前記ゲームエンジンが、人間のゲームを可能にするようにされた、
ことを特徴とする請求項62又は請求項63に記載の玩具。
【請求項65】
前記人間のゲームがゲーム機器でプレイされる、
ことを特徴とする請求項64に記載の玩具。
【請求項66】
前記ゲームエンジンが、人間が前記ゲーム機器を調整して前記ゲームをプレイできるようにする命令を出力するようにされた、
ことを特徴とする請求項65に記載の玩具。
【請求項67】
前記玩具が、少なくとも1つのさらなるこのような玩具と通信する手段をさらに含む、
ことを特徴とする請求項62から請求項66のいずれかに記載の玩具。
【請求項68】
前記ゲームエンジンがさらに、ルールに基づくゲームをプレイするようにされた、
ことを特徴とする請求項62から請求項67のいずれかに記載の玩具。
【請求項69】
前記ゲームエンジンが、前記ゲームに関する情報を前記メモリに記憶するようにされた、
ことを特徴とする請求項62から請求項68のいずれかに記載の玩具。
【請求項70】
前記情報が、前記ゲームの前記ルールを含む、
ことを特徴とする請求項69に記載の玩具。
【請求項71】
前記情報が、少なくとも1つのプレイボードのレイアウトをさらに含む、
ことを特徴とする請求項69又は請求項70に記載の玩具。
【請求項72】
前記ゲームエンジンが、仮想サイコロになっている乱数発生器を含む、
ことを特徴とする請求項62から請求項71のいずれかに記載の玩具。
【請求項73】
前記ゲームエンジンが、前記ゲームに関する外部入力を受信する手段を含む、
ことを特徴とする請求項62から請求項72のいずれかに記載の玩具。
【請求項74】
前記外部入力が、前記ゲームの駒に関連付けられる、
ことを特徴とする請求項73に記載の玩具。
【請求項75】
前記外部入力が、前記プレイボード内の少なくとも1つのセンサである、
ことを特徴とする請求項73又は請求項74に記載の玩具。
【請求項76】
前記外部入力が、前記玩具のユーザが使用するようにされたスイッチである、
ことを特徴とする請求項73、請求項74又は請求項75に記載の玩具。
【請求項77】
前記ルールに基づくゲームが、ヘビとはしご及びルードを含む、
ことを特徴とする請求項68から請求項76のいずれかに記載の玩具。
【請求項78】
前記出力が変換器である、
ことを特徴とする請求項1から請求項77のいずれかに記載の玩具。
【請求項79】
前記変換器がスピーカである、
ことを特徴とする請求項78に記載の玩具。
【請求項80】
前記変換器がアクチュエータである、
ことを特徴とする請求項78又は請求項79に記載の玩具。
【請求項81】
各々が請求項1から請求項12、又は請求項46から請求項80のいずれかに記載された複数の玩具を含む、
ことを特徴とする組み合わせ。
【請求項82】
前記複数の玩具の各々が他の前記玩具を制御する手段を含み、1つの玩具のみが他の前記玩具を同時に制御する、
ことを特徴とする請求項81に記載の組み合わせ。
【請求項83】
複数の玩具にテーマ別データを提供する装置であって、
各々が複数のサブテーマを含む前記テーマ別データを記憶する手段と、
特定の玩具を識別する手段と、
前記特定の玩具に基づいてサブテーマを選択する手段と、
前記玩具に前記特定のサブテーマを出力する手段と、
を含むことを特徴とする装置。
【請求項84】
複数の異なるテーマを記憶する手段をさらに含む、
ことを特徴とする請求項83に記載の玩具。
【請求項85】
ユーザが前記複数のテーマの1つを選択できるようにする手段をさらに含む、
ことを特徴とする請求項84に記載の玩具。
【請求項86】
前記特定の玩具を識別する手段が、前記玩具の一意の識別番号を使用する、
ことを特徴とする請求項83、請求項84又は請求項85のいずれかに記載の装置。
【請求項87】
前記玩具に関連するパラメータに基づいて個々の前記サブテーマを暗号化する手段を含む、
ことを特徴とする請求項83から請求項86のいずれかに記載の装置。
【請求項88】
前記パラメータが、前記玩具の一意の識別番号である、
ことを特徴とする請求項87に記載の玩具。
【請求項89】
玩具などの装置のための会話エンジンであって、
前記会話のテーマを選択し、
複数の起点から起点をランダムに選択し、
変数に基づいて語句をランダムに選択し、
変数に基づいて次の発話者をランダムに選択する、
ための手段を含むことを特徴とする会話エンジン。
【請求項90】
前記語句選択がさらに、重み付けに基づく、
ことを特徴とする請求項89に記載の会話エンジン。
【請求項91】
請求項89又は請求項90に記載の会話エンジンを組み込んだ、
ことを特徴とする玩具。
【請求項92】
前記玩具が、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具である、
ことを特徴とする請求項91に記載の玩具。
【請求項93】
請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の少なくとも1つの玩具とコンピュータとの間に無線通信を提供するための装置であって、
前記装置を前記コンピュータに接続する通信ポートと、
前記コンピュータと前記又は各玩具との間にネットワークを確立する手段と、
を含み、
前記装置が、前記コンピュータが別のこのような玩具であるかのように前記又は各玩具と通信できるようにする、
ことを特徴とする装置。
【請求項94】
前記装置が、前記コンピュータを仮想玩具として機能できるようにする、
ことを特徴とする請求項93に記載の玩具。
【請求項95】
前記通信ポートがUSB通信ポートである、
ことを特徴とする請求項93又は請求項94に記載の玩具。
【請求項96】
前記ネットワークが無線である、
ことを特徴とする請求項93、請求項94又は請求項95に記載の玩具。
【請求項97】
請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の少なくとも1つの玩具と、
各々が請求項93から請求項96のいずれかに記載の装置を含む少なくとも1つのコンピュータと、
を含み、
前記コンピュータと装置との組み合わせが、請求項1から請求項12、又は請求項46から請求項82のいずれかに記載の玩具であるかのように機能する、
ことを特徴とするシステム。
【請求項98】
前記コンピュータが、仮想玩具を提供するようになっている視覚及び音声出力を含む、
ことを特徴とする請求項97に記載のシステム。
【請求項99】
前記仮想玩具がアバターである、
ことを特徴とする請求項98に記載のシステム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12a】
【図12b】
【図12c】
【図13a】
【図13b】
【図14】
【図15】
【図16】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12a】
【図12b】
【図12c】
【図13a】
【図13b】
【図14】
【図15】
【図16】
【公表番号】特表2010−533532(P2010−533532A)
【公表日】平成22年10月28日(2010.10.28)
【国際特許分類】
【出願番号】特願2010−516579(P2010−516579)
【出願日】平成20年7月18日(2008.7.18)
【国際出願番号】PCT/GB2008/002457
【国際公開番号】WO2009/010760
【国際公開日】平成21年1月22日(2009.1.22)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.ZIGBEE
【出願人】(507355146)
【Fターム(参考)】
【公表日】平成22年10月28日(2010.10.28)
【国際特許分類】
【出願日】平成20年7月18日(2008.7.18)
【国際出願番号】PCT/GB2008/002457
【国際公開番号】WO2009/010760
【国際公開日】平成21年1月22日(2009.1.22)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.ZIGBEE
【出願人】(507355146)
【Fターム(参考)】
[ Back to top ]