JP4536481B2 - コンピュータシステム、修正作業を支援するための方法、及びプログラム - Google Patents

Description

本発明は、音声等の情報に基づいて字幕等のデータを作成する技術に関し、特に、コンピュータによって作成された字幕等のデータを編集する技術に関する。

放送を通じて発信される情報へのアクセシビリティを確保するため、字幕付与可能な全ての放送番組に２００７年までに字幕を付与するという目標が掲げられている。また、インターネット上で配信される動画についても、今後、字幕付与の必要性は高まるであろう。
このような背景から、放送や動画に対して字幕を付与するための研究が多くなされている。
その1つに、専門家による字幕書き起こし作業を支援するシステムがある(例えば、特許文献１、特許文献２参照)。特許文献１では、特殊な再生操作によって、また、特許文献２では、発話の速度を変更することによって、字幕書き起こし作業を支援している。

また、もう１つは、音声認識技術を用いて自動的に字幕を作成する方法である。専門家による字幕書き起こしの作業が不要になることから、この方法に対する期待は高まっている。しかしながら、現状の音声認識技術では、完璧に正しい字幕を作成することは不可能である。従って、結局は、専門家が音声認識結果をチェックして編集する作業を行わなければならず、その作業には膨大な工数がかかることとなってしまう。

このような編集作業の例について、図２３を参照して説明する。
ここでは、図示するように、「今までの取り組みがオンデマンドビジネスを実現する上での過程にすぎません。」という音声が流れ、図示するような音声認識結果が得られているものとする。
編集者は、この音声を先頭から聞きながら音声認識結果を確認し、間違いを見つける。例えば、５行目の「オンデアンド」は「オンデマンド」とすべき間違いであることが分かったとする。そうすると、編集者は、まず、音声を停止する。そして、５行目をマウスでポイントしてキーボードフォーカスを移動し、「オンデアンド」を「オンデマンド」に修正する。
ここで、５行目にキーボードフォーカスを移動したものの、「オンデアンド」をどのように修正すべきか忘れてしまった場合は、もう一度再生し、その後、「オンデアンド」を「オンデマンド」に修正する。

特開２００３−２１６２００号公報(第９、１０頁、第６図) 特開２００３−２２３２００号公報(第８頁、第６図)

このように、音声に字幕を付与するための研究は、従来より数多くなされてきた。しかしながら、従来の技術には、以下に述べるような問題点があった。
第１の問題点は、高いスキルレベルの人材に依存する部分が大きいという点である。
字幕書き起こし作業は、音声を聞きながら一字一句文字に変換していく作業であり、スキルレベルの低い人材では、到底なし得ない。また、音声認識結果を編集することにより字幕を作成する作業も、音声認識結果における間違いの認識及び正しい文字列の決定を音声を聞きながら瞬時に行わなければならないので、スキルレベルの低い人材では困難な作業である。そして、高いスキルレベルの人材を用いた場合には、人件費の上昇という問題が生じてしまう。

また、第２の問題点は、作業の操作性が悪く、効率的ではないという点である。
画面上の任意の場所をポイントするには、マウスが速やかに操作できて便利である。一方、画面上に文字を打ち込むには、キーボードが便利である。しかしながら、字幕書き起こし作業では、音声の再生及び停止はマウスで行い、字幕の入力はキーボードで行うことになる。また、字幕編集作業では、間違い箇所のポイントはマウスで行い、正しい文字列の入力はキーボードで行う。このようにマウスとキーボードを併用すると、手がマウスからキーボードへ、再びキーボードからマウスへと移動する時間がオーバーヘッドとなってしまうのである。
また、従来は、音声の再生中の箇所と字幕の書き起こし又は編集を行っている箇所とは連動していなかった。更に、キーボードで文字を入力中に音声が流れているとキー入力における集中力に影響を与えてしまう。逆に、修正内容を忘れてしまった場合は、記憶を手繰ったり、明示的に再生コマンドを発行したりする必要があった。従って、決して効率的な操作が行えるものではなかった。

本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、スキルレベルの高い人材のみに頼らずに字幕等のデータを作成し、そのような作業にかかるコストを削減することにある。
また、本発明の他の目的は、字幕等のデータを作成する効率を向上し、そのような作業に要する時間を短縮することにある。

かかる目的のもと、本発明では、音声認識結果において編集が必要な部分を特定する装置と、その部分における編集を実際に行う装置とを分けた。即ち、本発明のコンピュータシステムは、音声又は映像に基づいて作成されたテキストデータを編集するためのものであり、第１のコンピュータと、第２のコンピュータとを備える。そして、第１のコンピュータは、音声又は映像を出力し、外部からの指示に応じて、テキストデータの編集すべき部分を特定し、第２のコンピュータは、音声又は映像を出力し、第１のコンピュータにより特定された部分を、外部からの指示に応じて編集する。
また、編集が必要な部分を特定する装置を、マウス等のポインティングデバイスによって操作される装置と捉え、編集を実際に行う装置を、キーボードよって操作される装置と捉え、これらの装置を分けたシステムとして本発明を把握することも可能である。この場合、第１のコンピュータは、ポインティングデバイスからの指示に応じて、テキストデータの編集すべき部分を特定し、第２のコンピュータは、キーボードからの指示に応じて、その特定された部分を編集する。
更に、編集作業の効率化のため、音声又は映像とテキストデータとを連動させる構成とすることも可能である。その場合、第２のコンピュータは、編集すべき部分に対応する音声又は映像を、その部分の編集に先立って出力する。

更にまた、本発明は、音声又は映像から作成されたテキストを編集する場面だけでなく、一般的に何らかの情報から作成されたデータを修正する様々な場面において適用可能である。その場合、本発明のコンピュータシステムは、所定の情報に基づいて作成されたデータをその情報を参照しながら修正する作業を支援するためのものであり、第１のコンピュータと、第２のコンピュータとを備える。そして、第１のコンピュータは、その情報を出力し、外部からの指示に応じて、データの修正すべき部分を特定し、第２のコンピュータは、第１のコンピュータにより特定された部分に対応する情報を出力し、外部からの指示に応じて、その部分を修正する。

また、本発明は、所定の情報に基づいて作成されたデータをその情報を参照しながら修正する作業をコンピュータが支援する方法として捉えることもできる。その場合、本発明の方法は、その情報を出力することにより、データの修正すべき部分の特定を促し、外部からの指示に応じて、修正すべき部分を特定するステップと、その後、その情報を出力することにより、その部分の修正を促し、外部からの指示に応じて、その部分を修正するステップとを含んでいる。

一方、本発明は、サーバコンピュータに所定の機能を実現させるプログラムとして捉えることもできる。その場合、本発明のプログラムは、所定の情報に基づいて作成されたデータをその情報を参照しながら修正する作業の支援機能をサーバコンピュータに実現させるためのものであり、具体的には、次の機能を実現させる。１つは、外部からの指示に応じて、データの修正すべき部分を特定する機能であり、もう１つは、特定された部分の修正を、複数のクライアントコンピュータのうちの特定のクライアントコンピュータに指示する機能である。

本発明によれば、スキルレベルの高い人材のみに頼らずに字幕等のデータを作成することができ、そのような作業にかかるコストを削減することができる。

以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。
(第１の実施の形態)
図１は、本実施の形態における字幕編集システムの構成を示した図である。この字幕編集システムは、マウス字幕編集装置１０と、キーボード字幕編集装置２０と、音声認識装置３０と、音声データ記憶部４０と、字幕データ記憶部５０とから構成される。尚、図１では、キーボード字幕編集装置２０として、キーボード字幕編集装置Ａとキーボード字幕編集装置Ｂの２台を設けた場合の構成を示している。但し、キーボード字幕編集装置２０は、２台に限られるものではなく、１台であってもよいし、３台以上であってもよい。また、マウス字幕編集装置１０とキーボード字幕編集装置２０は、図１では別個の装置として示しているが、同一装置の上に実装されていても構わない。

マウス字幕編集装置１０は、生成される字幕に対する責任者(以下、「マスタエディタ」という)によって操作される装置(第１のコンピュータ)であって、例えば、ＰＣによって実現される。キーボード字幕編集装置２０は、マウス字幕編集装置１０から渡された字幕に対し、キーボードによる編集を行う操作者(以下、「キーボードエディタ」という）によって操作される装置(第２のコンピュータ)であって、例えば、ＰＣによって実現される。音声認識装置３０は、音声データをコンピュータで処理することにより、音声データが意味する内容を例えば文字列で出力する装置であり、音声認識の方式としては既存技術を採用することができる。音声データ記憶部４０は、音声認識対象の音声データを記憶する領域であり、例えば、磁気ディスク、光ディスク、半導体メモリ等によって実現される。
マスタエディタは、音声認識装置３０による音声認識結果に対し、句読点の位置の決定、キーボード字幕編集装置２０への配信、キーボード字幕編集装置２０による編集結果に対する最終チェック及び確定を行う。ここで、句読点の位置の決定は、キーボードエディタが複数いる場合の分配や、最終的な字幕表示にも影響を与えるものであるので、極めて重要な作業であると言える。
一方、キーボードエディタは、音声に対応する正しい文字列を入力する作業を行うだけでよい。この作業は極めて単純なものであるので、キーボードエディタは、比較的スキルレベルが低く、責任も低い人でよい。これにより、人件費を節約できるという効果が期待できる。

マスタエディタによる具体的な操作の内容は、以下の通りである。
Ａ) 音声認識により分割された行(以下、「字幕行」という)に誤りがなければ、その字幕行を確定する。
Ｂ) 「ほぼ正しい字幕行」に対し、確信度を設定する。
Ｃ) 句読点を指定する。
Ｄ) 字幕行の連結、分割等の調整を行う。
Ｅ) 編集が必要な字幕行をキーボード字幕編集装置２０にサブミットする。
Ｆ) 最終的な字幕を確定する。
一方、キーボードエディタによる具体的な操作の内容は、以下の通りである。
あ) 字幕行を編集し、正しい字幕行を作成する。
い) 正しい字幕行を確定する。

