JP4282475B2 - システム内の通信を管理する命令を格納するコンピュータ読取り可能媒体 - Google Patents

Description

本発明は、システム内の通信を管理する方法、ユーザユニット、および命令を格納するコンピュータ読取り可能媒体に関する。このシステムは、表面から情報を読み込むことができる少なくとも一台のユーザユニット、およびユーザユニットと通信するように構成された複数のサーバを含む。

情報は、ペンおよび紙を使用して書き込み、伝達されることが多い。しかし、このような紙面による情報は効率良く管理し伝達するのが難しい。

情報を管理し伝達するために、コンピュータが広範囲にわたり使用されている。通常、情報はキーボードにより入力され、コンピュータの内部または外部メモリ、例えばハードディスクに格納される。ただし、キーボードによる情報の入力は比較的低速の処理であり、この処理中にエラーの発生する危険性は大きい。また、コンピュータ画面上に大量のテキストを読出すことは特に不便である。描画または画像といった図形情報は、スキャナなど、時間がかかり、扱いにくく、不満足な結果になることが極めて多い方法により、別個の画像読取装置によって入力されることが多い。しかし、情報が一度コンピュータに入力されると、例えば、インターネット接続を介した電子メールまたはＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）メッセージ、またはファックスモデムを介したファックスと同様に）、他者と簡単に通信することができる。

本出願人は、参照により本明細書に引用したものとする、国際出願ＷＯ ０１／１６６９１にこの問題の対応策を提案し、その中で、位置コードを備える書き込み表面を有する製品の使用を予見している。前記位置コードは、表面上に複数の位置をコード化し、書き込み表面上に書き込まれている情報の電子記録を可能にする。情報はディジタルペンにより書き込まれ、このペンは位置コードを検出し、書き込まれた情報に対応する位置を計算するセンサを有する。また、前記製品は一つまたは複数の起動アイコンを有し、このアイコンは、ディジタルペンにより検出されると、ペンを始動させて、ペンにより記録された情報を利用する所定のそれぞれの動作を開始する。

詳細には、位置コード化製品は組込み機能を備え、この機能においては、起動アイコン内の位置および書込み表面内の位置など、前記製品のさまざまな位置がさまざまな機能に対して専用化されている。さらに、位置コードにより、一台の製品上に必要な位置の数より多い、多数の位置の座標のコーディングが可能になる。このように、位置コードは、この位置コードがコーディングできるすべての位置により定義される仮想表面を形成し、この仮想表面上のさまざまな位置は、さまざまな機能および／またはアクタに対して専用化されていると考えることができる。

上記の概念は、多くのさまざまな目的に使用することが可能である。ペンと位置コード化製品の組み合わせは、コンピュータ、ＰＤＡ、携帯電話など、入力デバイスとして使用することが可能である。例えば、位置コード化ノートバッド上に書き込まれたテキストおよびスケッチを、ペンを介してコンピュータに転送することが可能である。加えて、ペンと位置コード化製品を組み合わせることにより、広域通信に専門化した製品上の位置コードによって、ペンを介して製品から直接広域通信ができる。例えば、ペンにより記録された情報は、ファックス通信、電子メールまたはＳＭＳメッセージに変換され、その後ペンから受信者に送信される。さらに、ペンと位置コード化製品の組み合わせは、電子商取引で使用できる。例えば、ディジタルペンを使用して、雑誌の位置コード化された広告から、該当するサービスに割り当てされた広告内の位置コードにより、商品を注文することができる。

通常、ディジタルペンまたはそれに相当するデバイスを備えるように設計されているシステムは、ペンおよび複数の位置コード化製品に加えて、ＰＬＳ（Ｐａｐｅｒ Ｌｏｏｋ−ｕｐ Ｓｅｒｖｉｃｅ）と呼ばれるサービスを実行する少なくとも一台の検索サーバ、およびシステム内でアクタまたはＳＨ（Ｓｅｒｖｉｃｅ Ｈａｎｄｌｅｒｓ）として動作する複数のアプリケーションサーバを含む。検索サーバはデータベースを利用して、位置コードにより定義された仮想表面およびこの仮想表面に関連する情報、すなわち、仮想表面上の全ての位置の機能およびこの各位置に関連するアクタを管理する。アプリケーションサーバは、ディジタル情報の格納または中継、並びに受信者への情報または商品の送信の始動といった、ディジタルペンの代わりにサービスを実行するサーバである。

前述のシステムでは、ディジタルペンが、一台または複数の検索サーバおよび複数の前記アプリケーションサーバと通信する方法を予測することは、非常に困難である。このようなシステムはサービスまたはアプリケーションの設計を望むアクタに多数の可能性を提供する。この可能性には、例えば、どの単一または複数の別のサービスまたはアプリケーションサーバを特定のサービスに含めるか、特定のサービスを使用するときのディジタルペンとさまざまなサービス間の対話、サービス利用中にディジタルペンによりどのような動作が実行されるべきかなどがある。また、検索サーバのオペレータは、ディジタルペンとさまざまなアクタ間において、特にサービスの始動中に、通信されるデータおよび通信自体を制御できることにより便宜を得る。さらに、システム内には、例えばさまざまな負担を負う（例えば、ディジタルペンが通信する検索サーバを制御するためのメカニズムが必要とされる）複数の検索サーバが存在できる。

したがって、解決する必要がある一つの問題は、簡単で効率の良い方法で、上記のようなシステム内の通信をどのようにして調整し、制御するかである。

本発明の目的は、表面から情報を読み込みできるユーザユニットと、ユーザユニットをサポートするサービスを実行するサーバ間との通信を制御する方法を提供することである。

別の目的は、検索サーバが、ユーザユニットが関与する通信を制御できるようにする、ユーザユニットで使用される通信プロトコルを提供することである。特に、一つの目的は、検索サーバが、どの情報（この情報はディジタルペンにより格納されているか、またはり読み込まれるかのどちらか）がディジタルペンと通信するアプリケーションサーバにアクセス可能でなければならないか、に関して排他的制御を実行できるようにする。

本発明によれば、独立請求項１に定義されている形態を有する方法、独立請求項２３に定義されている形態を有するユーザユニット、および独立請求項２４に定義されている形態を有するコンピュータ読取り可能媒体により、前記問題は解決され、目的は達成される。

本発明は、表面から情報を読み込み、その情報の少なくとも一部をサーバに通信できる少なくとも一つのユーザユニットと、表面から読み込む情報に関連する情報管理ルールを格納する検索サーバと、少なくとも一台のアプリケーションサーバとを含むシステムに応用できる。本発明によれば、ユーザユニットは、検索サーバから制御データの一つまたは複数の命令を受け取る。その後、ユーザユニットは、これらの制御データに基づき、どの特定の情報データがアプリケーションサーバにアクセス可能でなければならないかを決定できる、すなわちアプリケーションサーバへの通信が可能になる。その後、特定の情報データに応答するアプリケーションサーバから命令を受け取ると、ユーザユニットは、制御データに基づき、これらの特定の情報データが通信可能かどうか決定する。通信可能であれば、特定の情報データは、受信するアプリケーションサーバに対してメッセージで送信される。

さまざまなアプリケーションサーバが、さまざまな目的を有するサービスを提供することは理解されるであろう。サービスの種類に依存して、サービスは低価格にも高価格にもなりうる（サービスを使用するユーザユニットについても、またはサービスを提供するアクタについても）。例えば、低価格のサービスは、ユーザユニットが単にある種の詳細な情報を指示できるサービスであることもあり、一方、高価格のサービスは株式仲買サービスである可能性もある。

本発明を使用すれば、システム内の検索サーバは排他的命令を使用することにより、どのような情報がユーザユニットから特定のサービスを実行するアプリケーションサーバに通信できるかを制御する。またこれは、前記検索サーバが、どの情報をユーザユニットにより格納または読み込みできないようにするのか、どの情報をアプリケーションサーバによりアクセスできないようにするのか、を保証することを意味する。検索サーバのオペレータは、アプリケーションサーバにより実現されるサービスのオペレータと合意を取ることができ、この合意において、検索サービスのオペレータはサービスの一定の詳細事項を保証する。例えば、株式仲買サービスに対しては、このサービスのオペレータのみが、サービスと関連付けされ、かつユーザユニットによって格納されている課金番号へのアクセスを提供される必要がある。一方、注文情報に対して使用されるだけの低価格のサービスに対しては、この情報発注サービスを実現するアプリケーションサーバは、単に、ユーザユニットに格納されている名前および住所属性など、可能な限りわずかなユーザユニット情報にしかアクセスできないようにすべきである。