この操作の内容を、図２を参照して具体的に説明する。図２の左側は、マウス字幕編集装置１０の画面における表示例であり、右側は、キーボード字幕編集装置２０の画面における表示例である。
ここでも、図２３と同様、「今までの取り組みがオンデマンドビジネスを実現する上での過程にすぎません。」という音声が流れ、図２に示すような音声認識結果が得られているものとする。

マウス字幕編集装置１０の表示例において、「行」欄には、各字幕行がその音声ファイル全体の先頭から何行目に位置するかが表示される。「開始」欄には、各字幕行に対応する音声がその音声ファイル全体の先頭から何秒経過した時に流れるかが表示される。
「確信度」欄には、各字幕行の音声認識結果に対する確信度が表示される。確信度は、初期状態においては、音声認識装置３０が音声認識処理の段階で得た確信度が表示されるが、これをマスタエディタが変更することも可能である。通常、音声認識装置３０は、確信度「１００％」を出力することはない。従って、図２における確信度「１００％」は、マスタエディタが、音声認識結果を見て間違いがないと判断し設定したものであると考えることができる。尚、確信度の変更は、欄内の上向き矢印及び下向き矢印を用いて行うことができる。
「ブロック」欄には、キーボード字幕編集装置２０にて字幕行の編集をブロックするかどうかのマークが表示される。上述したように、「確信度」欄においてマスタエディタが確信度「１００％」を設定すると、自動的に「ブロック」欄に「○」が表示されるようになっている。この例では、５行目の「オンデアンド」、１１行目の「での家庭」、１３行目の「すいません」が正しく認識されてない行(以下、「間違い行」という)と判断され、「ブロック」欄に「○」は表示されていない。
「音声認識結果」欄には、音声認識装置３０による音声認識の結果が文字列で表示される。マスタエディタは、この文字列が正しいかどうかを判断することになる。

ところで、マウス字幕編集装置１０の画面には、例えば、表示例の右下に示すようなポップアップメニューが表示される。マスタエディタは、この中から所望の指示内容を選択する。例えば、図示するように、１３行目の字幕行にフォーカスを位置付けた状態で「ピリオド確定してサブミット」を選択したとする。その場合、マウス字幕編集装置１０は、１行目から１３行目の字幕行までをキーボード字幕編集装置２０に送信する文として切り出し、この文に関する情報をキーボード字幕編集装置２０に送信する。
これにより、キーボード字幕編集装置２０の画面には、図２の右側に示す内容が表示される。その後、キーボード字幕編集装置２０における間違い行の編集が完了すると、マウス字幕編集装置１０に編集結果の確認依頼が返信される。即ち、これらの表示内容の間の矢印は、マウス字幕編集装置１０からキーボード字幕編集装置２０へ音声認識結果の編集すべき箇所がサブミットされ、その編集結果がマウス字幕編集装置１０にサブミットされることを示している。

尚、マスタエディタの具体的な操作内容のＢ)に挙げた「ほぼ正しい字幕行」の例を以下に示す。表現が多少違っても、内容さえ伝わっていればよいような場合に、「ほぼ正しい字幕行」として決定することが想定される。例えば、会議の音声から議事録を作成する場合等である。
Ａ．余計な句読点や抜けている句読点があっても、「ほぼ正しい字幕行」として決定する。例えば、「大事です」に対する「正しい字幕行」は「大事です。」であるが、このまま「ほぼ正しい字幕行」として決定することもある。
Ｂ．余計な記号や抜けている記号があっても、「ほぼ正しい字幕行」として決定する。例えば、「プロとしてですねー」に対する「正しい字幕行」は「プロとしてですね」であるが、このまま「ほぼ正しい字幕行」として決定することもある。
Ｃ．編集者による編集間違いがあっても、「ほぼ正しい字幕行」として決定する。例えば、「そういた」に対する「正しい字幕行」は「そういった」であるが、このまま「ほぼ正しい字幕行」として決定することもある。
Ｄ．音声認識装置による間違いがあっても、「ほぼ正しい字幕行」として決定する。例えば、「なってます」に対する「正しい字幕行」は「なっています」であるが、このまま「ほぼ正しい字幕行」として決定することもある。
Ｅ．助詞が抜けていても、「ほぼ正しい字幕行」として決定する。例えば、「ベースなって」に対する「正しい字幕行」は「ベースになって」であるが、このまま「ほぼ正しい字幕行」として決定することもある。

Ｆ．送り仮名が違っても、「ほぼ正しい字幕行」として決定する。例えば、「受け付け」に対する「正しい字幕行」として「受付」が意図されていた場合に、このまま「ほぼ正しい字幕行」として決定することもある。
Ｇ．仮名の種類が違っても、「ほぼ正しい字幕行」として決定する。例えば、「もとに」に対する「正しい字幕行」として「元に」が意図されていた場合に、このまま「ほぼ正しい字幕行」として決定することもある。
Ｈ．同じ意味を表す語の文字表記が異なっていても、「ほぼ正しい字幕行」として決定する。例えば、「アイデア」に対する「正しい字幕行」として「アイディア」が意図されていた場合に、このまま「ほぼ正しい字幕行」として決定することもある。
Ｉ．全角か半角かの違いがあっても、「ほぼ正しい字幕行」として決定する。例えば、「ＩＢＭ」に対する「正しい字幕行」として「IBM」が意図されていた場合に、このまま「ほぼ正しい字幕行」として決定することもある。
Ｊ．話し言葉であっても、「ほぼ正しい字幕行」として決定する。例えば、「なんですけれども」に対する「正しい字幕行」として「なのですが」が意図されていた場合に、このまま「ほぼ正しい字幕行」として決定することもある。

次に、本実施の形態を構成するマウス字幕編集装置１０及びキーボード字幕編集装置２０について、以下、詳細に説明する。
図３は、本実施の形態におけるマウス字幕編集装置１０及びキーボード字幕編集装置２０として用いるのに好適なコンピュータのハードウェア構成の例を模式的に示した図である。
図３に示すコンピュータは、演算手段であるＣＰＵ(Central Processing Unit)９０ａと、Ｍ/Ｂ(マザーボード)チップセット９０ｂ及びＣＰＵバスを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ/Ｂチップセット９０ｂ及びＡＧＰ(Accelerated Graphics Port)を介してＣＰＵ９０ａに接続されたビデオカード９０ｄ及びディスプレイ９０ｊとを備える。また、ＰＣＩ(Peripheral Component Interconnect)バスを介してＭ/Ｂチップセット９０ｂに接続された磁気ディスク装置(ＨＤＤ)９０ｅと、ネットワークインターフェイス９０ｇとを備える。更に、このＰＣＩバスからブリッジ回路９０ｆ及びＩＳＡ(Industry Standard Architecture)バス等の低速なバスを介してＭ/Ｂチップセット９０ｂに接続されたフレキシブルディスクドライブ９０ｈとキーボード/マウス９０ｉとを備える。

尚、図３は本実施の形態を実現するコンピュータのハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード９０ｄを設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ９０ａにてイメージデータを処理する構成としてもよいし、外部記憶装置として、ＡＴＡ(AT Attachment)やＳＣＳＩ(Small Computer System Interface)等のインターフェイスを介してＣＤ−Ｒ(Compact Disc Recordable)やＤＶＤ−ＲＡＭ(Digital Versatile Disc Random Access Memory)のドライブを設けてもよい。

次に、本実施の形態におけるマウス字幕編集装置１０について詳細に説明する。尚、このマウス字幕編集装置１０の説明においては、必要に応じて、マウス字幕編集装置１０を「マスタ」と称し、キーボード字幕編集装置２０を「クライアント」と称する。
図４は、本実施の形態におけるマウス字幕編集装置１０の機能構成を示した図である。このマウス字幕編集装置１０は、受信部１１ａと、コマンド受付部１１ｂと、制御部１２と、送信部１３と、警告発生部１４と、キュー管理部１５と、割り当て決定部１６と、空き状況管理部１７と、処理能力計算部１８と、スタベーション管理部１９とを備える。また、マスタジョブキュー３１と、クライアントジョブキュー３２と、クライアント管理データベース(以下、「クライアント管理ＤＢ」という)３３とを備える。尚、図４では、キーボード字幕編集装置２０に送信する文をマスタエディタが切り出すための機能構成については省略してある。

受信部１１ａは、キーボード字幕編集装置２０からジョブを受信する機能を有し、コマンド受付部１１ｂは、キーボード字幕編集装置２０に送信するジョブの発生を示すコマンドを受け付ける機能を有する。また、制御部１２は、マウス字幕編集装置１０の全体動作を制御する機能を有し、送信部１３は、キーボード字幕編集装置２０へジョブを送信する機能を有する。
警告発生部１４は、キーボード字幕編集装置２０が処理すべきジョブが処理されずに溜まってきた場合や作業を行っていないキーボード字幕編集装置２０が増えてきた場合に警告を発生する機能を有し、キュー管理部１５は、マスタジョブキュー３１及びクライアントジョブキュー３２にジョブを出し入れしたり、これらのキューに格納されているジョブを管理したりする機能を有する。
割り当て決定部１６は、ジョブのキーボード字幕編集装置２０に対する割り当てを決定する機能を有し、空き状況管理部１７は、クライアント管理ＤＢ３３における空き状況に関する情報の参照/更新を行う機能を有する。また、処理能力計算部１８は、クライアント管理ＤＢ３３におけるキーボードエディタの処理能力に関する情報の参照/更新を行う機能を有し、スタベーション管理部１９は、クライアント管理ＤＢ３３におけるクライアントの作業状況に関する情報の参照/更新を行う機能を有する。