さらに、本発明により、検索サーバが、ユーザユニットが関与する通信のセキュリティのレベルを制御できるようになる。特定のサービスまたは特定のユーザユニットの申し込みに対してより高度なセキュリティを提供することにより、そのようなサービスまたは申し込みをより高い価格で提供し、オペレータの収入を増やすことが可能になる。

検索サーバからの特定の命令の制御データは、ユーザユニットにより格納されている一つまたは複数の属性を定義する一つまたは複数のパラメータ、またはページアドレスを定義するパラメータ、すなわち、ユーザユニットが情報をそこから読み込むことができる表面の限定されたエリアのアドレス、のどちらかに対応している。前者の場合、これは、ユーザユニットが、ユーザユニットにより格納されている属性パラメータの値に対応する特定の情報データを通信できることを意味する。後者の場合、ユーザユニットが、特定のページからユーザユニットにより読み込まれる位置に対応する、特定の情報データを通信できることを意味する。

ユーザユニットは、本発明によれば、検索サーバによる独占使用である特定の命令セットに応答する。詳細な説明で述べられるそれらの定義および使用によれば、これらの排他的命令はさまざまな目的を有し、かつ、ユーザユニットに格納または読み込みされているどの情報データが、アプリケーションサーバにアクセスできる必要があるかを制御する命令を含んでいる。

通常、前記ユーザユニットは特定の情報データに応答する命令から、特定の受信するアプリケーションサーバを識別するアドレスを抽出する。このアドレスが必要とされるのは、特定の情報データの受信アプリケーションサーバが、特定の情報データに応答する命令がそこから受信されたアプリケーションサーバとは異なるサーバである場合である。

有利には、ユーザユニットの構成は、ユーザユニットが特定の情報データを含むメッセージを送信した、受信アプリケーションサーバから受け取った後続命令から結果のデータを抽出するように構成される。これらの結果データは、ユーザユニットに格納され、その後に、アプリケーションサーバにより実行される動作の結果の表示として、検索サーバに送信される。したがって、その結果、通信は、ユーザユニットが関与する動作の結果を追跡できるように制御される。この方法で、システム内のオペレータ、例えば記検索サーバのオペレータは、実行される動作、したがって全体的なシステム内で使用されるサービスに対して、アプリケーションサーバにより実現されているサービスのオペレータのような、ユーザユニット加入者および／またはアクタの請求を管理する基礎を提供される。

ユーザユニットで受信された命令を含むメッセージおよびその結果としてユーザユニットから送信された情報データを含むあらゆるメッセージは、ユーザユニットのラウンドトリップを定義する。ユーザユニットが表面から読み込まれたデータを送信する通信セッションは、一つまたは複数のラウンドトリップを含んでいる。

通信セッションを始動すると、ユーザユニットは事前に格納された一連のスタートアップ命令を実行する。これらは一般に、それぞれの表面エリアに関連する情報管理ルールを格納する検索サーバに送信されるメッセージとなる。検索サーバは、さらに、ユーザユニットの通信動作の初期制御を実行する。有利には、記ユーザユニットは検索サーバからの命令（このような動作を始動するために事前に定義された命令）に応じて、新しい命令にそのスタートアップの手順を結合できる。さらに、ユーザユニットが送信動作を定義する特定の表面領域の情報を検出すると、この領域に関連している事前に格納された命令が実行される。

当業者には、本発明のユーザユニットが、表面から情報を読み込み、その情報の少なくともその一部を通信ネットワークを介して通信できる任意の種類の携帯端末にできることは認識されるであろう。

本発明の別の特徴および利点は、具体化した本発明の実施形態の、添付図を参照する以下の説明から明らかになるであろう。

次に、具体化した本発明の実施形態を、添付図を基準して詳細に説明する。

図１は、ユーザユニットおよびサービスのサポートを含むシステムの基本構成を示す。この基本構成およびその動作の各部は、参照により本明細書に引用したものとした、本出願人の国際特許出願ＰＣＴ／ＳＥ００／０２６４０、ＰＣＴ／ＳＥ００／０２６４１およびＰＣＴ／ＳＥ００／０２６５９に、以前に記載されている。

図１のシステムは、複数のユーザユニット１００、位置コード１２０を備える複数の製品１１０、複数のネットワーク接続１３０、およびサービスのサポートを実行する複数のサーバ１４０、１５０、１６０を含む。前記サーバは少なくとも一台のリモート検索サーバ１４０、一台のローカル検索サーバ１５０および複数のアプリケーションサーバ１６０を含む。説明を簡略化するために、図１は、ユーザユニットを具体化している一つのディジタルペン１００、位置コード１２０および起動アイコン１２５を備える一つの製品１１０、ネットワーク通信ユニットを具体化している一つの移動局１３０、リモートＰＬＳ（Ｐａｐｅｒ Ｌｏｏｋ−ｕｐ Ｓｅｒｖｉｃｅ）を実行する一台のリモート検索サーバ１４０、ローカルＰＬＳ（Ｐａｐｅｒ Ｌｏｏｋ−ｕｐ Ｓｅｒｖｉｃｅ）を実行する一台のローカル検索サーバ１５０、およびアプリケーションサービス（ＡＳ）を実行する一台のアプリケーションサーバ１６０を含むだけである。

前記製品１１０は、ディジタルペン１００によって、製品１１０の表面上の位置と解釈されるコーディングパターンを備える。コーディングパターンは、製品１１０の表面より大幅に大きい全表面上の位置をコード化するものである。検出された位置に基づき、ディジタルペンは表面の一つまたは複数の絶対座標を決定する。

前記全表面は、有利には、多数のセグメントに分割され、各セグメントは多数のシェルフに分割され、各シェルフは多数のブックに分割され、各ブックは多数のページに分割される。絶対座標は、ディジタルペンによって、特定のページに置かれるように決定される。ページはフォーマット１．２．３．４（セグメント．シェルフ．ブック．ページ）を使用して識別できる（このフォーマットは、セグメント１内の、シェルフ２上の、ブック３の、ページ４を示す）。この表記はページアドレスを定義する。

ユーザが製品１１０の表面全体にわたりディジタルペン１００を移動させとき、表面上の位置を検出し、対応する絶対座標を決定することにより、情報が記録される。これらの絶対座標または座標が属するページアドレスは、移動局１３０を介して、ローカルＰＬＳサーバ１５０、リモートＰＬＳサーバ１４０、またはアプリケーションサーバ１６０のどれかに送信される。ローカルＰＬＳサーバ１５０はＢｌｕｅｔｏｏｔｈ（登録商標）トランシーバが装備されている場合、ディジタルペン１００はローカルＰＬＳサーバ１５０と直接通信できる。リモートＰＬＳサーバは前記全表面の全座標に関する項目を、メモリまたは連結されたデータベース（図示せず）に格納する。これには、全表面が分割されているページに関する項目の格納を含む。同様に、ローカルＰＬＳサーバ１５０は、表面領域が一つまたは限定された数のユーザによって使用されている、一つまたは複数の限定された表面領域の座標およびページに関する項目を格納する。リモート／ローカルＰＬＳサーバは、特定の座標または特定のページアドレスに関連する管理ルールに従って、少なくとも座標の内容またはページアドレスの内容を含む受信された情報を処理するソフトウェアを備えている。

ユーザにとって、このシステムは、ユーザ自身が記録した情報を管理する方法を定義する必要がないため、簡単に使用できる。ユーザが情報の送信のための通信セッションを始動すると、この情報の管理は、ユーザが記録した座標および／またはディジタルペン１００によって情報が記録されたページアドレスに基づき制御される。

ディジタルペン１００のユーザが情報の送信の始動を希望する場合、起動アイコン１２５を「軽く打つ」。この場合、起動アイコンの少なくとも一つの位置の記録は、ユーザユニット１００により送信される領域の座標として認識され、この送信領域は特定の送信情報と関連している。デフォルトでは、この送信命令は、リモートＰＬＳサーバ１４０またはローカルＰＬＳサーバ１５０のどちらかである、事前に定義されたＰＬＳサーバのアドレスを含む。代替形態では、二つの送信領域が存在し、その内の一つはリモートＰＬＳサーバに関連し、他の一つはローカルＰＬＳサーバに関連する。

製品１１０の表面が小さい部分を構成している、全体表面の位置コーディングパターンはさまざまな方法で形成できるが、一般的特徴としては、特定の最小サイズのパターンのどこかの部分が記録される場合に、全体の位置コーディングパターン内の前記部分の位置は明確に決定される特徴を有する。さらに、全体の位置コーディングパターンは、前述のように、ページに分割される。

位置コーディングパターンは、有利には、２０００年５月２６日に出願された公開国際出願ＷＯ ００／７３９８３または２０００年１０月２日に出願された国際出願ＷＯ ０１／２６０３２、（両出願は、本出願人に譲渡されているに示されている）に示されるタイプである。これらのパターンにおいて、各位置は複数のマークまたはシンボルによってコード化され、各シンボルはいくつかの位置をコーディングするのに役立っている。位置コーディングパターンは少数のタイプのシンボルで構成されている。