マスタジョブキュー３１は、キーボード字幕編集装置２０からマウス字幕編集装置１０へ送信されたジョブを格納するためのキューであり、クライアントジョブキュー３２は、マウス字幕編集装置１０からキーボード字幕編集装置２０へ送信するジョブを格納するためのキューである。尚、クライアントジョブキュー３２には、ジョブを一意に識別するジョブＩＤと、ジョブの処理が完了したかどうかを示す処理済フラグと、ジョブ本体とが関連付けられて保持されているものとする。そして、ジョブが処理されても、全ての情報を削除するのではなく、処理済フラグに「処理済」を書き込むようにする。

また、クライアント管理ＤＢ３３には、図示するように、クライアントＩＤと、ＢｕｓｙＦｌａｇと、作業開始時刻と、現ジョブサイズと、作業終了時刻と、累積作業時刻と、累積ジョブサイズとが管理されている。
ここで、クライアントＩＤとは、個々のキーボード字幕編集装置２０を一意に識別するＩＤである。ＢｕｓｙＦｌａｇは、個々のキーボード字幕編集装置２０が作業を行っているかどうかを示すフラグであり、作業を行っている状態を「Ｂｕｓｙ」で表し、作業を行っていない状態を「ＮｏｔＢｕｓｙ」で表すものとする。また、作業開始時刻は、個々のキーボード字幕編集装置２０が現在の作業を開始した時刻を示し、ＢｕｓｙＦｌａｇが「Ｂｕｓｙ」の時のみ有効な情報である。現ジョブサイズは、現在処理しているジョブのデータサイズを示し、ＢｕｓｙＦｌａｇが「Ｂｕｓｙ」の時のみ有効な情報である。作業終了時刻は、個々のキーボード字幕編集装置２０から最後にジョブを受信した時刻であり、ＢｕｓｙＦｌａｇが「ＮｏｔＢｕｓｙ」の時のみ有効な情報である。更に、累積作業時間は、個々のキーボード字幕編集装置２０における作業時間の累計であり、累積ジョブサイズは、個々のキーボード字幕編集装置２０で処理されたジョブのサイズの累計である。
尚、これらの各機能部分は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、マウス字幕編集装置１０のＣＰＵが、受信部１１ａ、コマンド受付部１１ｂ、制御部１２、送信部１３、警告発生部１４、キュー管理部１５、割り当て決定部１６、空き状況管理部１７、処理能力計算部１８、スタベーション管理部１９を実現するプログラムを外部記憶装置から主記憶装置に読み込み、外部記憶装置としてのマスタジョブキュー３１、クライアントジョブキュー３２、クライアント管理ＤＢ３３を必要に応じて参照しながら処理を行う。

ところで、本実施の形態において、キーボード字幕編集装置２０は、学生、ボランティア、障害者等の多様な労働者によって操作される。即ち、キーボードエディタのスキルレベルのばらつきは大きい。但し、各キーボードエディタの処理能力を事前に正確に予測することは困難である。また、その処理能力は、動的に変動するものでもある。更に、キーボード字幕編集装置２０に対し送信されるジョブは、不定期に発生し、そのサイズにはばらつきがあり、ジョブの終了も予測できない。一方、スキルレベルが低いキーボードエディタにジョブがいつまでも回ってこない現象(いわゆるスタベーション)は好ましくない。よって、本実施の形態では、スタベーションやデッドロックを起こさず、かつ、スループットを最大にするジョブの配信方法を採用している。

ここで、本実施の形態における前提条件をまとめておく。
１) 単独のマウス字幕編集装置１０及びそのマウス字幕編集装置１０を操作するマスタエディタが必ず存在する。
２) キーボード字幕編集装置２０が２台以上あり、かつ、キーボード字幕編集装置２０を操作するキーボードエディタが対応して存在する。
３) マスタエディタは、成果物に対する責任者であり、スキルレベルも安定している。ここで、マスタエディタの作業は、音声認識結果を確認しながら正しい部分をチェックし、間違っている部分を適当な時点でキーボード字幕編集装置２０に送信し、修正を指示することである。更に、マスタエディタの作業には、キーボード字幕編集装置２０による処理が完了したことにより送り返されてきたジョブの最終確認も含まれる。
４) キーボードエディタは、マスタエディタの指示に従う立場にあり、そのスキルレベルには大きなばらつきが想定される。スキルレベルが大きくばらつく理由は、障害、年齢、経験等の異なる多種多様な労働力を想定するからである。

５) キーボードエディタとしては、時間の経過に伴ってそれほど処理能力が変化しない人も存在する可能性はある。一方で、若年者のように「慣れ」によって大きく処理能力が向上していく人や、逆に高齢者等、「疲労」によって処理能力が減少していく人の存在も予想される。
６) 各ジョブはキーボードエディタと独立している。例えばジョブ１はキーボードエディタＡでなくては処理できない等のキーボードエディタに対する依存性があってはならない。
７) ジョブの発生は不定期で、そのサイズも大きくばらつく。サイズのばらつきの原因は、音声認識による認識率の高い部分と低い部分とが混在することにある。一般に、音声認識の認識率は、音響モデル、言語モデルのいずれか又は双方の理由により、同一環境における発話に対しても認識率が高い部分と低い部分とが混在する。そのため、一定時間や一定サイズ等、特定の範囲内でマスタがジョブを配信したとしても、図５(ａ),(ｂ)に示すようにその特定の範囲内での(誤認識部分の字幕編集の)ジョブサイズは一様にならない。
８) ジョブの終了を予測することもできない。例えば、字幕を付与したいコンテンツの長さが６０分間であったとしても、必ずしも一気に６０分間全部に対し字幕を付与するとは限らない。例えば、まず一旦１５分間分のコンテンツに対し字幕を付与した上で、専門用語の記述法、数値の記述法等、作業方法の確認のチェックを行い、その後、残りのコンテンツに対する字幕付与を再開するようなことも考えられる。

まず、キーボードエディタの処理能力の計算方法について述べる。ジョブは、マウス字幕編集装置１０からキーボード字幕編集装置２０へ送信され、キーボード字幕編集装置２０が処理終了後、マウス字幕編集装置１０へと送信される。このマウス字幕編集装置１０がジョブを送信してからジョブを受信する間に要した時間は簡単に求められる。このジョブの実仕事サイズをこの要した時間で割ることにより個々のキーボードエディタの処理能力を求めることができる。この実仕事サイズ及び処理時間を随時累積していくことによって、個々のキーボードエディタの処理能力を動的に計算することが可能となる。尚、ジョブの実仕事サイズとしては、例えば、マスタエディタが間違っていると判断した字幕行の行数や、その字幕行に含まれる文字の総数等、仕事としての負荷を表すいかなる情報をも採用可能である。
更に、いくら処理が早くとも誤りが多いようでは処理能力が高いとは言い切れない。よって、マスタエディタがキーボードエディタによる編集結果に対する最終確認を行った際、マスタエディタが修正したデータ量を求めることで、仕事の正確さを求めることができる。これにより、各キーボードエディタの仕事の正確さの累積実績に基づいて、その処理能力を更新することも可能である。

また、初期状態においては、各キーボードエディタの処理能力を計算するための情報が揃っていない。従って、そのような場合には、年齢等に基づく一定の基準により、処理能力の初期値を計算しておいてもよい。
尚、このような処理能力に関する情報は、内部で計算されるだけであり、外部には提示されない。従って、プライバシーに配慮し、処理能力の値は保存せず、システム終了時に自動的に破棄することも既存技術により可能である。一方、特定のキーボードエディタの処理能力を、例えば、裁量労働制のために特別に(プライバシーを保護した上で)保存する必要があれば、それもまた既存技術により実現することは容易である。

次に、本実施の形態におけるマウス字幕編集装置１０の動作について説明する。
図６は、マスタエディタの操作によってジョブが発生する場合のマウス字幕編集装置１０の動作を示したフローチャートである。
まず、マスタエディタは、図２のような音声認識結果が表示された状態で、マウス字幕編集装置１０に対し、音声の再生を指示する。そして、マスタエディタは、流れてくる音声と表示された音声認識結果を見比べながら、画面上で確信度チェックを行う。ここで、確信度チェックとは、各字幕行を、正しい字幕行、間違い行、不確定のまま表示する字幕行、のいずれかに分類する作業である。具体的には、正しい字幕行については、確信度を「１００％」とし、間違い行については、確信度をそのままにしておく。尚、不確定のまま表示する字幕行については、確信度はそのままにしておいてもよいし、変更するようにしてもよい。
その後、マスタエディタは、文の終わりであると判断すると、音声を停止し、キーボード字幕編集装置２０に対しサブミットするよう指示する。これにより、マウス字幕編集装置１０は、音声認識結果に含まれる字幕行のうち間違い行を特定する(ステップ１０１)。
尚、このようにしてマスタエディタが切り出した１つの文に対する編集作業が１つのジョブとして発生する。このジョブには、図２に示したキーボード字幕編集装置２０の表示を行うために必要な情報が含められる。また、キーボード字幕編集装置２０の画面上に直接表示されるわけではないが、間違い行を特定するための情報も含められる。

次に、マウス字幕編集装置１０では、コマンド受付部１１ｂが、ジョブが発生した旨のコマンドを受け付ける(ステップ１０２)。
これにより、制御部１２に制御が渡され、制御部１２は、キュー管理部１５に対し、送信すべきジョブをクライアントジョブキュー３２に格納するよう指示する。これに従い、キュー管理部１５は、ジョブをクライアントジョブキュー３２に格納する(ステップ１０３)。
また、制御部１２は、空き状況管理部１７に対し、現在ジョブを処理中ではないクライアント(以下、「空きクライアント」という)が存在するかどうかを判定するよう指示する。これに従い、空き状況管理部１７は、クライアント管理ＤＢ３３で管理される全クライアントのＢｕｓｙＦｌａｇを参照し、空きクライアントが存在するかどうかを判定する(ステップ１０４)。空き状況管理部１７は、空きクライアントが存在しない場合はその旨を、空きクライアントが存在する場合は、空きクライアントのＩＤを制御部１２に返却する。

その結果、空きクライアントが存在しない旨が返却された場合、制御部１２は、警告発生部１４に対し、警告を発生するよう指示する。これに従い、警告発生部１４は、マウス字幕編集装置１０の画面上に警告を表示する(ステップ１０５)。尚、警告発生部１４は、クライアントジョブキュー３２に格納されている未処理のジョブの数に応じて、警告の強さを変えるようにしてもよい。例えば、未処理のジョブが１つの場合は、弱い警告を発生し、未処理のジョブが２つ以上の場合は、強い警告を発生するようにしてもよい。また、単純に定量化して表示する方法も考えられる。或いは、音の強弱、音色、高さ等によって未処理ジョブの数を表すような方法も考えられる。

一方、空きクライアントのＩＤが返却された場合、制御部１２は、キュー管理部１５、処理能力計算部１８、スタベーション管理部１９に対し、割り当て決定部１６の処理に必要な情報を収集するよう指示する。これに従い、キュー管理部１５、処理能力計算部１８、スタベーション管理部１９は、そのような情報を収集する(ステップ１０６)。
具体的には、キュー管理部１５は、クライアントジョブキュー３２に格納される全てのジョブのジョブサイズ及び処理済フラグを求める。そして、そのジョブサイズ及び処理済フラグを制御部１２に返却する。
また、処理能力計算部１８は、クライアント管理ＤＢ３３を参照し、各クライアントの処理能力を計算する。具体的には、クライアント管理ＤＢ３３に管理される累積ジョブサイズを累積作業時間で除して、各オペレータが単位時間あたりにこなせる仕事の量を求める。そして、処理能力計算部１８は、各クライアントの処理能力を制御部１２に返却する。
更に、スタベーション管理部１９は、クライアント管理ＤＢ３３で管理される作業終了時刻を現在時刻から減ずることにより、空きクライアントの待ち時間を求める。そして、スタベーション管理部１９は、この求めた待ち時間を制御部１２に返却する。

このようにして制御部１２は、全てのクライアントの処理能力、全てのジョブのサイズ及び処理済フラグ、空きクライアントのＩＤ、今回のジョブのＩＤ、空きクライアントの待ち時間の情報を保持する。そして、割り当て決定部１６に対し、ジョブのクライアントに対する割り当てを決定するよう指示する。これに従い、割り当て決定部１６は、ジョブのクライアントに対する割り当てを決定する(ステップ１０７)。そして、割り当て決定部１６は、割り当ての結果(ジョブの送信を一時保留する場合もある)を制御部１２に返却する。尚、この決定処理の詳細については後述する。

制御部１２は、割り当て決定部１６から返却された情報に基づき、ジョブのクライアントへの送信が必要かどうかを判定する(ステップ１０８)。
その結果、ジョブの送信が必要と判定された場合、制御部１２は、空き状況管理部１７、処理能力計算部１８、スタベーション管理部１９に対し、クライアント管理ＤＢ３３で管理される送信先クライアントの情報を更新するよう指示する。これに従い、空き状況管理部１７、処理能力計算部１８、スタベーション管理部１９が、送信先クライアントの情報を更新する(ステップ１０９)。具体的には、空き状況管理部１７が、送信先クライアントのＢｕｓｙＦｌａｇにＢｕｓｙを設定する。また、処理能力計算部１８が、送信するジョブのサイズを現ジョブサイズに設定する。そして、スタベーション管理部１９が、作業開始時刻に現在時刻を設定する。
また、クライアント管理ＤＢ３３の情報の更新が完了すると、制御部１２の指示により、キュー管理部１５は、クライアントジョブキュー３２に格納されたこのジョブの処理済フラグに「処理済」を設定する(ステップ１１０)。その後、ジョブは、送信部１３に渡され、送信部１３が、送信先クライアントにジョブを送信する(ステップ１１１)。
一方、ジョブの送信が必要と判定されなかった場合は、そのまま処理を終了する。

このようにして送信されたジョブに対しクライアントで処理がなされ、その応答としてマスタでの確認を依頼するジョブが送信される。
図７は、このようなジョブを受信した際のマウス字幕編集装置１０の動作を示したフローチャートである。
まず、受信部１１ａが、クライアントからジョブを受信する(ステップ１２１)。
これにより、制御部１２に制御が渡され、制御部１２が、空き状況管理部１７、処理能力計算部１８、スタベーション管理部１９に対し、クライアント管理ＤＢ３３で管理される送信元クライアントの情報を更新するよう指示する。これに従い、空き状況管理部１７、処理能力計算部１８、スタベーション管理部１９が、送信元クライアントの情報を更新する(ステップ１２２)。具体的には、空き状況管理部１７が、送信先クライアントのＢｕｓｙＦｌａｇにＮｏｔＢｕｓｙを設定する。また、処理能力計算部１８が、現在時刻から作業開始時刻を減じた時間を累積作業時間に加算し、現ジョブサイズを累積ジョブサイズに加算する。そして、スタベーション管理部１９が、作業終了時刻に現在時刻を設定する。

次に、制御部１２は、キュー管理部１５に対し、受信したジョブをマスタジョブキュー３１に格納するよう指示する。これに従い、キュー管理部１５は、ジョブをマスタジョブキュー３１に格納する(ステップ１２３)。
また、制御部１２は、空き状況管理部１７に対し、空きクライアントを特定するよう指示する。これに従い、空き状況管理部１７は、クライアント管理ＤＢ３３で管理される全クライアントのＢｕｓｙＦｌａｇを参照し、空きクライアントを特定する(ステップ１２４)。具体的には、今回ジョブの送信元となっているクライアントに対しては、ステップ１２２でＮｏｔＢｕｓｙが設定されているので、必ず空きクライアントとして特定されるが、その他にも空きクライアントがあれば、それもあわせて特定する。そして、空き状況管理部１７は、空きクライアントのＩＤを制御部１２に返却する。
次に、制御部１２は、キュー管理部１５に対し、クライアントジョブキュー３２に未処理ジョブが格納されているかを判定するよう指示する。これにより、キュー管理部１５は、未処理ジョブがあるかどうかを判定する(ステップ１２５)。キュー管理部１５は、未処理ジョブがない場合はその旨を、未処理ジョブがある場合は、未処理ジョブのＩＤを制御部１２に返却する。

その結果、未処理ジョブがないと判定された場合、制御部１２は、警告発生部１４に対し、警告を発生するよう指示する。これに従い、警告発生部１４は、マウス字幕編集装置１０の画面上に警告を表示する(ステップ１２６)。尚、警告発生部１４は、空きクライアントの数に応じて、警告の強さを変えるようにしてもよい。例えば、空きクライアントが１つの場合は、弱い警告を発生し、空きクライアントが２つ以上の場合は、強い警告を発生するようにしてもよい。また、単純に定量化して表示する方法も考えられる。或いは、音の強弱、音色、高さ等によって空きクライアントの数を表すような方法も考えられる。

一方、未処理ジョブがあると判定された場合、制御部１２は、キュー管理部１５、処理能力計算部１８、スタベーション管理部１９に対し、割り当て決定部１６の処理に必要な情報を収集するよう指示する。これに従い、キュー管理部１５、処理能力計算部１８、スタベーション管理部１９は、そのような情報を収集する(ステップ１２７)。
具体的には、キュー管理部１５は、クライアントジョブキュー３２に格納される全てのジョブのジョブサイズ及び処理済フラグを求める。そして、そのジョブサイズ及び処理済フラグを制御部１２に返却する。
また、処理能力計算部１８は、クライアント管理ＤＢ３３を参照し、各クライアントの処理能力を計算する。具体的には、クライアント管理ＤＢ３３に管理される累積ジョブサイズを累積作業時間で除して、各オペレータが単位時間あたりにこなせる仕事の量を求める。そして、処理能力計算部１８は、各クライアントの処理能力を制御部１２に返却する。
更に、スタベーション管理部１９は、クライアント管理ＤＢ３３で管理される作業終了時刻を現在時刻から減ずることにより、空きクライアントの待ち時間を求める。そして、スタベーション管理部１９は、この求めた待ち時間を制御部１２に返却する。

このようにして制御部１２は、全てのクライアントの処理能力、全てのジョブのサイズ及び処理済フラグ、空きクライアントのＩＤ、今回のジョブのＩＤ、空きクライアントの待ち時間の情報を保持する。そして、割り当て決定部１６に対し、ジョブのクライアントに対する割り当てを決定するよう指示する。これに従い、割り当て決定部１６は、ジョブのクライアントに対する割り当てを決定する(ステップ１２８)。そして、割り当て決定部１６は、割り当ての結果(ジョブの送信を一時保留する場合もある)を制御部１２に返却する。尚、この決定処理の詳細については後述する。

制御部１２は、割り当て決定部１６から返却された情報に基づき、ジョブのクライアントへの送信が必要かどうかを判定する(ステップ１２９)。
その結果、ジョブの送信が必要と判定された場合、制御部１２は、空き状況管理部１７、処理能力計算部１８、スタベーション管理部１９に対し、クライアント管理ＤＢ３３で管理される送信先クライアントの情報を更新するよう指示する。これに従い、空き状況管理部１７、処理能力計算部１８、スタベーション管理部１９が、送信先クライアントの情報を更新する(ステップ１３０)。具体的には、空き状況管理部１７が、送信先クライアントのＢｕｓｙＦｌａｇにＢｕｓｙを設定する。また、処理能力計算部１８が、送信するジョブのサイズを現ジョブサイズに設定する。そして、スタベーション管理部１９が、作業開始時刻に現在時刻を設定する。
また、クライアント管理ＤＢ３３の情報の更新が完了すると、制御部１２の指示により、キュー管理部１５は、クライアントジョブキュー３２から送信対象のジョブを取り出し、このジョブの処理済フラグに「処理済」を設定する(ステップ１３１)。その後、ジョブは、送信部１３に渡され、送信部１３が、送信先クライアントにジョブを送信する(ステップ１３２)。
一方、ジョブの送信が必要と判定されなかった場合は、そのまま処理を終了する。