ＷＯ ００／７３９８３に示される例では、大きなドットは“１”を表わし、小さなドットは“０”を表わす。

現在、最も好ましいパターンはＷＯ ０１／２６０３２に示されており、このパターンでは、ラスターポイントに対するドットまたはマークの四つの異なる変位が四つの異なる値にコード化される。このパターンは、０．３ｍｍの公称間隔の小さなドットで構成されている。６×６のこのようなドットを含むパターンのどの部分も、一対の絶対座標を定義する。このように、絶対座標の各対は位置コーディングパターンの１．８ｍｍ×１．８ｍｍサブセットによって定義される。パターンを読み取るのに使用されるユーザユニット内のセンサによって検出された６×６ドットの位置を決定することにより、仮想表面上の絶対位置は、解像度０．０３ｍｍで補間することにより計算できる。

この位置コーディングパターンは多数の絶対位置をコード化することが可能である。各位置は、それぞれが４つの値のうちの一つを有することができる６×６ドットによってコード化されるため、４^３６位置をコード化できる。これは、ドット間の前述の公称間隔では、４．６×１０^６ｋｍ^２の表面に相当する。

前述のように、全表面は、好ましくは、順に、セグメント、シェルフ、ブックおよびブックのページに分割される。さまざまな非重複セグメントは、さまざまな種類の情報管理に割り当てられる。ページ−ブック−シェルフ−セグメントの概念により、例えば、ブック全体の一部分またはシェルフ全体の一部分などが、特定の種類の情報管理のために、特定のパーティーに割り当てることができる。例えば、あるページは運送会社のための電子情報収集に、他のページは配送会社の電子絵はがきの管理のために、さらに別のページはインターネット上で事前に決められたサーバに常に転送される手書き情報を記録するために割り当てられ、さらに別のページは図による電子メール、ＳＭＳ、ファックスなどを送信するために割り当てることが可能である。

アプリケーションサービスは、システム内の所定の一台または複数のアプリケーションサーバを介して、情報管理を制御するアプリケーションである。前述のように、会社などに、その会社が全表面の割り当てられた部分の独占権を取得した後に、一つまたは複数のページ、または好ましくは、全表面のシェルフ全体を割り当てることができる。また、アプリケーションサービスは、例えばローカルＰＬＳを含むものと同じサーバなどのローカルサーバに存在でき、さまざまなローカルアプリケーションはさまざまなページに割り当てることができる。全表面のページ全てを管理するリモートＰＬＳサーバ１４０において、どの会社が全表面のどの部分の権利を有するかが記録されている。リモートＰＬＳサーバ１４０は、少なくとも一つの座標またはページアドレスを含む、ディジタルペン１００から受け取った情報に応答して、対応する表面領域を割り当てるパーティー（例えば会社）、および情報を扱う方法を決定する。同様に、ローカルＰＬＳサーバ１５０は、少なくとも一つの座標またはページアドレスを含む、受け取った情報に応答して、対応する表面領域を割り当てるローカルアプリケーション（例えば、カレンダー、電子メールまたはファックスアプリケーション）、および情報を扱う方法を決定する。

図２は、ユーザユニット２の一例を示している。このユーザユニットはペンに近い形状を有するケース１１を備えている。ケースの短辺側は、開口部１２を有し、位置コーディングパターンを備えるベースに接触するかまたは近距離に維持されるようになっている。

以下ではディジタルペンと称する、ユーザユニットは基本的に、光学部品、電子回路部分および電源を含む。

光学部品は、ディジタルカメラを形成し、また、画像化される表面を照射する少なくとも一つの赤外線発光ダイオード１３と、二次元画像を記録するための、例えばＣＣＤまたはＣＭＯＳセンサなどの光検出エリアセンサ１４とを備える。また、ユーザユニットはレンズ系を含むこともできる（図示せず）。赤外線光は位置コーディングパターン内のシンボル、好ましくはドットにより吸収され、これにより、シンボルはセンサ１４で認識される。有利には、センサは少なくとも一秒当たり百枚の画像を記録する。

ペンの電源は、ケース内の分離収納部に装着される電池１５から得られる。しかし、代替形態では、ペンを外部電力源に接続することができる。

電子回路部分は、センサ１４で読み取られた画像に基づいて位置決定するための信号プロセッサ１６、詳細には、マイクロプロセッサを有するプロセッサユニットを備える。このプロセッサユニットは、センサからの画像を記録して、その画像中のシンボルを識別し、さらに、位置コーディングパターンの画像化されたサブセットに基づいて表面上の位置の絶対座標をリアルタイムで決定するようにプログラムされている。

このように、位置決定は信号プロセッサ１６により実行される。このプロセッサは画像中のシンボルの位置を確認して、デコードすることができ、またこのようにして得られたコードから位置を決定できる、ソフトウェアを有する必要がある。前述の特許出願 ＷＯ ０１／２６０３２の説明から、当業者はこのようなソフトウェアを設計することが可能である。

また、信号プロセッサ１６は、格納された対の座標を分析し、これら座標を変換して、ユーザユニット２が位置コーディングパターンを備える表面全体にわたり移動した状態の詳細を構成する座標列を生成するようにプログラムされている。

信号プロセッサ１６は記録された情報すべてを同一サーバに転送する必要はない。信号プロセッサ１６のプログラムは、記録された座標を分析し、さらに、特定の座標領域内の座標により表される情報だけを転送するようにプログラムできる。また、信号プロセッサ１６は、サーバに送られる情報を暗号化するソフトウェアを有することもできる。

ディジタルペンは、このパターンからコード化できる全表面に対して位置コーディングパターンを定義することを含む。したがって、決定された位置から、信号プロセッサは、前記位置が全表面のどの領域に属するのかを導き出す。通常、このような領域は特定のページまたはページ上の特定の起動アイコンを表している。

ディジタルペンは、ディジタルペンを用いてユーザにより生成される位置コード化表面の情報を、ローカルまたはリモート検索サービス、あるいはアプリケーションサービスに送信するように構成される。システム内では、図１によるシステムでは、情報はネットワーク接続ユニットを具体化している移動局１３０に無線で送信され、この移動局は、順次、情報をローカルＰＬＳサーバ１５０、リモートＰＬＳサーバ１４０、またはアプリケーションサーバ１６０に送信する。代替形態では、ネットワーク接続ユニットは、コンピュータ、または、例えばインターネット、会社のローカルネットワークまたは電話回線網といった、ネットワークへのインターフェースを有するその他の適切なユニットである。代替形態では、ネットワーク接続ユニット１３０は、ペン１００と一体化した部分を構成する。すべての記録されたデータは、受信サーバ１４０、１５０、１６０への送信を待機するバッファメモリ２０に格納できる。結果として、ペン１００は独立方式で動作することができる。すなわち、ペン１００は、例えばネットワーク接続ユニット１３０と接続され、その後バッファメモリ２０から記録された情報を読み出した時点で、情報を送信する。

表面上でのペンストロークを分析することにより生成される位置の絶対座標およびページアドレスのデータを送信することに加えて、ディジタルペンはサーバにペンの属性データを送信することができる。前記属性は、プロセッサ１６により読み出しおよび書き込み可能なアドレス指定できる値または文字列として、メモリ２０に格納される。以下は、ペン属性データの例証となる、非網羅的リストであり、この他の属性は容易に推測できる。

ＰＥＮ＿ＩＤ・・・ペン固有のアイデンティティ
ＰＥＮ＿ＳＯＦＴＷＡＲＥ＿ＶＥＲＳＩＯＮ・・・ペンのソフトウェアのバージョン
ＴＲＡＮＳＡＣＴＩＯＮ ＤＡＴＡ・・・最後のトランザクションのアイデンティティおよびステータス
ＰＥＮ＿ＭＡＮＵＦＡＣＴＵＲＥＲ＿ＩＤ・・・ペンメーカーのアイデンティティ
ＬＯＣＡＬ＿ＵＲＬ・・・ローカルサーバのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）
ＰＬＳ＿ＵＲＬ・・・ＰＬＳ（Ｐａｐｅｒ Ｌｏｏｋ−ｕｐ Ｓｅｒｖｉｃｅ）サービスを実行するリモートサーバのＵＲＬ
ＬＡＳＴ＿ＰＲＯＰＥＲＴＹ＿ＵＰＤＡＴＥ・・・ペンにおける属性の最後に処理された最新データのアイデンティティ
ＰＥＮ＿ＯＷＮＥＲ＿ＮＡＭＥ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＡＤＤＲＥＳＳ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＩＮＶＯＩＣＥ＿ＡＤＤＲＥＳＳ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＥＭＡＩＬ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＨＯＭＥ＿ＰＨＯＮＥ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＣＥＬＬ＿ＰＨＯＮＥ ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＢＵＳＩＮＥＳＳ＿ＰＨＯＮＥ ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＰＡＧＥＲ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＨＯＭＥ＿ＦＡＸ・・・説明を要しない
ＰＥＮ＿ＯＷＮＥＲ＿ＢＵＳＩＮＥＳＳ＿ＦＡＸ・・・説明を要しない
ＴＸＴ＿ＳＹＳＴＥＭ＿ＥＲＲＯＲ・・・特定のメッセージに伴う文字列。この場合は、リクエスト送信時のエラーである。ユーザへのメッセージに伴う多数の文字列が存在する。

ユーザユニットおよびそれに関連するネットワーク接続ユニットは、通常、相互に近くに置かれている。図１におけるディジタルペン１００と移動局１３０間のような、ユーザユニットとネットワーク接続間の通信は、有線、または、例えばＢｌｕｅｔｏｏｔｈ（登録商標）技術に準拠する赤外線または電波、または短い距離間の情報の転送のためのその他の技術を介して実行できる。この目的のために、図２のディジタルペンは、外部ユニットとの無線通信のために、好ましくはＢｌｕｅｔｏｏｔｈ（登録商標）トランシーバであるトランシーバ１９を有する。

図３では、ディジタルペンのようなユーザユニット１００間の通信と、さまざまなサーバ上でのサポートサービスとに使用される例示的なプロトコルスタックが示されている。左側には、例示的なプロトコルスタックが、ディジタルペン（ＰＥＮ）とＰＬＳ（Ｐａｐｅｒ Ｌｏｏｋ−ｕｐ Ｓｅｒｖｉｃｅ）間の、またはペンとサービスを提供するアプリケーションサービス（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｈａｎｄｌｅｒ）間の、インターネットを介する通信に対して示されている。右側には、例示的プロトコルスタックが、ディジタルペンとローカルサーバ間の通信に対して示されている。ローカルサーバは、例えば、ローカル・アプリケーション・ルータ・サービスＬＡＲＳ（Ｌｏｃａｌ Ａｐｐｌｉｃａｔｉｏｎ Ｒｏｕｔｅｒ Ｓｅｒｖｉｃｅ）（ローカルＰＬＳとして作動する）を実行するローカルのパソコンである。さらに、ローカルサーバはローカル・アプリケーション・サービスを実行する場合がある。

ディジタルペンとあらゆるローカルまたはリモートサーバ間の通信は、ペンプロトコルＰＰ（Ｐｅｎ Ｐｒｏｔｏｃｏｌ）を定義する所定の命令セットに基づいている。このＰＰは、セキュリティ・ペン・プロトコルＳＰＰ（Ｓｅｃｕｒｉｔｙ Ｐｅｎ Ｐｒｏｔｏｃｏｌ）に実装されており、このＳＰＰは公知のＨＴＴＰプロトコルにも実装されている。インターネットでは、ＨＴＴＰ層はＴＣＰ／ＩＰ、ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）およびＢｌｕｅｔｏｏｔｈ（登録商標）のＲＦＣＯＭＭプロファイル上に実装されており、ローカルの場合にはＢｌｕｅｔｏｏｔｈ（登録商標）のＲＦＣＯＭＭプロファイル上に直接実装されている。したがって、ペンプロトコルＰＰは、本発明による通信方式を実装しているプロトコルである。セキュリティ・ペン・プロトコルＳＰＰは、本発明の出願人の独自のプロトコルであり、ペンＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｅｒｓ Ｉｎｔｅｒｆａｃｅ）は、ディジタルペンをサポートするサービスを設計する場合、アクタが使用するＰＰ上に抽象層を追加する。ＳＰＰまたはペンＡＰＩのどちらも本発明の範囲内ではなく、これ以上の説明はしない。スタックのその他の部分は、当業者には公知の通信プロトコル層である。

命令は、ペンにより以前に送信されたＨＴＴＰリクエストに応じて、サーバから送信されたＨＴＴＰ応答で、ディジタルペンにより受信される。

ＨＴＴＰ応答での受信メッセージは、ペンプロトコルのどのバージョンに前記応答の後の部分が適合するのかを表すプロトコルバージョンデータ部分、前記応答に関するメタデータを保持する応答ヘッダー部分、およびパラメータを備える命令の数を含む命令データ部分の、三つの部分で構成される。命令データ部分は、事前に定義されたアイデンティティにより命令を識別する。各命令アイデンティティは、それぞれのパラメータアイデンティティにより識別される、一つまたは複数のパラメータを伴う。各パラメータアイデンティティはパラメータの値を伴い、このパラメータの値は、ブール値、整数、文字列、バイトストリーム、または前述のいずれのタイプの値の配列であってもよい。

ディジタルペンから送信されるすべてのユーザユニットメッセージは、ＨＴＴＰリクエストで送信される。ユーザユニットメッセージは特定のサーバに送信され、ペンプロトコルのどのバージョンに応答の後の部分が適合するのかを表すプロトコルバージョンデータ部分、応答に関するメタデータを保持する応答ヘッダー部分、記録されたペンストロークデータを備えるページデータ部分、および一つまたは複数のペンの属性を備える属性データ部分の、四つの部分から構成される。データ部分は、事前に識別されたアイデンティティにより属性を識別する。各属性アイデンティティは属性値を伴い、この属性値は応答でのパラメータの値に対して、上記のいずれのタイプであってもよい。リクエストヘッダー部分はページアドレスおよびｐｉｄｇｅｔ（ｐａｐｅｒ ｗｉｄｇｅｔ）属性を含む。ページアドレスは、送信領域またはリクエストを起動したその他の起動アイコンが置かれているページのページアイデンティティである。ページアドレスの固定ビット位置は、結果として、セグメント、シェルフ、ブックおよびページを表す。前術のように、ページアドレスは「セグメント．シェルフ．ブック．ページ」を表すこともできる。ｐｉｄｇｅｔアイデンティティは、対象になっているページ上の送信領域（または起動アイコン）のアイデンティティである。二つ以上の起動アイコンが同一ページ上に置かれているので、このようなアイデンティティが必要となる。同一送信セッション中、すなわち同一トランザクション中の、特定のページの特定の送信領域により始動されたディジタルペンからのすべてのリクエストは、ページのページアドレスおよび送信領域のｐｉｄｇｅｔを含む。

ペンプロトコルに含まれている各命令の定義は、ディジタルペン１００のメモリ２０に格納されている。ディジタルペンが特定の命令に関連する動作を実行するとき、プロセッサ１６はメモリ２０内の対応する定義（プロセッサ、したがってディジタルペン１００のオペレーションを制御する定義）をアドレス指定する。全体としてのディジタルペンの動作、および特にペンプロトコル命令に従う動作は、メモリ２０により格納されているコンピュータ実行可能コンポーネントにより制御されている。したがって、メモリ２０は、本発明によるディジタルペン１００を動作させるためのコンポーネントを格納するコンピュータ読取り可能媒体を実現する。しかし、このようなコンピュータ読取り可能媒体は、ディジタルペンからアクセスされる目的のため、または後の段階でペン１００のメモリ２０内において転送およびダウンロードされる目的のため、ディジタルペンの外部に置くこともできる。

以下は、ペンプロトコルＰＰに含まれる命令の非網羅的リストである。このリストはリモートＰＬＳサーバの排他的命令および共通命令に分割される。後者の命令は、あらゆるサーバ、リモートまたはローカルＰＬＳサーバ並びにアプリケーションサーバは、これらの命令によりディジタルペンの動作を制御できる命令を意味する。

リモートＰＬＳサーバの排他的命令：
−ｇｒａｎｔＰａｇｅＤａｔａＡｃｃｅｓｓ（ｐａｇｅＡｄｄｒｅｓｓ）
パラメータｐａｇｅＡｄｄｒｅｓｓは、同一セッション内のａｄｄＰａｇｅＤａｔａ命令においてアクセスできるページを定義する。

−ｇｒａｎｔＰｒｏｐｅｒｔｙＡｃｃｅｓｓ（ｐｒｏｐｅｒｔｙ ｉｄｅｎｔｉｔｉｅｓ）
一つまたは複数の属性アイデンティティパラメータは、同一セッション内のａｄｄＰｒｏｐｅｒｔｙＤａｔａ命令においてアクセスできるペンの属性を定義する。