次に、割り当て決定部１６の処理内容について図８を参照して詳細に説明する。
割り当て決定部１６は、空きクライアントの数が単一か複数かを判定する(ステップ１４１)と共に、未処理ジョブの数が単一か複数かを判定し(ステップ１４２)、その結果に基づいて処理を振り分ける。即ち、空きクライアントの数が単一で未処理ジョブの数が複数の場合は、最適ジョブ選定処理を行い、空きクライアントの数が単一で未処理ジョブの数が単一の場合は、ディレイ処理を行い、空きクライアントの数が複数で未処理ジョブの数が単一の場合は、最適クライアント選定処理を行う。尚、空きクライアントの数が複数で未処理ジョブの数も複数というケースは、図６、７のフローチャートに従って処理を行う限り発生しないので、このような場合については考慮していない。

まず、最適ジョブ選定処理について説明する。最適ジョブ選定処理とは、クライアントジョブキュー３２の中に複数の未処理ジョブがあり、空きクライアントが１つである場合に、その空きクライアントに送信すべき最適なジョブを選定するものである。
最適ジョブ選定処理では、まず、割り当て決定部１６が、図９のようなマッピングを行う。即ち、割り当て決定部１６の処理に先立って取得しておいた全クライアントの処理能力Ｐｉ(ｉ＝１，…，ｍ)をＸ軸に、全ジョブのサイズＳｊ(ｊ＝１，…，ｎ)をＹ軸に設定する。次に、処理能力の最小値Ｐ１をＸ座標に持ち、ジョブサイズの最小値Ｓ１をＹ座標に持つ点と、処理能力の最大値ＰｍをＸ座標に持ち、ジョブサイズの最大値ＳｎをＹ座標に持つ点とを線分で結ぶ。そして、この線分上にあり、かつ、空きクライアントＣｋの処理能力ＰｋをＸ座標に持つ点のＹ座標Ｓを求める(ステップ１４３)。本実施の形態では、このＳを空きクライアントに対して送信すべき理想的なジョブのサイズとみなし、未処理ジョブの中からそのサイズがＳに最も近似するジョブを求める(ステップ１４４)。割り当て決定部１６は、そのジョブを空きクライアントに送信するという割り当てを決定し、そのジョブのＩＤを制御部１２に返却する(ステップ１４５)。

ここで、最適ジョブ選定処理を採用したことによる効果を述べる。
図１０(ａ)は、ジョブをＦＩＦＯ(First-In First-Out)に従ってシーケンシャルに処理する場合のタイムチャートであり、図１０(ｂ)は、最適ジョブ選定処理を採用した場合のタイムチャートである。尚、タイムチャートの左側の括弧内は、各クライアントを操作するキーボードエディタの処理能力を示している。
図１０(ａ)において、ジョブ１、２、３は、クライアントＣ、Ｂ、Ａにこの順に割り当てられる。一方、ジョブ４、５は、その発生時に空きクライアントが存在しないため、すぐには処理されずに待たされる。その後、クライアントＡ、Ｃがこの順に空き状態になるので、ジョブ４、５はそれぞれクライアントＡ、Ｃに割り当てられる。ところが、図１０(ａ)では、ジョブ５が、クライアントＣが処理するにはかなりの時間を要するジョブとなっている。そのため、全体としてのスループットが低下してしまっている。
これに対し、図１０(ｂ)のように最適ジョブ選定処理を採用した場合は、各クライアントの処理能力に見合ったジョブを依頼することになるので、スループットの低下は生じない。

次に、ディレイ処理について説明する。ディレイ処理とは、クライアントジョブキュー３２に１つの未処理ジョブがあり、空きクライアントが１つである場合に、ただちにそのジョブを空きクライアントに配信すべきか、又は、配信せずに待機すべきか(ディレイすべきか)を判定するものである。
ディレイ処理でも、まず、割り当て決定部１６が、図１１(ａ)のようなマッピングを行う。即ち、 最適ジョブ選定処理の場合と同様に、空きクライアントＣｋの処理能力Ｐｋに対する理想的なジョブサイズＳを求める(ステップ１４６)。
次に、割り当て決定部１６は、未処理ジョブの最適ジョブサイズ度数Ｄｋを求める(ステップ１４７)。ここで、最適ジョブサイズ度数Ｄｋは、未処理ジョブのサイズＳｊと理想的なジョブサイズＳとを用いて、「Ｄｋ＝１/｜Ｓ−Ｓｊ｜」と定義される。尚、｜Ｓ−Ｓｊ｜は、ＳとＳｊとの距離を表し、Ｓ＝Ｓｊの場合は、ＤｋをＭａｘとする。

また、割り当て決定部１６は、割り当て決定部１６の処理に先立って取得しておいた空きクライアントＣｋの待ち時間に基づいて、待ち時間重みＷｋを求める(ステップ１４８)。尚、本実施の形態では、待ち時間をそのまま用いるのではなく、待ち時間重みに変換して用いている。
例えば、２秒の待ち時間と４秒の待ち時間とを比較すると、単純には後者は前者の２．０倍である。一方、２０分の待ち時間と４０分の待ち時間とを比較しても、単純には上述の場合と同様、後者が前者の２．０倍である。しかしながら、人間の直感としては、２つ目の例の方が、１つ目の例よりも、大きな違いとして実感することとなる。よって、本実施の形態では、待ち時間をそのまま用いるのではなく、待ち時間との対応が線形ではない待ち時間重みに変換して用いているのである。その方法としては、例えば、待ち時間を一次関数で変換することにより待ち時間重みを得る場合に、待ち時間が境界値以下の場合の傾きよりも、待ち時間が境界値以上の場合の傾きを大きくすることが挙げられる。また、その他にも、一次関数や二次関数等の既知の関数を組み合わせて、待ち時間から待ち時間重みを導く方法は種々考えられる。
図１１(ｂ)に、このようにして得られた待ち時間と待ち時間重みを示す。ディレイ処理においては、空きクライアントは１台のみであるので、クライアントＣｋに対する待ち時間重みＷｋのみを図示している。

次に、割り当て決定部１６は、ジョブ最適度合いＦｋを求める(ステップ１４９)。尚、ジョブ最適度合いＦｋは、待ち時間重みＷｋと、最適ジョブサイズ度数Ｄｋとを用いて、「Ｆｋ＝Ｗｋ×Ｄｋ」によって求めることができる。
そして、割り当て決定部１６は、ジョブ最適度合いが予め定めた閾値Ｆ_ＴＨを超えたかどうかを判定する(ステップ１５０)。図１１(ｃ)に、このようにして得られたジョブ最適度合いＦｋ及び閾値Ｆ_ＴＨとの比較の様子を示している。
その結果、閾値Ｆ_ＴＨを超えたと判定された場合は、そのジョブのＩＤを制御部１２に返却する(ステップ１５１)。一方、閾値Ｆ_ＴＨを超えなかったと判定された場合は、ディレイ処理を行い、制御部１２に「送信しない」を返却する(ステップ１５２)。
尚、Ｄｋ＝Ｍａｘの場合、ジョブ最適度合いＦｋは、待ち時間や待ち時間重みに関係なく、閾値Ｆ_ＴＨを超える値になるものとする。

ここで、ディレイ処理を採用したことによる効果を述べる。
図１２(ａ)は、ジョブをＦＩＦＯに従ってシーケンシャルに処理する場合のタイムチャートであり、図１２(ｂ)は、ディレイ処理を採用した場合のタイムチャートである。尚、タイムチャートの左側の括弧内は、各クライアントを操作するキーボードエディタの処理能力を示している。
図１２(ａ)において、ジョブ１、２、３は、クライアントＣ、Ｂ、Ａにこの順に割り当てられる。一方、ジョブ４は、その発生時に空きクライアントが存在しないため、すぐには処理されずに待たされる。その後、クライアントＣが空き状態になるので、ジョブ４は即座にクライアントＣに割り当てられている。ところが、図１２(ａ)では、ジョブ４が、クライアントＣが処理するにはかなりの時間を要するジョブとなっている。そのため、全体としてのスループットが低下してしまっている。
これに対し、図１２(ｂ)のようにディレイ処理を採用した場合は、ジョブ４をクライアントＣで処理せずに、その後に発生したクライアントＣの処理能力に見合ったジョブ５をクライアントＣで処理することになるので、スループットの低下は生じない。

次に、最適クライアント選定処理について説明する。最適クライアント選定処理とは、１つのジョブに対して複数の空きクライアントが存在する場合に最適なクライアントを求めるものである。
まず、割り当て決定部１６は、図１３(ａ)のようなマッピングを行う。即ち、割り当て決定部１６の処理に先立って取得しておいた全クライアントの処理能力をＸ軸に、全ジョブのサイズをＹ軸に設定する。次に、処理能力の最小値をＸ座標に持ち、ジョブサイズの最小値をＹ座標に持つ点と、処理能力の最大値をＸ座標に持ち、ジョブサイズの最大値をＹ座標に持つ点とを線分で結ぶ。そして、この線分上にあり、空きクライアントの処理能力Ｐｉ(ｉ＝１，…，ｍ)をＸ座標に持つ点のＹ座標Ｓｉ(ｉ＝１，…，ｍ)を求める(ステップ１５３)。本実施の形態では、このＳｉ(ｉ＝１，…，ｍ)を、処理能力Ｐｉ(ｉ＝１，…，ｍ)を有する各空きクライアントに対して送信すべき理想的なジョブのサイズとみなし、未処理ジョブのサイズのＳｉ(ｉ＝１，…，ｍ)との近似度である最適ジョブサイズ度数Ｄｉ(ｉ＝１，…，ｍ)を求める(ステップ１５４)。ここで、最適ジョブサイズ度数Ｄｉ(ｉ＝１，…，ｍ)は、未処理ジョブのサイズＳと理想的なジョブサイズＳｉ(ｉ＝１，…，ｍ)とを用いて、「Ｄｉ＝１/｜Ｓｉ−Ｓ｜」と定義される。尚、｜Ｓｉ−Ｓ｜は、ＳｉとＳとの距離を表し、Ｓｉ＝Ｓの場合は、ＤｉをＭａｘとする。