−ｉｎｔｅｒｎｅｔＩｎｉｔｉａｌＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ（ｕｒｌ）
提供されたｕｒｌへのリクエストを通知する。この命令は、基盤を成すＳＰＰプロトコルが使用されることを意味する。また、この命令は、使用されるＳＰＰプロトコルの最小バージョンを定義するパラメータおよび最大バージョンを定義するパラメータを含むこと場合がある。さらに、前記命令は、使用されるＰｅｎ Ｐｒｏｔｏｃｏｌの最小および最大バージョンを定義する二つのパラメータを含む場合がある。

−ｉｎｔｅｒｎｅｔＬｏｏｋｕｐＲｅｑｕｅｓｔ
ＰＬＳ＿ＵＲＬ属性により定義されたｕｒｌへのリクエストを通知する。この命令は、基盤を成すＳＰＰプロトコルが使用されることを意味する。

− ｒｅｇＶｅｒｔｉｃａｌＡｐｐ （ｐａｇｅＡｄｄｒｅｓｓ， ｉｎｓｔｒｕｃｔｉｏｎｓｃｒｉｐｔ）
パラメータｐａｇｅＡｄｄｒｅｓにより定義される一つのページまたは複数のページを、ｉｎｓｔｒｕｃｔｉｏｎｓｃｒｉｐｔパラメータにより定義される命令のセットに関連付ける。その後、これらの命令は、送信領域のような、特定の表面エリアの位置を検出すると実行される。

−ｓｅｔＰｒｏｐｅｒｔｙ（ｐｒｏｐｅｒｔｙＩＤ， ｖａｌｕｅ）
ある属性に特定の値を割り当てる。この記値は、ブール値、整数、文字列、バイトストリーム、または前述のいずれの値の配列であってもよい。

−ｓｔａｒｔＴｒａｎｓａｃｔｉｏｎ（ｔｒａｎｓＩＤ）
この命令は、アプリケーショントランザクションを開始する。このパラメータは、トランザクションを識別し、好ましくは、ＰＬＳサーバによってカウントされる、１９７０年以来のミリ秒単位の現在のグリニッジ標準時（ＧＭＴ）に等しい。

−ｌｏｃａｌＬｏｏｋｕｐＲｅｑｕｅｓｔ
ＬＯＣＡＬ＿ＵＲＬ属性により定義されたｕｒｌへのリクエストを通知する。

共通命令：
−ａｂｏｒｔＴｒａｎｓａｃｔｉｏｎＶｅｒｂｏｓｅ
アプリケーショントランザクションを中止する。

−ａｄｄＰａｇｅＤａｔａ（ｐａｇｅＡｄｄｒｅｓｓ）
パラメータｐａｇｅＡｄｄｒｅｓｓは、そのページから、記録されたデータがページリクエストのユーザユニットメッセージに追加されるページを指定する。この命令は、命令を送信するサーバが該当するページデータを読み込む権利を有することを要求する。これは、サーバがリモートＰＬＳサーバであるか、または、ｇｒａｎｔＰａｇｅＤａｔａＡｃｃｅｓｓ命令がセッション内で以前にリモートＰＬＳサーバに呼び出されているか、あるいは、セッションがローカルセッションであり、かつローカルＰＬＳサーバにより読み出し可能であることを意味する。

−ａｄｄＰｒｏｐｅｒｔｙＤａｔａ（ｐｒｏｐｅｒｔｙ ｉｄｅｎｔｉｔｉｅｓ）
一つまたは複数のペンの属性を識別する一つまたは複数のパラメータである。これらの属性の値は、リクエストのユーザユニットメッセージに含まれる（加えられる）。この命令は、この命令を送信するサーバが、該当する属性を読み出す権利を有することを要求する。これは、サーバがリモートＰＬＳであるか、またはｇｒａｎｔＰｒｏｐｅｒｔｙＡｃｃｅｓｓ命令が同一セッション内で以前にリモートＰＬＳサーバにより呼び出されていることを意味する。

−ｃｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎＶｅｒｂｏｓｅ
トランザクションを処理する、すなわち、サーバによりサービスが正常に実行されることをペンに伝える。

−ｉｎｔｅｒｎｅｔＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ（ｕｒｌ）
提供されたｕｒｌへのリクエストを通知する。この命令は基盤を成すＳＰＰプロトコルが使用されることを意味する。

−ｌｏｃａｌＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ（ｕｒｌ）
提供されたｕｒｌへのリクエストを通知する。

図４を参照すると、例示的な実施形態による、ユーザユニットの動作のフローチャートが示されている。以下に述べられる命令およびパラメータは単なる例であることに注意されたい。これらの多くは、ここに述べられ、さらに図４の実施形態内に含まれる、その他の適正な命令および／またはパラメータに変更または置き換えられる。

ステップ４００では、ディジタルペン１００は、パターンを有する表面１２０上を、ディジタルペンを用いてユーザが操作するペンストロークがされている間に、エリアセンサ１４の視野内にある位置コード化パターンの各部分を記録する。プロセッサ１６は、位置コーディングパターンを用いて表面上で検出された位置を絶対座標に変換し、ディジタルペンがペンストローク中に表面上を移動する状態を記述する座標数列を生成する。この座標数列は、ペンストロークデータとも呼ばれる。これらの座標および座標がこれらの位置コード化パターンの全表面を定義する方法の認識に基づき、プロセッサは、座標が属する特定の表面の該当するページアドレスを決定する。すべての座標が、送信領域のような、起動アイコン１２５に属する場合、該当する送信領域はアイデンティティ、すなわちｐｉｄｇｅｔアイデンティティは、どの座標がどの起動ボックスを定義するかの認識に基づき決定される。

ステップ４１０では、ディジタルペン１００のプロセッサ１６は、どのサーバにどのデータを送信するのかを定義する、事前に格納された多数のパラメータを用いて、事前に格納されたスタートアップ命令のセットを実行する。例えば、プロセッサは、特定の記録された座標がインターネット送信領域を定義する起動アイコン１２５に属することを検出すると、この送信領域に関連している事前に格納されたスタートアップ命令が実行される。例えば、スタートアップ命令は以下の通りである：
−ａｄｄＰｒｏｐｅｒｔｙＤａｔａ（ＰＥＮ＿ＩＤ， ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＡ，
ＰＥＮ＿ＭＡＮＵＦＡＣＴＵＲＥＲ＿ＩＤ， ＬＡＳＴ＿ＰＲＯＰＥＲＴＹ＿ＵＰＤＡＴＥ）；
−ｉｎｔｅｒｎｅｔＬｏｏｋｕｐＲｅｑｕｅｓｔ（ＰＬＳ＿ＵＲｌ）．
第一の命令は、どの属性データが送信されることになっているかを定義する。第二の命令は、ディジタルペンに、指定された属性データを含むユーザユニットメッセージを持つＨＴＴＰリクエストを、リモートＰＬＳサーバ１４０に送信するように命令する。受信サーバは属性ＰＬＳ＿ＵＲＬに格納されている、事前に定義されたＵＲＬアドレスにより識別される。

代替形態では、検出された座標がローカル送信領域を定義する起動アイコン１２５に属する場合、ユーザユニットメッセージはローカルＰＬＳサーバ１５０に送信されることになり、事前に格納されたスタートアップ命令は以下のようになる：
−ａｄｄＰｒｏｐｅｒｔｙＤａｔａ（ＰＥＮ＿ＩＤ）；
−ｌｏｃａｌＬｏｏｋｕｐＲｅｑｕｅｓｔ（ＬＯＣＡＬ＿ＵＲＬ）．

好ましくは、前述のように、どの属性データをリモートＰＬＳサーバに送信するのは定義するスタートアップ命令は、属性ＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＡを含む。この属性は最新のトランザクションのアイデンティティおよび最新のトランザクションのステータスを含む。このステータスは、最新のトランザクションを含むアプリケーションサーバの動作の結果（例えば、成功、中止、保留など）を示す。有利には、受信リモートＰＬＳサーバの請求の基本を、トランザクションが成功した場合、例えばペン利用者に請求することにより、受信したトランザクションデータを基に請求できるが、ステータスが、何らかの理由でトランザクションが中止されたことを示す場合は、請求できない、ことを基本とすることができる。送信されるメッセージ内の最新のトランザクションの結果を含むこの動作は、図４のステップ４２０として示されている。スタートアップ命令により送信されるのが望ましいその他の属性は、ＬＡＳＴ＿ＰＲＯＰＥＲＴＹ＿ＵＰＤＡＴＥである。この属性は受信リモートＰＬＳサーバ１４０により使用され、この属性が、更新されたペンの属性の値として、ペンにより格納される必要のあるすべての更新された情報を保持するかどうかについて決定される。保持している場合、サーバ１４０は、後の段階において、以下に説明するように、命令ｓｅｔＰｒｏｐｅｒｔｙを使用する一つまたは複数の属性に対して新しい値の格納を開始する。