また、割り当て決定部１６は、割り当て決定部１６の処理に先立って取得しておいた各空きクライアントＣｉ(ｉ＝１，…，ｍ)の待ち時間に基づいて、待ち時間重みＷｉ(ｉ＝１，…，ｍ)を求める(ステップ１５５)。尚、待ち時間重みは、ディレイ処理に関して述べたのと同様の方法で算出することができる。
図１３(ｂ)に、このようにして得られた待ち時間と待ち時間重みを示す。最適クライアント選定処理においては、空きクライアントはｍ台あるので、クライアントＣｉ(ｉ＝１，…，ｍ)に対する待ち時間重みＷｉ(ｉ＝１，…，ｍ)を図示している。

次に、割り当て決定部１６は、ジョブ最適度合いＦｉ(ｉ＝１，…，ｍ)を求める(ステップ１５６)。尚、ジョブ最適度合いＦｉ(ｉ＝１，…，ｍ)は、待ち時間重みＷｉ(ｉ＝１，…，ｍ)と、最適ジョブサイズ度数Ｄｉ(ｉ＝１，…，ｍ)とを用いて、「Ｆｉ＝Ｗｉ×Ｄｉ」によって求めることができる。
そして、割り当て決定部１６は、ジョブ最適度合いＦｉ(ｉ＝１，…，ｍ)が最大となる空きクライアントを特定する(ステップ１５７)。図１３(ｃ)に、このようにして得られたジョブ最適度合いＦｉ(ｉ＝１，…，ｍ)の比較の様子を示している。
その結果、割り当て決定部１６は、制御部１２にそのクライアントのＩＤを返却する(ステップ１５８)。
尚、Ｄｉ＝Ｍａｘのクライアントのジョブ最適度合いＦｉは、待ち時間や待ち時間重みに関係なく、他のＤｉ＝Ｍａｘでない全てのクライアントのジョブ最適度合いＦｉよりも大きくなるものとする。

ここで、最適クライアント選定処理を採用したことによる効果を述べる。
まず、第一に、複数の空きクライアントがある場合に、ジョブを個々のクライアントに均等に振り分ける方法がある。しかしながら、この方法だと、処理能力が低いクライアントに仕事がたまるため、全体のスループットは改善されない。
また、第二に、マスタエディタが、その裁量で個々のクライアントにジョブを振り分ける方法もある。しかしながら、この方法だと、マスタエディタ自身のスループットが低下し、結果的にシステム全体のスループットも低下してしまう。
また、第三に、空きクライアントの中から処理能力の高いクライアントに優先的にジョブを配信する方法がある。この場合のジョブ割り当ての例を図１４(ａ)に示す。この場合、ジョブは、処理能力の高いクライアントＡにばかり割り当てられ、処理能力の低いクライアントＢ、Ｃには割り当てられないいわゆるスタベーションが発生している。

尚、スタベーションとは、以下の現象を指す。
マルチスレッドプログラミングにおいて、プライオリティ設定が高いスレッドが繰り返し実行されるようにプログラムしてしまっている場合、よりプライオリティ設定が低いスレッドはいつまでたっても制御が回らない現象をいう。このような現象を引き起こすようなプログラミングは必ずしも適切でないといわれている。
以上に倣い、本実施の形態では、キーボードエディタにいつまでたってもジョブが回ってこない現象を指すこととする。これは、キーボードエディタが機械であれば特に問題を発生させないが、本実施の形態ではキーボードエディタが人間であるため、ジョブを回さないことは重大な問題となるのである。

更に、第四に、空きクライアントの中から待ち時間が長いクライアントに優先的にジョブを配信する方法もある。この場合のジョブ割り当ての例を図１４(ｂ)に示す。この場合、仕事量の大きいジョブ４が、処理能力の低いクライアントＣに割り当てられることもあり得るため、システム全体のスループットは最適化されない。
これに対し、図１４(ｃ)のように最適クライアント選定処理を採用した場合は、各ジョブは、そのジョブを処理するのに相応しい能力を有するクライアントに依頼されることになるので、スループットを最適化できる。

次に、本実施の形態におけるキーボード字幕編集装置２０について詳細に説明する。
図１５は、本実施の形態におけるキーボード字幕編集装置２０の機能構成を示した図である。このキーボード字幕編集装置２０は、受信部２１と、制御部２２と、送信部２３と、表示制御部２４と、音声再生部２５と、計時部２６とを備える。
受信部２１は、マウス字幕編集装置１０からジョブを受信する機能を有し、制御部２２は、キーボード字幕編集装置２０の全体動作を制御する機能を有し、送信部２３は、マウス字幕編集装置１０へジョブを送信する機能を有する。また、表示制御部２４は、キーボード字幕編集装置２０の画面上への情報の表示を制御する機能を有し、音声再生部２５は、音声データ記憶部４０に記憶された音声データの指定された部分を再生する機能を有し、計時部２６は、タイマとしての機能を有する。
尚、これらの各機能部分は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、キーボード字幕編集装置２０のＣＰＵが、受信部２１、制御部２２、送信部２３、表示制御部２４、音声再生部２５、計時部２６を実現するプログラムを外部記憶装置から主記憶装置に読み込んで処理を行う。

本実施の形態のキーボード字幕編集装置２０は、このような構成を備えることにより、以下に述べる機能を実現している。
第一に、間違い行へのオートジャンプ機能である。
この機能では、ある間違い行の修正が完了すると、次の間違い行へ自動的にジャンプし、その行に対応する音声を自動的に再生する。図１６の例では、５行目の「オンデアンド」の修正が完了すると、１１行目の「での家庭」にジャンプし、その行の修正が完了すると、１３行目の「すいません。」にジャンプしている。
このような構成により、キーボードエディタは、文字列の入力だけに専念することができるため、高いスキルレベルを要求されない。また、編集の効率も格段に向上される。

第二に、のりしろ付き強調再生機能である。
この機能では、間違い行に対応する音声のみでなく、その前後の音声も含めて再生する。また、間違い行に対応する音声の前の音声をフェードインさせ、間違い行に対応する音声の後の音声をフェードアウトさせることにより、間違い行に対応する音声を強調する。尚、本明細書では、このフェードイン、フェードアウトさせる音声部分を「のりしろ」に見立て、この機能を「のりしろ付き強調再生機能」と称しているのである。
形態素解析に基づいて決定された字幕文節を、のりしろの範囲(フェードインさせるのりしろからフェードアウトさせるのりしろまでの範囲)とした場合の例を図１７に示す。
ここで、字幕文節とは、名詞、動詞語幹、格助詞、助動詞等の品詞に基づいた形態素ではなく、例えば、「本日は晴天なり」という文であれば、「本日は」と「晴天なり」等のそれぞれに独立した意味をなすかたまりを意味するものとする。このような字幕文節の生成については、形態素の個々の品詞に基づいて単純に規則化することが可能である。また、一般的に連続する間違い行について分割されることはないものとする。
尚、のりしろの範囲は、字幕行の分割の方法に応じて、種々の方法で決定することができる。例えば、固定行を用いて決定することも考えられる。

第三に、キー入力連動再生機能である。
この機能では、図１８に示すように、キーボードエディタがキー入力を行っている間はその集中力を奪わないようにするため音声の再生を停止し、キーボードエディタのキー入力が止まったら、音声を再生することによる入力の催促(音声催促)を行う。本手法は、従来の、カーソルによる点滅や、「フィールドに正しく名前を入力して下さい。」等の催促用メッセージ(ポップアップメッセージ又は音声メッセージ)と違い、キー入力を行う際に参照すべき情報を直接かつ動的に再生するものである。従って、これらの従来の手法に比べて高い効果が得られるものである。
尚、本手法と従来の手法を、オーバーヘッド、催促の効果、情報の有益性の３つの観点から比較すると次のようになる。
即ち、カーソル点滅は、オーバーヘッドは少なくてすむが、催促の効果や情報の有益性では劣る。ポップアップメッセージや音声メッセージは、催促の効果はあるが、オーバーヘッドや情報の有益性では劣る。これに対し、本手法は、オーバーヘッドも少なく、催促の効果も期待でき、情報の有益性もある優れた手法である。

次に、これらの機能を実現するキーボード字幕編集装置２０の動作について詳細に説明する。
図１９は、キーボード字幕編集装置２０の動作を示すフローチャートである。
まず、受信部２１が、ジョブを受信する(ステップ２０１)。尚、このジョブには、上述したように、表示すべき各字幕行について、音声ファイルにおける開始時間、音声認識結果、間違い行であるかどうか、の情報が含まれている。
これにより、制御部２２へ制御が移り、表示制御部２４に対し、キーボードフォーカスを間違い行へジャンプさせるよう指示する。これに従い、表示制御部２４は、キーボードフォーカスを間違い行へジャンプさせる(ステップ２０２)。具体的には、ジョブに各字幕行が間違い行であるかどうかの情報が含まれるので、表示制御部２４は、制御部２２からその情報の通知を受けることにより、そのような間違い行へのジャンプを実現する。