ユーザユニットメッセージを有するＨＴＴＰリクエストのサーバへの送信は、ステップ４３０に示されている。前述のように、いずれのユーザユニットメッセージもその上でペンストロークが検出された表面領域のページアドレスと、起動アイコンがペンストロークで「軽く打たれた」場合は、この起動アイコンのアイデンティティ（ｐｉｄｇｅｔアイデンティティ）とを含む。ＨＴＴＰリクエストのトランザクションを実行することにより、ディジタルペンは送信セッションを始動する。したがって、送信セッションをペンにより起動し、ｉｎｔｅｒｎｅｔＬｏｏｋｕｐＲｅｑｕｅｓｔ命令またはｌｏｃａｌＬｏｏｋｕｐＲｅｑｕｅｓｔ命令をそれぞれ使用して、リモートまたはローカルＰＬＳサーバのどちらかにＨＴＴＰ要求を送ることができる。ｉｎｔｅｒｎｅｔＬｏｏｋｕｐＲｅｑｕｅｓｔ命令によりＨＴＴＰリクエストを送信する場合、これはペンプロトコルＰＰが基盤を成すセキュリティ・ペン・プロトコルＳＰＰを使用することを意味する。ＳＰＰは、ディジタルペンとリモートＰＬＳサーバ間の通信の暗号化を提供する。この暗号化により、リモートＰＬＳサーバはディジタルペンに事前に定義され限定された命令のセットつの命令（すなわち、リモートＰＬＳサーバの排他的命令）を送信することができ、またディジタルペンは、この限定されたあらゆる命令セットが、その他のサーバではなく、特定のリモートＰＬＳサーバから受信されたことを確認することができる。この暗号化は、暗号研究の当業者には公知の技術を採用している。いずれにせよ、ＳＰＰプロトコルの実装は本発明の範囲外である。

ディジタルペン１００で受け取られるいずれの命令も、ステップ４４０において、ペンがＨＴＴＰリクエストを要求したサーバからのＨＴＴＰ応答で受信される。さまざまな命令はＨＴＴＰ応答で受信できる。この応答は、通常、前述の限定された命令セットの命令を含む。このような命令の典型例は、ペンに格納された属性を更新する命令、スタートアップ命令のセットを送信領域に関連付ける命令、または一定のアプリケーショントランザクションを始動する多数の命令を含む。

命令ｓｅｔＰｒｏｐｅｒｔｙ（ｐｒｏｐｅｒｔｙＩＤ， ｖａｌｕｅ）を用いて、リモートＰＬＳサーバは、ペンにより格納された一つまたは複数の属性を更新する。例えば、そのリクエスト内でペンが、値２を有する属性ＬＡＳＴ＿ＰＲＯＰＥＲＴＹ＿ＵＰＤＡＴＥを送信した場合、受信サーバはこの値を、サーバにより格納されている該当する属性の更新された値と照合する。前記値間に違いがある場合、サーバはどの属性が更新される必要があるかを識別できる。例えば、ペンがＨＴＴＰ応答内で、命令ｓｅｔＰｒｏｐｅｒｔｙ（ＰＥＮ＿ＯＷＮＥＲ＿ＥＭＡＩＬ， ｍｒ＿Ｘ＠ｃｏｍｐａｎｙ＿Ｙ．ＣＯＭ）を受信すると、これは、ペンはその所有者の新しい電子メールアドレスを格納することを意味する。この動作は、ステップ４５０で実行される。それ以上受信する命令がなくなった場合、ペンは、ステップ４７０のセッションを終了後、実行がステップ４００に戻り、表面から新しく記録された位置を処理する。

命令ＲｅｇＶｅｒｔｉｃａｌＡｐｐ（ｐａｇｅＡｄｄｒｅｓｓ， ｉｎｓｔｒｕｃｔｉｏｎｓｃｒｉｐｔ）を用いて、新しいスタートアップ命令セットが送信領域に関連付けられる。例えば、前記命令は特定のセグメント／シェルフ／ブック上の全ページに関連付けることができる。これはページアドレスを用いて表わされ、例えば、２．３．４．＊は、ブック４、シェルフ３、セグメント２の全ページを意味する。命令スクリプトは、座標パラメータを含み、また、ペンがページアドレス２．３．４．＊により定義される全ページ上でこれらの座標により定義された送信領域の位置を記録したことを検出すると、どの命令を実行するかを定義する。新しい命令は、同様の方法により、すべてのページ上のいずれの起動ボックスにも関連付けできる。ペンは、ステップ４５０において新しい命令を格納する。それ以上受信する命令がなくなった場合、ペンはステップ４７０におけるセッションを終了後、実行がステップ４００に戻り、表面から新しく記録された位置を処理する。

ステップ４４０におけるリモートＰＬＳサーバから受信される命令の別の典型例は、アプリケーショントランザクションを始動し、さらに、一般にはディジタルペンからペンストロークデータの別のトランザクションを含む命令である。この命令は、ペンからのＨＴＴＰリクエストにより受信されるページアドレスと関連する格納された管理ルールに従って、リモートＰＬＳサーバから送信される。アプリケーショントランザクションが始動されたときに受信される命令の例は以下の通りである（すべてのパラメータを含む）：
ｓｔａｒｔＴｒａｎｓａｃｔｉｏｎ；
ａｄｄＰｒｏｐｅｒｔｙＤａｔａ
ａｄｄＰａｇｅＤａｔａ；および
ｉｎｔｅｒｎｅｔＩｎｉｔｉａｌＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ．
再度、これらの命令の定義に従う実行はステップ４５０において実行される。

ｓｔａｒｔＴｒａｎｓａｃｔｉｏｎ（ｔｒａｎｓＩＤ）命令は新しいトランザクションを開始する。パラメータｔｒａｎｓＩＤは、開始されたトランザクションを識別し、このトランザクションのＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＡ属性の一部としてペンにより格納される。有利には、トランザクションのアイデンティティは、例えば１９７０年以来ミリ秒単位での現在のグリニッジ標準時（ＧＭＴ）などの、時刻表示である。有利には、ペンはトランザクションのアイデンティティを使用して、命令を送信したリモートＰＬＳサーバのクロックとその内部クロックを同調させることができる。

ａｄｄＰｒｏｐｅｒｔｙＤａｔａ（ＰＥＮ＿ＩＤ， ＰＥＮ＿ＯＷＮＥＲ＿ＥＭＡＩＬ）命令は、識別されたペンの属性を、ペンを用いて、送信される次のユーザユニットメッセージに含むようにすることを意味する。この例の命令はリモートＰＬＳサーバにより呼び出されるため、ｇｒａｎｔＰｒｏｐｅｒｔｙＡｃｃｅｓｓ命令が前にある必要はない。

ａｄｄＰａｇｅＤａｔａ（ｐａｇｅＡｄｄｒｅｓｓ）命令は、識別されたページのペンストロークデータを、ペンを用いて、送信される次のユーザユニットメッセージに含むようにすることを意味する。この場合、命令はリモートＰＬＳサーバにより呼び出され、したがって、この命令の前にｇｒａｎｔＰｒｏｐｅｒｔｙＡｃｃｅｓｓ命令がある必要はない。

ｉｎｔｅｒｎｅｔＩｎｉｔｉａｌＡｐｐｌｉｃａｔｉｏｎＲｅｅｑｕｅｓｔ（ｕｒｌ）命令は、ペンがＨＴＴＰリクエスト内のユーザユニットメッセージを特定のｕｒｌにより識別されるアプリケーションサーバに送信すること、およびアプリケーションサーバが現在のトランザクションに含まれていることを意味する。

ペンからのＨＴＴＰリクエストのトランザクションまでの前述の命令の実行はステップ４５０において実行され、その後、ペン実行はステップ４３０に戻り、ステップ４３０において、ｉｎｔｅｒｎｅｔｌｎｉｔｉａｌＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ命令に対応して、ユーザユニットメッセージが識別されたサーバに送信される。

例えば、ディジタルペンのユーザが、位置コーディングパターンを有する表面上に表示された広告にいくつかのペンストロークを実行後、広告の送信領域を「軽く打つ」ことにより送信セッションを始動する場合、前述のスタートアップ命令は、リモートＰＬＳサーバに対してＨＴＴＰリクエストを発行する。このＨＴＴＰリクエストには、広告が印刷された表面のページアドレスと、「軽く打たれた」送信領域のアイデンティとを含む。ページに関連する管理ルールに従って、リモートＰＬＳサーバからのＨＴＴＰ応答は、ペンを制御して、ページと関連するアクタにＨＴＴＰリクエスト（通常、アプリケーションサーバ上で広告主により実行されるサービス）を送信するための命令を含む。この例では、前述の受信された命令の結果として、ペンはそのペンのアイデンティティ、その所有者の電子メールアドレス、および広告主に広告上になされたペンストロークデータを送信する。これにより、例えば、製品の注文または追加情報の注文などを発生することができる。

ステップ４３０において、ＨＴＴＰリクエストがペンからアプリケーションサーバに送信される結果としての、アプリケーションサーバのサービスにより実行される動作は、正常に行われるか、または何らかの理由で障害が起こる可能性がある。動作が正常に行われた場合、ｃｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎＶｅｒｂｏｓｅ命令を用いて、ステップ４４０において、この結果がペンに送信される。次にステップ４６０において、ペンは、このトランザクションに関連するＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＡ属性内の正常なトランザクションの表示を格納する。その後ステップ４７０において、ペンはセッションを終了し、実行はステップ４００に戻る。次回に、何らかの理由により、ユーザが送信セッションを始動するとき、この最後のトランザクションのＴＲＡＮＳＡＣＴＩＯＮ＿ＤＡＴＡ属性は、リモートＰＬＳサーバへのＨＴＴＰリクエストに含まれる。

本発明の具体化した実施形態を示すために、図５を参照する。図５はディジタルペン５００、リモートＰＬＳサーバ５１０、アプリケーションサーバ５２０、およびその他のアプリケーションサーバ５３０を示している。アクタ、すなわち広告主「Ｘ」は、ＵＲＬ「ａｄｖｅｒｔｉｓｅｒ＿ｘ．ｃｏｍ」を有するアプリケーションサーバ５２０上でアプリケーションサービスを実行し、その他のアプリケーションサービスは、ＵＲＬ「ｌｏｃａｌ＿ｄｅａｌｅｒ＿ｙ． ｃｏｍ」を用いて、サーバ５３０上でローカルディーラー「Ｙ」により実行される。

図４と関連して述べた例に戻ると、ユーザは広告上にいくつかのペンストロークを発生し、同一広告上で送信領域を「軽く打つ」。図５のステップ１は、リモートＰＬＳサーバに送られるＨＴＴＰリクエストを示しており、このリクエストには、広告が表示されている表面上のページアドレスおよび「軽く打たれた」送信領域のアイデンティティを含む。ステップ２は、リモートＰＬＳサーバ５１０からペン５００に返送される、該当するページに関連する管理ルールに従う命令を有するＨＴＴＰ応答を示している。この場合の命令は以下のようである：
−ｓｔａｒｔＴｒａｎｓａｃｔｉｏｎ（ｔｒａｎｓＩＤ）；
−ｇｒａｎｔＰａｇｅＤａｔａＡｃｃｅｓｓ（１．２．３．４）；
−ｇｒａｎｔＰｒｏｐｅｒｔｙＡｃｃｅｓｓ（ＰＥＮ＿ＩＤ， ＰＥＮ＿ＯＷＮＥＲ＿ＮＡＭＥ，
ＰＥＮ＿ＯＷＮＥＲ＿ＩＮＶＯＩＣＥ＿ＡＤＤＲＥＳＳ）；
−ａｄｄＰｒｏｐｅｒｔｙＤａｔａ（ＰＥＮ＿ＩＤ， ＰＥＮ＿ＯＷＮＥＲ＿ＡＤＤＲＥＳＳ）；および
−ｉｎｔｅｒｎｅｔＩｎｉｔｉａｌＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ（ａｄｖｅｒｔｉｓｅｒ＿ｘ．ｃｏｍ）．
図４の例との一つの相違は、ｇｒａｎｔＰａｇｅＤａｔａＡｃｃｅｓｓがａｄｄＰａｇｅＤａｔａ命令の代わりに送信されることである。ｇｒａｎｔＰａｇｅＤａｔａＡｃｃｅｓｓ命令は、ページ１．２．３．４（広告が表示されている表面のページ）が、同一セッションにおいてその後に（したがってアプリケーショントランザクション中に）、いずれのａｄｄＰａｇｅＤａｔａ命令によってもアクセスが可能であることを、ページアドレスパラメータを用いて定義する。同じ方法で、ｇｒａｎｔＰｒｏｐｅｒｔｙＡｃｃｅｓｓ命令は、どんな属性がアプリケーショントランザクション中にサーバによりアクセス可能なのかを定義する。この命令により、ステップ３では、ＵＲＬａｄｖｅｒｔｉｓｅｒ＿ｘ．ｃｏｍを使用してペン５００からアプリケーションサーバ５２０に送信される、ユーザユニットメッセージ内に属性ＰＥＮ＿ＩＤおよびＰＥＮ＿ＯＷＮＥＲ＿ＡＤＤＲＥＳＳを有するＨＴＴＰリクエストが発生する。

この受信サービスは広告主により実行される主要サービスであり、広告主がローカルディーラー対してすべてのユーザの管理を要求すると仮定する。例えば、ペンの所有者のアドレスを検査することにより、サービスは、広告された製品に関連する、ペンの所有者に最も近いローカルディーラーを決定する。ステップ４において、ａｄｖｅｒｔｉｓｅｒ＿ｘ． ｃｏｍのサービスは、ペン５００に、以下の命令を有するＨＴＴＰ応答を送信する。

−ａｄｄＰａｇｅＤａｔａ（１．２．３．４）；
−ａｄｄＰｒｏｐｅｒｔｙＤａｔａ（ＰＥＮ＿ＩＤ， ＰＥＮ＿ＯＷＮＥＲ＿ＮＡＭＥ，
ＰＥＮ＿ＯＷＮＥＲ＿ＩＮＶＯＩＣＥ＿ＡＤＤＲＥＳＳ）； および
−ｉｎｔｅｒｎｅｔＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ（ｌｏｃａｌ＿ｄｅａｌｅｒ＿ｙ．ｃｏｍ）．
これらの命令により、ステップ５において、ペン５００からｌｏｃａｌ＿ｄｅａｌｅｒ＿ｙ．ｃｏｍにより実行されるサービスに送信される、ＨＴＴＰリクエストが発生する。このリクエストはユーザユニットメッセージを含み、このメッセージには、ページ１．２．３．４からのペンストロークデータ、および属性データＰＥＮ＿ＩＤ， ＰＥＮ＿ＯＷＮＥＲ＿ＮＡＭＥ、ＰＥＮ＿ＯＷＮＥＲ＿ＩＮＶＯＩＣＥ＿ＡＤＤＲＥＳＳを含む。製品の注文に応える場合、ステップ６におけるローカルディーラーのサービスは、アプリケーションサーバ５３０からペン５００への、処理されるパラメータのセットを含むｃｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎＶｅｒｂｏｓｅ命令を有するＨＴＴＰ応答により、リクエストに応答する。前述のように、サービスが正常に実行されたことを示すこの情報は、ステップ７に示されるように、ペンにより始動された次の送信セッション中に、ペン５００からリモートＰＬＳサーバ５１０に送信される。この情報に基づき、リモートＰＬＳサーバ５１０のオペレータがユーザの申し込みに対して請求を発行することにより、ユーザがオペレータにより提供されるサービスを利用できるようになる。この例は、一つまたは同一セッションが二つ以上のラウンドトリップで構成でき、この場合、一つの単一ラウンドトリップが、ペンによりサーバに送信されたＨＴＴＰリクエスト、および同一サーバからペンにより受信された次のＨＴＴＰ応答から構成されていることを示す。

既存のペンの属性、既存の命令、および関連するパラメータに関して、および命令の正確な数列に関して、多くの代替形態および変更形態などが可能であることは理解されるところである。

したがって、本発明を特定の具体化した実施形態により説明してきたが、これらの実施形態は、添付クレームにより定義されている本発明の範囲を限定するものではない。

ユーザユニットおよびサービスのサポートを実行するサーバを含むシステム内の要素およびそれら要素の相互関係を示す。 ユーザユニットを具体化しているディジタルペンの内部の略図である。 ユーザユニットがリモートネットワークサーバまたはローカルサーバと通信するときに使用されるプロトコルスタックである。 具体化した実施形態によるユーザユニットの動作のフローチャートである。 本発明の別の実施形態による、通信セッション中のサービスをサポートしている、ユーザユニットの動作およびその通信を示す図である。

Claims (24)