そして、制御部２２は、音声再生部２５に対し、間違い行に対応する音声を再生するよう指示する。これに従い、音声再生部２５が、音声を再生する(ステップ２０３)。具体的には、ジョブに開始時間の情報が含まれるので、音声再生部２５は、制御部２２からその情報の通知を受ける。そして、音声データ記憶部４０に記憶された音声データを取得し、通知された情報によって指定された部分の再生を行う。また、その際、間違い行に対応する音声の前の音声をフェードインさせ、間違い行に対応する音声の後の音声をフェードアウトさせる制御も行う。
一方で、制御部２２は、計時部２６に対し、タイマのセットを指示する。これに従い、計時部２６は、タイマをセットする(ステップ２０４)。尚、キー入力がない場合は、ここでセットされた時間が経過すると、再び音声の再生が開始される。従って、ここでセットする時間は、再生される音声の長さに一定の待ち時間を加算した時間とする。

次に、制御部２２は、キーボードからキー入力があったかどうかを判定する(ステップ２０５)。
その結果、キー入力がないと判定された場合は、セットされた時間が経過したかどうかを判定し(ステップ２１０)、経過していなければ、経過するまでステップ２０５の判定を繰り返す。また、セットされた時間が経過していれば、音声を再び再生する(ステップ２０３)。
一方、キー入力があったと判定された場合は、音声再生中であるかどうかを判定し(ステップ２０６)、再生中でなければ何もしないが、再生中であれば、その音声をインタラプトする(ステップ２０７)。そして、キー入力が確定キーによるものかどうかを判定する(ステップ２０８)。その結果、確定キーによるキー入力でなければ、計時部２６に対し、タイマをリセットするように指示する。これに従い、計時部２６は、タイマをリセットする(ステップ２０９)。即ち、ステップ２０３の音声再生の開始から一定時間後に再び音声を再生するという設定を、今回のキー入力から一定時間後に再び音声を再生するという設定に変更するのである。

その後、制御部２２は、セットされた時間を経過したかどうかを判定し(ステップ２１０)、経過していなければ、経過するまでステップ２０５の判定を繰り返す。また、セットされた時間が経過していれば、音声を再び再生する(ステップ２０３)。一方、ステップ２０８でキー入力が確定キーによるものであると判定された場合は、次の間違い行があるかどうかを判定する(ステップ２１１)。具体的には、ジョブに各字幕行が間違い行であるかどうかの情報が含まれるので、制御部２２は、その情報に基づいて間違い行の有無を判定する。
その結果、間違い行があれば、ステップ２０２に戻り、間違い行がなければ、送信部２３に確認依頼のジョブを受け渡し、送信部２３がそのジョブをマウス字幕編集装置１０に送信する(ステップ２１２)。
尚、音声を再生させるための時間の長さ、音声を再生/停止するための具体的なキーの一覧については自由に設定できるものとする。

以上により、本実施の形態の説明を終了する。
本実施の形態では、間違い行を特定し、編集結果を確定するための装置と、間違い行を編集する装置とを分ける構成を採用した。このような構成により、スキルレベルの高い責任ある人材を前者の装置の操作にのみ従事させ、後者の装置の操作にはスキルレベルの低い人材を従事させることが可能となる。従って、人件費の大幅な削減が期待できる。更に言うと、従来の字幕編集装置では既述のように多くの問題点が存在していたためボランティアの人たちに編集作業に協力してもらうことは難しかった。ところが、本発明によってインターネット等を通じて全国の字幕付けボランティアに協力してもらうことが現実的になる。そういった環境が整備された時の字幕普及への社会的効果は計り知れない。
また、本実施の形態では、間違い行の特定、編集結果の確定といったマウスによる操作部分と、間違い行の修正というキーボードによる操作部分とを分ける構成を採用した。このような構成を採用したことにより、マウスとキーボードを持ち替えて操作する必要がなくなる。従って、操作性の大幅な向上が期待できる。
更に、本実施の形態では、間違い行の修正にあたり、オートジャンプ機能、のりしろ付き強調再生機能、キー入力連動再生機能を実現した。これにより、間違い行を修正する際の操作性は更に向上される。

更にまた、本実施の形態では、各キーボードエディタの処理能力がばらつき、かつ、動的に変動することを想定している。また、各ジョブは、その発生のタイミング、終了のタイミングが不定期であり、かつ、そのサイズも不定であることを想定する。そのような状況において、ジョブのキーボード字幕編集装置への割当てを最適化することにより、スタベーション、デッドロック、スループット低下を引き起こすことがないようにしている。これにより、多様な労働力の確保が可能になり、その労働時間も短縮されるため、大幅な人件費の節約が期待できる。

(第２の実施の形態)
図２０は、本実施の形態における字幕編集システムの構成を示した図である。この字幕編集システムは、マウス字幕編集装置１０と、キーボード字幕編集装置２０と、音声認識装置３０と、音声データ記憶部４０と、字幕データ記憶部５０とから構成される。尚、第１の実施の形態では、キーボード字幕編集装置２０から字幕データ記憶部５０への字幕の書き込みは、マウス字幕編集装置１０を介して行われるような構成となっていたが、本実施の形態では、キーボード字幕編集装置２０から字幕データ記憶部５０へ直接字幕が書き込まれるような構成となっている。そして、図示しないが、表示装置が、字幕データ記憶部５０に書き込まれた字幕をリアルタイムに取得し、音声データ記憶部４０に記憶された音声データに基づく音声の再生と同期させて表示する。
尚、本実施の形態におけるマウス字幕編集装置１０及びキーボード字幕編集装置２０として用いるのに好適なコンピュータのハードウェア構成は、図３に示したものと同様であるので、詳しい説明は省略する。
また、本実施の形態のマウス字幕編集装置１０は、キーボード字幕編集装置２０からのジョブを受信しないので、図６及び図８に示した動作を行い、図７に示した動作は行わない。
更に、本実施の形態のキーボード字幕編集装置２０は、ほぼ図１９に従った動作を行う。但し、ステップ２１２では、マウス字幕編集装置１０にジョブを送信する処理ではなく、編集後の字幕を字幕データ記憶部５０に対して書き込む処理を行う。

ここで、本実施の形態による表示の例を図２１に示す。
図２１(ａ)は、字幕の編集が連続して完了している箇所までを表示する場合の例である。この例では、「今までの取り組みが、オンデマンドビジネスを実現する上での過程にすぎません。」という箇所までは全て編集が完了している。仮に、この後に、「現在、私たちは、過去の取り組みを基盤とし、次なる課題に取り組んでいます。」という音声と、「それは、市場のスピードと、従業員のリクエストに即応できるオンデマンド企業への変革です。」という音声とが続き、それぞれ別のキーボードエディタに編集が依頼されたとする。この場合において、後者の編集が完了していたとしても、前者の編集が完了するまでは表示しないようにしている。

また、図２１(ｂ)は、字幕の編集が完了している箇所は全て表示する場合の例である。この例では、「現在、私たちは、過去の取り組みを基盤とし、次なる課題に取り組んでいます。」については、字幕の編集が完了している。しかし、「今までの取り組みが、オンデマンドビジネスを実現する上での過程にすぎません。」、及び、「それは、市場のスピードと、従業員のリクエストに即応できるオンデマンド企業への変革です。」については、字幕の編集が完了しておらず、未確定のまま表示されている。
尚、未確定のままの表示としては、その箇所に文が存在することのみを示す情報を表示する方法を採用しても良いし、図２１(ｂ)のように、正しい文字列と未確定の文字列とを表示形態で区別するようにしてもよい。後者の場合、正しい文字列か未確定の文字列かは、マスタエディタによって設定された確信度の情報を参照することができる。

以上により、本実施の形態の説明を終了する。
本実施の形態は、第１の実施の形態における効果に加え、字幕をリアルタイムに表示することができるという効果を有する。
尚、上述した第１及び第２の実施の形態では、マウス字幕編集装置１０及びキーボード字幕編集装置２０から共通にアクセス可能な音声データ記憶部４０を設け、音声データはここに格納するようにした。しかしながら、マウス字幕編集装置１０及びキーボード字幕編集装置２０から音声データに必ずしも共通にアクセスできるようにする必要はない。例えば、マウス字幕編集装置１０が音声データを保持しておき、その音声データの必要な部分のみを切り出してキーボード字幕編集装置２０に字幕データと共に送信するような形態でも構わない。
また、第１及び第２の実施の形態では、マウス字幕編集装置１０とキーボード字幕編集装置２０と間で字幕データ自体を送受信するように構成している。しかしながら、字幕データ自体を送受信しないように構成することも可能である。即ち、字幕データを、マウス字幕編集装置１０及びキーボード字幕編集装置２０から共通にアクセス可能な記憶領域に記憶し、マウス字幕編集装置１０からキーボード字幕編集装置２０へは、その記憶領域のアドレス情報や字幕データにおける間違い行の位置情報を送信するようにしてもよい。

更に、本実施の形態に対しては、次のような技術を有機的に組み込むことも可能である。
１．話速変換
のりしろ付き強調再生機能において、間違い行に対応する音声を更に強調するため、その音声のみを話速変換技術を応用して「ゆっくり」と再生することも考えられる。但し、話速変換自体の処理は一般に重たいので、本技術の導入によって他の処理のパフォーマンスが低下しないように配慮する必要がある。
２．音声コマンド
音声を再生したり停止したりする際に、「再生」、「停止」等の音声コマンドを使用することができる。但し、音声コマンドの処理は一般に重たいので、本技術の導入によって他の処理のパフォーマンスが低下しないように配慮する必要がある。

また、第１の実施の形態で述べた「ほぼ正しい字幕行」の表示についても検討を加えることが可能である。例えば、図２１(ｂ)に示した表示例は、「ほぼ正しい字幕」の表示例と捉えることもできる。即ち、「ほぼ正しい字幕行」に対しては、その確信度に応じて、「正しい字幕行」と異なる形態で表示することが可能である。図２１(ｂ)では、「正しい字幕行」は通常の字体で表示し、「ほぼ正しい字幕行」は斜体字で表示している。