1. ユーザユニットと、検索サーバ及びアプリケーションサーバを含むサーバ群とを備えるシステムにおいて、前記ユーザユニットが有する情報データの前記サーバ群のうちの少なくとも一つのサーバへの送信を制御する方法であって、
   前記ユーザユニットは、位置コードを備える表面から読み込んだ情報の少なくとも一部を、前記サーバ群のうちの少なくとも一つのサーバに送信する手段を有しており、
   前記表面は、前記ユーザユニットと一緒に使用される製品の表面であって、前記ユーザユニットへ情報を入力するために用いられるものであり、
   前記方法は、
   前記ユーザユニットが、前記検索サーバから、前記ユーザユニットが有する情報データの送信可否を定めるための命令を受信するステップと、
   前記ユーザユニットが、前記アプリケーションサーバから、特定の情報データを求める命令を受信するステップと、
   前記ユーザユニットが、前記アプリケーションサーバからの命令で求められた特定の情報データの送信可否を、前記検索サーバからの命令に基づいて決定し、前記ユーザユニットが有する情報データのうち送信可と決定された前記特定の情報データを送信するステップと、
   を含むことを特徴とする方法。
2. 前記検索サーバは、前記表面から読み込んだ情報の取り扱いを定めるためのルールを有するものであり、
   前記ユーザユニットが、前記表面から読み込んだ情報の少なくとも一部を前記検索サーバに送信した後に、前記検索サーバからの命令を受信するステップが実行され、
   前記ユーザユニットが、前記検索サーバにより前記ルールに基づいて指定される前記アプリケーションサーバへメッセージを送信した後に、前記アプリケーションサーバからの命令を受信するステップが実行される、請求項１に記載の方法。
3. 前記ユーザユニットは、前記検索サーバからの命令を受信すると、前記命令に関連する動作を、前記ユーザユニットに格納されている命令セットにより提供される定義に従って実行する、請求項１または２に記載の方法。
4. 前記送信するステップは、前記アプリケーションサーバからの命令から、前記特定の情報データを含むメッセージを受信する受信アプリケーションサーバを識別するアドレスを抽出することを含む、請求項１〜３のいずれかに記載の方法。
5. 前記検索サーバからの命令が前記検索サーバにより排他的に使用される特定の命令セットに含まれることを、前記ユーザユニットが決定する、請求項１〜４のいずれかに記載の方法。
6. 前記ユーザユニットが有する情報データは、前記ユーザユニットの属性を示すデータを含み、
   前記検索サーバからの命令は、前記ユーザユニットの属性を定義するパラメータを含む、請求項１〜５のいずれかに記載の方法。
7. 前記ユーザユニットが有する情報データは、前記ユーザユニットの属性を示すデータを含み、
   前記特定の情報データは、前記ユーザユニットの属性の値を含む、請求項１〜６のいずれかに記載の方法。
8. 前記ユーザユニットが有する情報データは、前記表面から読み込んだ情報の少なくとも一部を含み、
   前記検索サーバからの命令は、前記位置コードによって定義される仮想表面の特定の部分を示すページアドレスを定義するパラメータを含む、請求項１〜７のいずれかに記載の方法。
9. 前記ユーザユニットが有する情報データは、前記表面から読み込んだ情報の少なくとも一部を含み、
   前記特定の情報データは、前記表面から前記ユーザユニットにより読み込まれた位置の座標を含む、請求項１〜８のいずれかに記載の方法。
10. 前記ユーザユニットが事前に格納されているスタートアップ命令の実行に関連して前記検索サーバへメッセージを送信するステップの後に、前記検索サーバからの命令を受信するステップが実行される、請求項１〜９のいずれかに記載の方法。
11. 前記ユーザユニットが、前記特定の情報データを含むメッセージを送信した先のアプリケーションサーバから、結果データを有する命令を受信するステップと、
    前記ユーザユニットが、前記送信先のアプリケーションサーバから受信した前記命令から前記結果データを抽出するステップと、
    前記ユーザユニットが、前記結果データを、前記送信先のアプリケーションサーバにより実行された動作の結果を示すものとして格納するステップと、
    前記ユーザユニットが、事前に格納されているスタートアップ命令の実行に関連する前記検索サーバに、前記結果を送信するステップと、
    をさらに含む、請求項１〜１０のいずれかに記載の方法。
12. 前記サーバ群のうちの少なくとも一つのサーバへのメッセージの送信と、その後の同一のサーバからの少なくとも一つの命令の受信とにより、ユーザユニットのラウンドトリップが定義され、
    前記ユーザユニットからデータを送信するために前記ユーザユニットにより開始されるセッションが、一つのラウンドトリップまたは複数のラウンドトリップのどちらかを含む、請求項１０または１１に記載の方法。
13. 前記事前に格納されているスタートアップ命令が、
    前記検索サーバを識別するアドレスパラメータと、
    前記事前に格納されているスタートアップ命令の実行に関連して前記検索サーバに送信されるメッセージにユーザユニットの何の属性を含めるべきかを定義するユーザユニット属性パラメータと、
    を含む、請求項１０〜１２のいずれかに記載の方法。
14. 前記事前に格納されているスタートアップ命令の実行の後に、前記ユーザユニットが、前記検索サーバから、識別子により特定のセッションの開始を識別する属性パラメータを有する別の命令を受信し、時刻表示形式で前記識別子を格納する、請求項１０〜１３のいずれかに記載の方法。
15. 前記ユーザユニットが、前記時刻表示形式の識別子を用いて、前記ユーザユニットの内部クロックを前記検索サーバのクロックと同期させる、請求項１４に記載の方法。
16. 前記ユーザユニット属性パラメータのセットが、最後に実行される属性更新パラメータを含み、
    前記事前に格納されているスタートアップ命令の実行の後に、前記ユーザユニットが、前記検索サーバから、属性の更新された値を有する別の命令を受信し、前記属性の更新された値を格納する、請求項１３に記載の方法。
17. 前記事前に格納されているスタートアップ命令の実行の後に、前記ユーザユニットが、前記検索サーバから別の命令を受信し、前記別の命令に基づき、前記事前に格納されたスタートアップ命令のセットが変更されるか、または新しいスタートアップ命令のセットが定義される、請求項１０〜１３のいずれかに記載の方法。
18. 前記表面から読み込んだ情報を送信するために前記ユーザユニットがセッションを開始するときに、前記事前に格納されたスタートアップ命令が前記ユーザユニットにより実行され、
    前記セッションは、前記ユーザユニットが前記表面の特定の送信領域からの情報の読み込みを検出したときに開始される、請求項１０〜１３のいずれかに記載の方法。
19. 前記送信領域は、前記情報の読み込みにより、前記ユーザユニットがリモート検索サーバと通信するように構成されており、
    前記リモート検索サーバは、前記表面から読み込んだ情報の取り扱いを定めるためのルールを有するものであり、
    前記ユーザユニットが前記検索サーバから受信する、情報データの送信可否を定めるための命令は、前記リモート検索サーバが有するルールに基づいて生成されたものである、請求項１８に記載の方法。
20. 前記送信領域は、前記情報の読み込みにより、前記ユーザユニットがローカル検索サーバと通信するように構成されており、
    前記ローカル検索サーバは、前記表面から読み込んだ情報の取り扱いを定めるためのルールを有するものであり、
    前記ユーザユニットが前記検索サーバから受信する、情報データの送信可否を定めるための命令は、前記ローカル検索サーバが有するルールに基づいて生成されたものである、請求項１８に記載の方法。
21. 前記ユーザユニットから送信されるメッセージが、そのユーザユニットの固有のアイデンティティを含む、請求項１〜２０のいずれかに記載の方法。
22. 前記表面から読み込んだ情報が、前記位置コードによって定義される仮想表面に含まれる少なくとも一つの位置を含む、請求項１〜２１の内のいずれかに記載の方法。
23. ユーザユニットと一緒に使用される製品の表面であって位置コードを備えて前記ユーザユニットへ情報を入力するために用いられる表面から読み込んだ情報の少なくとも一部を、検索サーバ及びアプリケーションサーバを含むサーバ群のうちの少なくとも一つのサーバに送信する手段と、
    前記検索サーバから、前記ユーザユニットが有する情報データの送信可否を定めるための命令を受信する手段と、
    前記アプリケーションサーバから、特定の情報データを求める命令を受信する手段と、
    前記アプリケーションサーバからの命令で求められた特定の情報データの送信可否を、前記検索サーバからの命令に基づいて決定し、前記ユーザユニットが有する情報データのうち送信可と決定された前記特定の情報データを送信する手段と、
    を備えることを特徴とするユーザユニット。
24. コンピュータ実行可能コンポーネントを格納するコンピュータ読取り可能媒体であって、
    前記コンピュータ実行可能コンポーネントをユーザユニットに含まれているマイクロプロセッサ上で実行するときに、
    ユーザユニットと一緒に使用される製品の表面であって前記ユーザユニットへ情報を入力するために用いられる表面から情報を読み込み、その情報の少なくとも一部をサーバに通信することができる前記ユーザユニットに、請求項１〜２２のいずれかに記載された方法を実行させるようにすることを特徴とするコンピュータ読取り可能媒体。

Images