以下、本発明の従来技術に比べた優位性をまとめる。
１) 従来の字幕編集装置は、基本的に、音声フォーカス移動、音声再生、音声停止、キーボードフォーカス移動、行の分割・連結調整の５つの機能しか有していなかった。従って、それ以外の間違い行の特定や修正の操作を編集者が行わなくてはならなかった。しかも、そのような無駄な処理は字幕行ごとに発生するので、その発生回数は膨大となる。
２) 本発明において、マスタエディタは、自動的に再生される音声に応じて各字幕行の確信度をチェックし、必要な文単位でキーボードエディタにサブミットするだけである。音声の停止、再生、再生箇所のポイント等の操作は基本的に必要ない。更に、正しい文字列の記憶も必要ない。最終的に字幕として確定する作業は従来と同様である。
３) 本発明において、キーボードエディタは、間違い行をキーボードで編集し、最後に行確定するだけである。よって、既述のように、人件費が安く、スキルレベルの低い人でも編集が容易であることは明らかである。

ここで、具体的に、１つの間違い行の編集手順について、従来技術と本発明とを比較する。図２２は、人間の手、目、耳に関係する操作及び動作をステップごとに示したものである。尚、ここでは、典型的な例として、３回音声を聞いた場合を想定する。
図２２から、マウス字幕編集装置及びキーボード字幕編集装置共に、従来の字幕編集装置よりも操作性、コストにおいて優れていることが明らかである。

最後に、本発明の応用例について述べる。
例えば、音楽への応用が考えられる。
所望の音楽素材に対してその譜面や歌詞が入手できないケースは珍しくない。そのような音楽素材に対し、音符や歌詞を付加する作業は字幕付け作業と同様、大変手間がかかる。音声認識装置を音楽認識ソフトと言い換え、字幕を音符や歌詞と言い換えても、本発明の有効性は変わらない。
また、動画に対する注釈付けにも応用することができる。所望の動画素材に対して注釈をタイムスタンプとして埋め込み、それを後々検索システム等によってインデックスとして使用することがしばしば行われる。このような作業もやはりコンテンツの長さによっては膨大な作業となり得る。そこで、音声認識装置を動画認識装置と言い換え、字幕を動画における注釈と言い換え、音声催促を動画による催促や動画に対応した音声による催促と言い換えることができる。

更に、文章やリッチコンテンツ等の自動コンテンツ生成も想定される。近年、コンピュータによって自動的にコンテンツが生成されることは珍しくなくなった。もちろん人間の手によってコンテンツが生成される場合もある。しかし、コンテンツには、多少の誤りや変更点が含まれていることを想定しなくてはならない。本発明における音声認識装置をコンテンツ生成装置と言い換え、字幕をコンテンツと言い換え、音声催促をコンテンツ表示による催促又はそのコンテンツから音声合成によって得られた音声による催促と言い換えることが可能である。

本発明の第１の実施の形態におけるシステム構成を示したブロック図である。 本発明の実施の形態のマウス字幕編集装置及びキーボード字幕編集装置における表示例を示した図である。 本発明の実施の形態におけるマウス字幕編集装置及びキーボード字幕編集装置のハードウェア構成を示したブロック図である。 本発明の実施の形態におけるマウス字幕編集装置の機能構成を示したブロック図である。 本発明の実施の形態におけるジョブサイズの大小について説明するための図である。 本発明の実施の形態におけるマウス字幕編集装置の動作を示したフローチャートである。 本発明の第１の実施の形態におけるマウス字幕編集装置の動作を示したフローチャートである。 本発明の実施の形態におけるマウス字幕編集装置の動作を示したフローチャートである。 本発明の実施の形態における最適ジョブ選定処理の説明に用いる図である。 本発明の実施の形態における最適ジョブ選定処理の効果を示す図である。 本発明の実施の形態におけるディレイ処理の説明に用いる図である。 本発明の実施の形態におけるディレイ処理の効果を示す図である。 本発明の実施の形態における最適クライアント選定処理の説明に用いる図である。 本発明の実施の形態における最適クライアント選定処理の効果を示す図である。 本発明の実施の形態におけるキーボード字幕編集装置の機能構成を示したブロック図である。 本発明の実施の形態のキーボード字幕編集装置におけるオートジャンプ機能について説明するための図である。 本発明の実施の形態のキーボード字幕編集装置におけるのりしろ付き音声強調再生機能について説明するための図である。 本発明の実施の形態のキーボード字幕編集装置におけるキー入力連動再生機能について説明するための図である。 本発明の実施の形態におけるキーボード字幕編集装置の動作を示したフローチャートである。 本発明の第２の実施の形態におけるシステム構成を示したブロック図である。 本発明の第２の実施の形態におけるリアルタイム字幕表示の例を示した図である。 本発明における操作手順と従来技術における操作手順とを比較するための図である。 従来技術について説明するための図である。

符号の説明

１０…マウス字幕編集装置、１１ａ…受信部、１１ｂ…コマンド受付部、１２…制御部、１３…送信部、１４…警告発生部、１５…キュー管理部、１６…割り当て決定部、１７…空き状況管理部、１８…処理能力計算部、１９…スタベーション管理部、２０…キーボード字幕編集装置、２１…受信部、２２…制御部、２３…送信部、２４…表示制御部、２５…音声再生部、２６…計時部、３０…音声認識装置、４０…音声データ記憶部、５０…字幕データ記憶部

Claims (15)

1. 音声又は映像に基づいて作成されたテキストデータを編集するためのコンピュータシステムであって、
   前記テキストデータを表示すると共に前記音声又は映像を出力し、外部からの指示に応じて、当該テキストデータの編集すべき部分を特定し、当該テキストデータと、当該部分を特定する情報とを出力する第１のコンピュータと、
   前記第１のコンピュータにより出力された前記テキストデータを表示し、前記第１のコンピュータにより出力された前記情報によって特定される前記部分に編集のためのフォーカスを位置付けると共に当該部分に対応する前記音声又は映像を出力した後、当該部分を、外部からの指示に応じて編集する第２のコンピュータと
   を備え、
   前記第２のコンピュータは、前記編集すべき部分の前後の部分に対応する音声又は映像を、当該編集すべき部分に対応する音声又は映像とは異なる態様で出力する、コンピュータシステム。
2. 前記第１のコンピュータは、ポインティングデバイスからの指示に応じて、前記テキストデータの編集すべき部分を特定し、
   前記第２のコンピュータは、キーボードからの指示に応じて、前記部分を編集する、請求項１記載のコンピュータシステム。
3. 前記第１のコンピュータは、前記第２のコンピュータによる前記部分の編集を確定させるための処理を行う、請求項１記載のコンピュータシステム。
4. 前記第２のコンピュータは、一の前記部分の編集が完了した旨の入力があると、他の前記部分へ前記フォーカスを移動する、請求項１記載のコンピュータシステム。
5. 前記第２のコンピュータは、前記編集すべき部分に対応する前記音声又は映像を、当該部分に対する編集データの入力に応じて停止する、請求項１記載のコンピュータシステム。
6. 前記第２のコンピュータにより編集された前記部分を出力する第３のコンピュータを更に備えた、請求項１記載のコンピュータシステム。
7. 前記第３のコンピュータは、前記第２のコンピュータにより編集された前記部分に先行して出力すべき部分の中に、編集が完了していない部分が存在していない場合に、当該編集された部分を出力する、請求項６記載のコンピュータシステム。
8. 前記第３のコンピュータは、前記第２のコンピュータにより編集された前記部分に先行して出力すべき部分の中に、編集が完了していない部分が存在している場合に、当該編集された部分と当該編集が完了していない部分とを区別して出力する、請求項６記載のコンピュータシステム。
9. 音声又は映像に基づいて作成されたテキストデータを編集するための方法であって、
   第１のコンピュータが、前記テキストデータを表示すると共に前記音声又は映像を出力し、外部からの指示に応じて、当該テキストデータの編集すべき部分を特定し、当該テキストデータと、当該部分を特定する情報とを出力するステップと、
   第２のコンピュータが、前記第１のコンピュータにより出力された前記テキストデータを表示し、前記第１のコンピュータにより出力された前記情報によって特定される前記部分に編集のためのフォーカスを位置付けると共に当該部分に対応する前記音声又は映像を出力した後、当該部分を、外部からの指示に応じて編集するステップと
   を含み、
   前記第２のコンピュータは、前記編集すべき部分の前後の部分に対応する音声又は映像を、当該編集すべき部分に対応する音声又は映像とは異なる態様で出力する、方法。
10. 前記第１のコンピュータは、ポインティングデバイスからの指示に応じて、前記テキストデータの編集すべき部分を特定し、
    前記第２のコンピュータは、キーボードからの指示に応じて、前記部分を編集する、請求項９記載の方法。
11. 前記第２のコンピュータは、一の前記部分の編集が完了した旨の入力があると、他の前記部分へ前記フォーカスを移動する、請求項９記載の方法。
12. 前記第２のコンピュータは、前記編集すべき部分に対応する前記音声又は映像を、当該部分に対する編集データの入力に応じて停止する、請求項９記載の方法。
13. 音声又は映像に基づいて作成されたテキストデータを編集するためのプログラムであって、
    クライアントコンピュータに、
    前記テキストデータと、前記テキストデータの編集すべき部分を特定する情報とを、サーバコンピュータから受信する機能と、
    受信した前記テキストデータを表示する機能と、
    受信した前記情報によって特定される前記部分に編集のためのフォーカスを位置付けると共に当該部分に対応する前記音声又は映像を出力する機能と、
    その後、前記部分を、外部からの指示に応じて編集する機能と
    を実現させ、
    前記出力する機能では、前記編集すべき部分の前後の部分に対応する音声又は映像を、当該編集すべき部分に対応する音声又は映像とは異なる態様で出力する、プログラム。
14. 前記出力する機能では、一の前記部分の編集が完了した旨の入力があると、他の前記部分へ前記フォーカスを移動する、請求項１３記載のプログラム。
15. 前記出力する機能では、前記編集すべき部分に対応する前記音声又は映像を、当該部分に対する編集データの入力に応じて停止する、請求項１３記載のプログラム。

Images