ウェブサービスと相互作用するための方法および装置
【課題】 複数の異なるウェブサービスと実質同時に独立に相互作用することができるフレキシビリティの高い方法を提供する。
【解決手段】 映画ポスターなどのオブジェクトに付された各タグは、ウェブサービス記述の格納先へのリファレンスまたはウェブサービス記述の識別子を含むものである。斯かるタグからユーザの携帯機器のタグリーダで読み出されたデータを格納できる値ストアを、ウェブサービスとの相互作用を制御する相互作用マネジャ内で管理する。タグに含まれたデータをリファレンスまたは識別子と一緒に値ストアに格納する。ウェブサービスが起動したら、値ストアを検索して関係のあるパラメータが値ストアに既に格納されており使用できるかどうかをチェックする。これにより、パラメータの入力は順序に依存しなくなる。その結果、複数の相互作用マネジャは、それらが共に実行を完了するまで独立に使用することが可能となる。
【解決手段】 映画ポスターなどのオブジェクトに付された各タグは、ウェブサービス記述の格納先へのリファレンスまたはウェブサービス記述の識別子を含むものである。斯かるタグからユーザの携帯機器のタグリーダで読み出されたデータを格納できる値ストアを、ウェブサービスとの相互作用を制御する相互作用マネジャ内で管理する。タグに含まれたデータをリファレンスまたは識別子と一緒に値ストアに格納する。ウェブサービスが起動したら、値ストアを検索して関係のあるパラメータが値ストアに既に格納されており使用できるかどうかをチェックする。これにより、パラメータの入力は順序に依存しなくなる。その結果、複数の相互作用マネジャは、それらが共に実行を完了するまで独立に使用することが可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はウェブサービスと相互作用（interaction）するための方法および装置に関する。
【背景技術】
【０００２】
ＮＦＣ（Near Field Communication）、ＲＦＩＤ（Radio Frequency Identification）、および２次元視覚的タグなどの多数の技術は、デジタル情報を任意のオブジェクトと関連付けるための方法を提供する。結果として、それらの技術のおかげで、ユーザがそのユーザらの環境内にある任意のオブジェクトを通じて情報にアクセスし、次いでサービスにアクセスするという、あらゆるものが繋がるインターネット（ＩｏＴ：Internet of Things）と広い意味で呼ばれている１つの構想が現実のものとなる。
【０００３】
１Ｄまたは２ＤバーコードリーダからiMode-FeliCa（より詳しくは後述）などのサービス商品に至るまで、これらの技術を活用する多数のソリューションが既に開発されている。しかしこれまでのところ、オブジェクトをインターネット上で利用可能なサービスと動的に関連付ける問題に取り組んだソリューションは存在していない。言い換えると、今日までのところ、適切なリーダで電子タグまたは視覚的タグが強化された任意のオブジェクトに接近し、そのオブジェクトに関連するサービスと自動的に相互作用することは不可能である。現在までの全てのソリューションは、特定のサービスと協働する前にリーダがカスタマズされることを必要とする。
【０００４】
以下、当該分野で周知のいくつかのソリューションについて説明する。
【０００５】
サービスとタグとを関連付けることは、新しいアイデアではない。実際、学術論文や技報の中で多数のソリューションが提案されている。既存の用途および学術的なプロジェクトではサービスとタグとの関係は常にハードコード（hard-coded）されている。このため、既存のシステムでは、タグとサービスとの間に事前に定められたハードコードされた関係が一切存在しない場合には、任意のオブジェクトを使ってサービスを利用することは不可能である。
【０００６】
さらに、従来技術におけるオブジェクトとの相互作用は、常に単一の読取り行為に限定される。具体的には、相互作用は、タグを読取り、その値をサービスに送信することに限定される。それに対し、図２に示すように複数の映画を宣伝する映画ポスターなどのオブジェクトと相互作用するには、複数のタグに付随した値がサービスに送信されることが要求される。
【０００７】
以下、従来技術のアプローチについてより詳細に説明する。
【０００８】
サービスとタグとを結びつける複数の方法が存在している。第１のやり方では、タグはサービスと結びついたアクティブリーダ（active reader）で構成され、ユーザは情報が格納されたカードを保持する。サービスを開始するには、ユーザはカードをリーダの前にさっとかざし、リーダはカードの所定の場所を読取り、読み出したデータをサービスに直接伝達する。最後は、情報がサービスから返信され、応答としてカードに書き込まれうる。このソリューションは非常に有効であり、公共交通機関から建物までのアクセスなど、多くの用途で利用されている。しかし、最悪の場合、ユーザは使用する各サービスごとに異なるカードが必要になるので、これは非常に柔軟性がない。カードが、例えば日本のFeliCa対応の携帯電話機の場合のように複数のアプリケーションで共有されていても、アプリケーションプロバイダは、カードのどの部分を読取りおよび書き込みするかについて合意しておく必要がある。このため複数のプリケーションプロバイダは事前の取り決めなくして同じカードでビジネス展開することは不可能である。さらに、ユーザは、カードが設定していない新たなサービスと連携してカードを利用することができない。なぜなら、これら新しいサービスがカード上のデータを利用することができないからである。また、最悪の場合、新たなサービスが斯かるデータにオーバライドしてカードが利用不能になる可能性がある。
【０００９】
第２のやり方は、ＩＤをオブジェクトと関連付ける視覚的コード（visual code）を利用するものである。この場合、ユーザは、特定のタイプのタグを読み取ってユーザの機器上でサービスをトリガーするための、ユーザの機器に組み込まれたリーダを保持する。例えば、日本では広告に２Ｄ視覚的コードが頻繁に利用されている。携帯電話機上で適切なアプリケーションを使用することによって、ユーザは視覚的コードの写真を撮り、自動的にブラウザに広告会社のウェブページをロードする。この場合、視覚的マーカ（visual marker）で可能なサービスはウェブページのダウンロードだけであるため、その関係がまだハードコードされている。
【００１０】
第３のやり方では、タグとの相互作用と、サービスとの相互作用とは別々に分けられたままである。それでもタグを通じて集められた情報は、サービスに情報を提供するために利用することができる。このソリューションの一例は、非特許文献１で提供されている。このＲＦＩＤを使用するシステムは、オブジェクトまたは人が在室であることを識別するために利用され、それに対し、ウェブサービスはサービスを提供するために利用される。ウェブサービスおよびＲＦＩＤが同じシステムで使用される事実にもかかわらず、それらは２つの非常に異なるタスクを実行し、それらは決して一緒には働かない。ＲＦＩＤは識別にのみ使用され、これを言い換えると、環境内の人とオブジェクトとにあるＲＦＩＤタグが、非常に受動的で、それらが識別するオブジェクトのＭＡＣｉｄを報告するだけであるということを意味する。他方、サービスはＳＯＡ（Service Oriented Architecture）によって記述されるインフラストラクチャ（infrastructure）を通じて呼び出される。実際には、ウェブサービスはＵＤＤＩレジストリに登録され、それらはＵＤＤＩレジストリを通じて発見される。サービスは、直接相互作用し、ＳＯＡサイクルの間においてＮＦＣまたはＲＦＩＤタグは、環境内のオブジェクトと人とに関する識別情報を提供する以外には決して使用されない。
【００１１】
第４のやり方では、多数のサービスクライアント（service client）が電話機に既にロードされうる。そしてサービスとの相互作用を制御する適切なクライアントを選択し、相互作用している間、情報をサービスに伝送するためにＩｏＴタグが利用される。このタイプのアプリケーションの例としては、日本のＮＴＴドコモ社が開発したiMode-FeliCaが挙げられる（非特許文献２参照）。iMode-FeliCaのおかげでＮＴＴドコモ社の顧客は、例えば経常収支または利用明細書、および支払サービスなどの異なるタイプのサービスを利用することができるが、これらのサービスを利用するにはユーザはサービスクライアントの機能を果たすｉアプリ・スタブ（i-appli stub）を最初にダウンロードする必要がある。ｉアプリは携帯電話機のｉモードプラットフォームで動作するＪａｖａ（登録商標）のＤｏＪａダイアレクトで書かれたｉモード用Ｊａｖａ（登録商標）アプリケーションである。ダウンロードされると、ｉアプリは、FeliCaプラットフォームサーバを通じて検証される。そして最後に、検証後、ｉアプリはアクティブになり、FeliCaカードにアクセスすることが可能である。サービスとのあらゆる相互作用は、最初に適切なｉアプリの識別が必要であり、次にサービスクライアントの機能を果たすｉアプリの利用が必要となる。
【００１２】
ＲＦＩＤを使ってサービスをいかに呼び出すかを記述した、オウル（Oulu）大学により開発されたプロジェクトが更に存在している（非特許文献１参照）。その基本的なアイデアは、各ＲＦＩＤが例えば印刷サービスといったサービスのタイプを示すというものである。タグを読み取るとすぐに、携帯電話にロードされたサービス・ミドルウェア・エンジン（service middleware engine）が、選択されたサービスのタイプに対応するサービス・スタブを起動し、サービス・スタブは最もよく適合する利用可能なサービスを探して、そのサービスを開始させる。このシステムは、このスタブが既にロードされておりミドルウェアに利用可能であることを必要とする。例えば、印刷スタブがロードされていなければ、印刷サービスが例え利用可能であるとしても印刷アイコンをスワイプしても何のサービスも始まらない。
【００１３】
iMode-FeliCaなどのソリューションは、銀行取引明細書または交通システムにアクセスするなどの長期にわたって存続し続けるサービスを可能にするのに効果的である。これらの場合、クライアントは一回インスタンス化され、必要であれば検証され、その後はユーザがサービスを必要とするときにそのサービスにアクセスするために使用される。しかし未知のタグ付けされたオブジェクトとの不用意な相互作用には対応していない。
【００１４】
以上の概説は、タグをサービスと関連付ける多くのやり方が存在することを示している。それらは全て、いまのところ、ハードコードされたソリューションをもたらすだけであって、ユーザが未知のサービスと相互作用しようとしてもうまく機能しない。例えば、仮に４本の映画を宣伝する映画ポスターであって、しかもそれらの映画や映画館などについての情報を含み、ユーザがウェブサービスと相互作用して或る特定の映画館において４本の映画のうち１本以上の映画を観るためにチケットを予約したりあるいは購入したりすることを可能にするＲＦＩＤタグが組み込まれた映画ポスターにユーザが遭遇する状況を想定することができる。従来技術では、ユーザが、タグを読取りウェブサービスを呼び出してそれと相互作用するための、サービスに対応するアプリケーションを、携帯電話機にインストールしていない場合には、ユーザは、タグ付きの映画ポスターを使ってウェブサービスを呼び出し、それを利用することは不可能であろう。
【００１５】
サービスとの接続の問題に加えて、ユーザとオブジェクトとの間の相互作用によって別の次元が定義される。通常、ユーザはタグの前に携帯電話機またはカードをさっとかざすまたは視覚的マーカを写真に撮るといった唯一のアクションを行う必要がある。こうしたアクションは、サービスを呼び出し、そのサービスに適切なデータを送信することになる。既に指摘したように、このユーザ相互作用メカニズムは、サービスを呼び出すのに複数のアクションを必要とするような例えば映画ポスターに関連して説明した問題に対処するには十分でない。具体的には、ユーザは、チケットを購入することができる前に、（１）所望の映画、（２）所望の上映時間、（３）所望の映画館、および（４）所望のチケット数を指定する必要がある。
【００１６】
従来技術では、ユーザによる複数のアクションは知られていない。通常使用されるポイント＆クリックではなく例えば投げ縄ツール選択（lasso selection）などのより複雑なジェスチャを用いる方法を提供する提案が存在している（例えば非特許文献３参照）。ユーザは、投げ縄ツールを使って地図から複数の情報を同時に選択することができるが、それでもまだユーザは複数のアクションの代わりに唯一のアクションを行う。タグ付きオブジェクトに関連したアクションへの異なるアプローチは、非特許文献４で研究されている。そこでは“ポインティング”および“スキャニング”といった異なる相互作用技術が調べられている。まだここでもユーザはオブジェクトから情報を収集するのに１回の単一アクションを行う必要がある。
【００１７】
ＮＦＣタグを使ってオブジェクトを拡充し、斯かるオブジェクトを使って例えば映画チケットや公共交通機関の乗り物チケットなどの商品を購入する問題について述べている刊行物が存在している（例えば、非特許文献５、６および７参照）。
【００１８】
上記刊行物は、斯かる購入をサポートする仮想システムのインフラを提示しており、第２に低フィデリティのペーパープロトタイプ（low fidelity paper-prototype）が議論されている。そのアーキテクチャは２つの要素に分割される。１つは相互作用プロキシ（Interaction Proxy）で、これはサービスの構成（Service Composition）、推論（Reasoning）、ユーザインタフェース生成（User Interface Generation）のようなタスクを担う。もう１つは携帯電話機上に存在するユニバーサルクライアント（Universal Client）であり、これはユーザインタフェース（Use Interface）を提供し、ＰＭＬフレームワークを活用したタグの読取りを担う。ＰＭＬは、特にインターネットを通じて物理的環境の監視と制御に使用される、物理的オブジェクトを記述するための一般言語である。その用途としては、在庫追跡、自動取引、サプライチェーン管理、マシン制御およびオブジェクト間通信などが含まれる。ＰＭＬについての詳細はhttp://web.mit.edu/mecheng/oml/index.htmlを参照されたい。
【００１９】
構想を提供したり、システムの要件を記述するほかに、上記論文は、潜在的なユーザが本発明のリポートに提示された能力の一部を有することができる仮想システムに応答することを求められているペーパープロトタイプ（paper-prototype）の実験を議論している。ペーパープロトタイプ（paper-prototype）の実験は、検査対象のシステムのペーパーモックアップ（paper mockups）、基本的にはシステムが存在した場合にユーザが見るであろうスクリーンショットのペーパーリーフレット（paper leaflets）を使用して実行される。それらは、潜在的なユーザの斯かるシステムに対する応答を評価するために使用される。
【非特許文献１】J. Riekki, T. Salminen, I. Alakarppa; Requesting Pervasive Services by Touching RFID Tags; IEEE Pervasive computing, 2006
【非特許文献２】Yoshinaga H., Hattari Y., Sato T., Yoschida M. and Washio S. i-Mode FeliCa; NTT DoCoMo Technical Journal, Vol 6, No 3, Dec 2003 and deployed by NTT DoCoMo in Japan
【非特許文献３】Reilly, D., Welsman-Dinelle, M., Bate, C., and lnkpen, K. (2005). Just Point and Click? Using Handhelds to Interact with Paper Maps. In Proceedings of Mobile HCl 2005
【非特許文献４】Enrico Rukzio, Karin Leichtenstem, Vic Callaghan, Albrecht Schmidt, Paul Holleis, Jeannette Chin; An Experimental Comparison of Physical Mobile Interaction Techniques: Touching, Pointing and Scanning; Eighth International Conference on Ubiquitous Computing (Ubicomp 2006), California, USA. 17-21 September 2006
【非特許文献５】Gregor Broll, Sven Siorpaes, Enrico Rukzio, Massimo Paolucci, John Hamard, Matthias Wagner, Albrecht Schmidt.; Supporting Service Interaction in the Real World; In Permid Workshop 2006 in conjunction with Pervasive 2006, Dublin, Ireland, May 7 2006
【非特許文献６】Enrico Rukzio, Massimo Paolucci, Matthias Wagner, Hendrik H. Berndt, John Hamard, A. Schmidt.; Mobile Service Interaction with the Web of Things; 13th International Conference on Telecommunications (ICT 2006), Funchal, Madeira island, Portugal, May 9-12 2006
【非特許文献７】Sven Siorpaes, Gregor Broll, Massimo Paolucci, Enrico Rukzio, John Hamard, Matthias Wagner, Albrecht Schmidt.; Mobile Interaction with the Internet of Things; In Late Breaking Result and Poster at 4th International Conference on Pervasive Computing (Pervasive 2006), May 7-10, 2006, Dublin, Ireland
【００２０】
上記論文には完全なプロトタイプが提供されているという主張がなされているが、基本的な細部が欠けている。具体的に言えば、
１．サービス記述（service description）がタグとどのように関係しているのかについての議論が全くない。例えば“タグのコンテンツは何か？”あるいは“相互作用プロキシ（Interaction Proxy）またはユニバーサルクライアント（Universal Client）は相互作用するためのプロセスをどのようにして見つけるのか？”といった最も素朴な問いかけも答えられていない。
２．サービスは事前に知られていないために、インフラ全体が移動中に（on the fly）生成される必要があるが、それがどのように生成されるのか、どんな能力が携帯電話機またはプロキシに期待されるかについての議論がまだ全く存在しない。
３．ユーザインタフェースがサービス記述とどのように関係するかについての議論も全く存在しない。もちろん、サービスとの相互作用やユーザとの相互作用は同期する必要があるが、まだそのようなメカニズムは提案されていない。
４．この取り組みの１つの重要な特徴は、複数のユーザアクションがオブジェクトと相互作用するのに必要とされるという点にある。しかしながら、インフラがこのプロセスをどのようにサポートするかについて説明がまだなされていない。インフラは新しいタグが読み取られるごとに再インストールされるのか？あるいはそれは再利用されるか？タグからの値はすぐにサービスに渡されるのか？あるいはそれらは将来の利用のためにどこかに保存されるのか？そして相互作用の結果はどこに保存されるのか？
５．複数のサービスが同じオブジェクトを通じて使用されうるが、まだそのようなケースに対するインフラは提供されていない。
６．何のアルゴリズムも提示されていない。従って、斯かるシステムを再現することができるようなこの分野の専門家またはプログラマがいない。
【００２１】
結局のところ、上記論文は、現実世界のオブジェクトとの相互作用をサポートすることができるシステムの構想とアイデアを提供するが、しかしながら斯かるシステムが実際にどのように働くかについての技術的な詳細は何も提供されていないのである。
【発明の開示】
【００２２】
本発明は、上記課題を解決するため、ユーザの携帯機器と物理的オブジェクトに添付されたタグに対応するウェブサービスとの間の相互作用（interaction）を実行するための方法を提供する。
当該方法は、
ある物理的オブジェクトに付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るステップであって、前記タグ情報が、ウェブサービス記述（description of the Web service：以下ウェブサービス記述という）または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、ステップと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするステップと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするステップと、
相互作用マネジャがある相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中でインデックス付けされるような相互作用マネジャ・レジストリ、または、相互作用マネジャが前記ウェブサービス記述を識別する前記識別子を用いてその中でインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするステップと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするステップと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するステップと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するステップとを含み、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該方法は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するステップと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするステップとを更に含む。
【００２３】
このおかげで、携帯機器はウェブサービスクライアントが携帯機器上にまだインストールされていなくてもタグに対応するウェブサービスと相互作用することができる。
【００２４】
相互作用マネジャ・レジストリを管理することで、相互作用マネジャまたはサービスクライアントをそれが一旦生成されたら再利用することが可能となる。各タグが格納場所の識別子を有する場合、タグが読み取られるごとに、上記チェックを実行することができ、新しい相互作用マネジャを生成すべきかまたは既に存在する相互作用マネジャを使用するべきかを決定することができる。
【００２５】
それゆえ、各生成された相互作用マネジャ（およびそれらの対応するサービスクライアント）ごとに相互作用マネジャ・レジストリを管理することで、システムは読み取られているタグに基づくある特定のウェブサービスに対して対応するサービスクライアント（相互作用マネジャ）が既に生成されているかどうかをチェックすることが可能となる。既に生成されている場合、既に生成された相互作用マネジャが再利用され、まだ生成されていない場合は、最初にサービスクライアントが生成される。
【００２６】
さらに、それを通じて複数の相互作用マネジャがインデックス付けされ、その結果、互いに独立に呼出が可能なこの相互作用マネジャ・レジストリのおかげで、２つの相互作用マネジャをそれらが共に実行を完了するまで独立に使用することが可能となる。
【００２７】
値ストアを管理することで、パラメータの順序に依存しない入力が可能となり、アクションを順序に関係なく実行することができる。
【００２８】
本方法の一態様によれば、前記ウェブサービス記述は、ユーザインタフェースの記述を更に含み、当該方法は、
前記ウェブサービス記述に基づいて、どういった情報がユーザに提供されるかと、どういった情報がユーザから求められるかとを特定するユーザインタフェースを生成するステップを更に含む。
【００２９】
このおかげで、ウェブサービスに属する任意のユーザインタフェースを利用することができる。
【００３０】
本方法の一態様によれば、前記ウェブサービス記述は、
ウェブサービスの動作をどの順序で実行するかを指定する、ウェブサービスのプロトコルの記述を含むものである。
【００３１】
このおかげで、サービスクライアントのプログラム論理がウェブサービスの要件に応じて実行されるように相互作用マネジャを生成することができる。
【００３２】
本方法の一態様によれば、タグは、前記ウェブサービスが入力として使用する値のほかに、前記値のＩＤおよび／または前記ウェブサービス記述の前記格納先へのリファレンスもしくは前記ウェブサービス記述の前記識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含むタグのＩＤと、前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである。
【００３３】
このおかげで、任意の情報を含む任意のタグを利用することができる。
【００３４】
本方法の一態様によれば、タグは前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、
前記アクション識別子は、
前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含み、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる。
【００３５】
斯かる“アクションタグ（action tags）”を使用するおかげで、ユーザが携帯機器でタグを読み取ることで、ウェブサービスによって実行されるべきアクションをトリガーすることができる。
【００３６】
本方法の一態様によれば、前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性をユーザに与え、それによりユーザが前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じてそのデータを入力することができる。
【００３７】
このおかげで、ユーザは接続性が失われたとしても相互作用を継続することができる。さらに、ユーザがユーザインタフェースによる入力の方がより便利だと分かれば、タグから入力を読み取る代わりにユーザインタフェースを選択することができる。
【００３８】
本発明は、上記課題を解決するため、あるユーザの携帯機器とある物理的オブジェクトに付されたタグに対応するウェブサービスとの間の相互作用を実行するための装置を提供する。当該装置は、
ある物理的オブジェクトに添付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るモジュールであって、前記タグ情報が、ウェブサービスの記述（以下、ウェブサービス記述）または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、モジュールと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするモジュールと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするモジュールと、
相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中で相互作用マネジャがインデックス付けされるような相互作用マネジャ・レジストリ、または、前記ウェブサービス記述を識別する前記識別子を用いてその中で相互作用マネジャがインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするモジュールと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするモジュールと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するモジュールと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するモジュールとを備え、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該装置は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するモジュールと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするモジュールとを更に備えるものである。
【００３９】
本装置の一態様によれば、前記ウェブサービス記述は、ユーザインタフェースの記述を更に含みものであり、当該装置は、
前記ウェブサービス記述に基づいて、どういった情報がユーザに提供されるかと、どういった情報がユーザから求められるかとを特定するユーザインタフェースを生成するモジュールを更に備えるものである。
【００４０】
本装置の一態様によれば、前記ウェブサービス記述は、
ウェブサービスの動作をどの順序で実行するかを指定する、ウェブサービスのプロトコルの記述を含むものである。
【００４１】
本装置の一態様によれば、タグは、前記ウェブサービスが入力として使用する値のほかに、前記値のＩＤおよび／または前記ウェブサービス記述の格納先へのリファレンスもしくは前記ウェブサービス記述の識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含むタグのＩＤと前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである。
【００４２】
本装置の一態様によれば、タグは前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、前記アクション識別子は、
前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含み、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる。
【００４３】
本装置の一態様によれば、前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性をユーザに与え、それによりユーザは前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じてデータを入力することができる。
【００４４】
本装置の一態様によれば、タグに含まれる情報は、前記ウェブサービスの記述が格納された格納先へのリンク情報を含むものである。
【００４５】
このおかげで、ウェブサービス記述のダウンロードと、ウェブサービスクライアントの生成とが、そのウェブサービスクライアントが事前にインストールされていなくとも可能である。
【００４６】
本発明は、上記課題を解決するため、コンピュータ上で実行されたときに上記いずれかの方法を実行することを可能にするプログラムコードを含むコンピュータプログラムも提供される。
【発明を実施するための最良の形態】
【００４７】
以下、本発明の実施の最良の形態を添付図面を参照して詳細に説明する。本発明の実施形態は機能が拡充された任意のオブジェクトを（Ｗｅｂ）サービスと関連付けることが可能である。ここで言うウェブサービス（Web service）とは、ＷＳＤＬ文書で記述することができる、インタネット上で利用可能な任意のプログラムを最低限包含するものであると理解されたい。ＷＳＤＬは、ウェブサービス記述言語（Web Service Description Language）である。ＷＳＤＬについての詳細はhttp://www.w3.org/TR/2006/CR-wsdl20-20060327から入手可能な非特許文献［Chinnici R., Moreau J., Ryman A.; Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language; W3C Candidate Recommendation 27 March 2006］とその関連文書を参照されたい。
【００４８】
Ｗ３Ｃ定義によれば、ウェブサービスとは、「標準的なＷｅｂプロトコル、記法および命名法を使用して送られたメッセージを使ってアクセス可能なサービスである（この標準的なＷｅｂプロトコル、記法および命名法は、ＸＭＬプロトコル（またはＸＭＬプロトコルが標準化されるまではＳＯＡＰ）を含むものである）。ウェブサービスは、ウェブサービスインタフェースを定義するためのＷＳＤＬおよびＵＤＤＩなどの補助メカニズムの利用も暗示している場合もある」。
【００４９】
ウェブサービスとは、ネットワーク上の相互動作可能なマシン間の相互作用（interaction）をサポートするように設計されたソフトウェアシステムであると言うこともできる。それは機械処理可能なフォーマット（具体的にはＷＳＤＬ）で記述されるインタフェースを有する。他のシステムは、ウェブサービスと、ＳＯＡＰメッセージを使用するウェブサービス記述によって指示された方法で相互作用する。このＳＯＡＰメッセージは、一般的には、他のＷｅｂ関連標準と併せてＸＭＬシリアライゼーション（XML serialization）でＨＴＴＰを使用して搬送されるものである。
【００５０】
本発明の実施形態の説明を続ける前に、最初に以下の説明で使用される用語について明らかにする。
ＨＴＴＰ（Hypertext Transfer Protocol）：ハイパーテキスト転送プロトコル
ＩｏＴ（Internet of Things）：あらゆるものが繋がるインターネット
ＮＦＣ（Near Field Communication）：近距離無線規格
ＯＷＬ−Ｓ（OWL Service Ontology）：ウェブサービスに関するオントロジーを記述するためのマークアップ言語
ＲＦＩＤ（Radio Frequency Identification）：電波方式認識. 電磁波を使って、物品や人物などの個体識別を自動的に行う技術の総称
ＳＯＡＰ（Simple Access Object Protocol）：ＸＭＬとＨＴＴＰなどをベースとした、他のコンピュータにあるデータやサービスを呼び出すためのプロトコル
ＵＩ（User Interface）：ユーザインタフェース
ＵＲＩ（Universal Resource Identifier）：統一資源識別子
ＵＲＬ（Universal Resource Locator）：統一資源位置子
ＷＳＤＬ（Web Services Description Language）：ウェブサービス記述言語
ＸＭＬ（Extensible Markup Language）：拡張可能マークアップ言語
【００５１】
以下、ユーザの機器がタグによって提供された情報からサービスクライアントと必要に応じてユーザインタフェースとを自動的に生成することを可能にする本発明の実施形態について説明する。生成されたサービスクライアントを使用することで、ユーザはウェブサービスと相互作用することができる。
【００５２】
以下の説明からより明らかになるように、使用されるタグ付け技術のタイプは関係がなく、サービス記述（service description）のアドレスと、例えばそのサービスで実行される動作やそのサービスに送られる値などの追加情報とを提供するような或る種のタグの存在が重要である。
【００５３】
図１おいて、サンプルの用途として本発明を適用することが可能な映画ポスターを示している。ポスターの中心にある４つの絵は異なる映画を示している。また左上にある３つの小さなボックスは映画を上映する映画館、右上にある小さなボックスは上映時間、左下の小さなボックスは取得可能なチケット数、右下の小さなボックスは映画館までの公共交通機関の選択肢が示されている。各ボックスには、ポスターの裏側から関連するＮＦＣタグが貼付されている。こうしてポスターは、入力としてユーザが観たい映画、その映画を上映している映画館、ユーザが希望する上映時間を取得し、出力として映画チケットを発行するサービスと関連付けられる。ＮＦＣ対応携帯電話機を携帯する移動ユーザは、ポスターのタグを読取り、自動的にサービスを呼び出して映画チケットと映画館までの乗り物チケットを購入することができる。
【００５４】
次に、ユーザがウェブサービスと相互作用するための対応するサービスクライアントをユーザの機器にインストールしていない状況を想定する。この問題を解決するため、本発明の実施の一形態によれば、オブジェクトとの相互作用を通じてサービスクライアントが生成され、更にそのオブジェクトはサービスとの相互作用を制御するために使用される。このソリューションは、ウェブサービス技術に基づいている。従って、最初に、サービスによって実行される動作（オペレーション）のワークフローと、それらの動作を実施するために交換されるメッセージと、これらのメッセージのフォーマットと、入出力ポートの仕様と、クライアントとサーバとの間でこれらのメッセージを交換するために使用される転送プロトコルとに関して、サービスの相互作用プロトコルの宣言的仕様が設定される。結果として、サービスとの相互作用を制御するためにクライアントが移動中に生成され、相互作用が完了したらそのクライアントは破棄される。
【００５５】
実施の一形態によれば、タグ付けされたオブジェクトを通じての機器のサービスとの相互作用をサポートするため、図２に示すような以下の３つのコンポーネントが提供される。
１．ユーザの機器がアクセスするインターネットまたはローカルネットワークを通じて到達可能なサービス。このサービスの振る舞いは、例えば、ＷＳＤＬ、ＯＷＬ−ＳまたはＷＳ−ＢＰＥＬなどのウェブサービス記述言語を使って記述される。後者の記述はユーザの機器によっても到達可能でなければならない。
２．視覚的または電子タグで拡充されたオブジェクト。タグは、サービス記述、サービスで実行される動作、および／またはサービスに送られる値に関係している。
３．ユーザがそれを使ってタグを読取り、サービスを呼び出すことができる機器。
【００５６】
ユーザの機器としては、携帯電話機、スマートフォン、あるいは例えばＰＤＡもしくはサブノートパソコンなどの何か他の類似の機器が挙げられる。携帯電話によっては以下に述べる全ての機能を実行するのに必要な計算能力を持たない場合があるため、一部の処理は、例えばオペレータが提供するサーバまたは時としてユーザのホームコンピュータなどへの遠隔の手続き呼出しを使って遠隔サーバで実行されうる。
【００５７】
ユーザ用機器内のコンポーネントは、ユーザ用機器がタグを通じてサービスにアクセスすることを制御するアルゴリズムの３つのメインステップに関与する。これらのコンポーネントを図２に示している。具体的に言えば、タグリーダ（Tag Reader）はアルゴリズムの第１のステップとしてタグを読み取るために当然必要とされる。タグリーダは、タグを読み取るために必要とされるハードウェア−視覚的コードの場合はカメラ、またはＮＦＣもしくはＲＦＩＤリーダ−のほか、そのハードウェアを操作するために必要とされるソフトウェアと、ＡＰＩをシステムの残りの部分に公開するのに必要なソフトウェアとを両方含まなければならない。
【００５８】
アルゴリズムの第２のステップは、タグによって提供された情報を使用して、タグリーダからサービスヘの情報の流れとユーザインタフェースとを管理する責任を負う相互作用マネジャ（Interaction Managers）のインスタンスを生成（instantiate）することである。相互作用マネジャ・レジストリ（Interaction Managers Registry）はこれらの相互作用マネジャを生成し、それらを将来のタグの読取りで使用するために格納する責任を負う。
【００５９】
アルゴリズムの第３のステップは、相互作用マネジャを使用して、タグとサービスとユーザとの間のデータフローを制御することである。斯かるプロセスをサポートするために２つのコンポーネントが必要とされる。第１のコンポーネントは、ウェブサービスとの相互作用に関与する。斯かるコンポーネントは、ウェブサービスとの相互作用をサポートする１セットのライブラリを通じて実行時間に実現される。斯かるライブラリは、多くの場合、ラベル付きのウェブサービススタック（Web Services Stack）であり、斯かるライブラリは、ネットワーク管理と、ＳＯＡＰおよびＨＴＴＰ処理と、ＷＳＤＬ解釈と、ウェブサービスプロトコルの実行のためのＡＰＩとを提供する。ウェブサービススタックの例は、Apache Axis（ws.apache.org/axis/参照）、Ｊ２ＥＥ、Microsoft.Netといったライブラリのほか、ＯＷＬ−Ｓ ＡＰＩ（http://www.mindswap.org/2004/owl-s/api/参照）といったライブラリを含む。第２のコンポーネントは、サービス記述に記述された抽象的ユーザインタフェースを、ユーザに表示される具体的ユーザインタフェースに変換する働きをするＵＩプロセッサである。
【００６０】
これらの３つのステップを使ってユーザはウェブサービスと相互作用することができる。
【００６１】
アルゴリズムの３つのステップを以下の３つのセクションで詳しく説明する。
【００６２】
［タグの読取り］
アルゴリズムの第１のステップは、タグの読取りである。タグは現在利用可能な多くの異なるタグ付け技術のいずれかを用いてコード化することができる。現在利用可能なタグ付け技術としては、ＮＦＣ／ＲＦＩＤからセマコード（記述はhttp://www.semacodes.org参照）を使用する視覚的コード（ビジュアルコード）まで、場合によってはBluetoothまたはＷＬＡＮなどの他の標準に基づく他のタグ付け技術などが挙げられる。タグ付け技術のタイプは、ユーザ用機器がタグの読取りを通じて情報を取得する限りは、本発明ではどんなタイプでも構わない。重要なものはタグの内容である。本発明の実施形態によれば、以下の３つのタイプのタグが存在する。
１．Actionタグ：チケットの予約または商品の購入などのサービスによって実行される動作と関連付けることが可能なタグ。Actionタグは、（ａ）作業が記述されたウェブサービス記述のＵＲＬと、（ｂ）サービス記述内の動作のｎａｍｅまたはＵＲＩとを提供することによって、実行される動作を一意に識別する必要がある。
２．Valueタグ：値に関連するタグ。例えば、観たい映画または上映時間などに関連するタグ。これらのタグは実施の一形態によれば、４つの情報：（ａ）データの値、（ｂ）データのタイプ、（ｃ）データをサービスに送られる情報とユーザに表示される情報との両方と関連付けるために使用されるＩＤ、および（ｄ）サービス記述のある場所を示すＵＲＬ、を含む。
３．Hybridタグ：実行されるアクションと値との両方を表現することによって前の２つのタイプのタグを組み合わせるタグ。
【００６３】
ActionタグとValueタグとの例を、図３と図４とにそれぞれ示している。図３におけるActionタグの例は、サービスによって実行される動作（オペレーション）bookMovieを指定する。そのサービス記述は以下のＵＲＬを参照されたい。
http://perci.medien.ifi.lmu.de:8080/axis/serviceDescription/extendedCinema
【００６４】
図４のValueタグについては、データの値は映画のタイトルGeisyaで与えられ、データのタイプは<abstractType>、ＩＤは<id>movie</id>、そしてサービスＵＲＩは上と同じＵＲＩで与えられる。
http://perci.medien.ifi.lmu.de:8080/axis/serviceDescription/extendedCinema
<abstractType>といった追加のタグは追加の推論に利用することができるようタグの意味的な値（semantic value）を特定するために使用される。タグ<label>および<desc>は、開発者を対象とする文書化に利用される。
【００６５】
斯かるタグを使用して、ユーザ用機器は第１のステップとしてタグの読取りを実行することができる。
【００６６】
［相互作用マネジャの生成および／または検索］
アルゴリズムの第２のステップは、サービスと相互作用するために相互作用マネジャのインスタンスを生成（instantiate）する目的を有する。手短に述べたように、相互作用マネジャは、サービスクライアントとユーザインタフェースを制御するものである。択一的な２つの可能性が存在する。１つの可能性は、サービスは既知で、この場合、携帯電話機は既にそのサービスに対するクライアントを有している。もう１つの可能性は、サービスは未知で、この場合、携帯電話機はサービスおよびユーザインタフェース記述についての利用可能な情報を用いて新たな相互作用マネジャのインスタンスを生成する必要がある。斯かるプロセスは以下のステップによって制御される。
１．相互作用マネジャ・レジストリは、サービス記述のＵＲＬからそのサービスと相互作用するために必要とされる相互作用マネジャへの対応を管理する。
２．タグから読み出したＵＲＬが与えられると、携帯電話機は、相互作用マネジャ・レジストリからそのサービスに対応する相互作用マネジャ、または斯かる相互作用マネジャが存在しない場合には空値を検索する。
３．相互作用マネジャが見つかった場合、手続きは、“サービスとの相互作用の管理”に後述されるように、アルゴリズムはサービスとの相互作用の管理に戻る。
４．相互作用マネジャが見つからない場合、携帯電話機は新たな相互作用マネジャを構築する。そのプロセスは以下のステップ（ａおよびｂ）を含む。
ａ）サービスＵＲＬからサービス記述をロードする。本発明の実施の一形態によれば斯かるサービス記述は３つのコンポーネントを含む。
ｉ）サービス動作（オペレーション）、メッセージ動作およびポートに関するＷＳＤＬ記述。
ｉｉ）動作をどういった順番で実行するかを指定するウェブサービスのプロトコルの記述。プロトコル記述は、例えば、抽象的ＷＳ−ＢＰＥＬまたはＯＷＬ−Ｓなどのウェブサービス記述言語で表現することができる。
ｉｉｉ）サービスの抽象的ユーザインタフェースを記述するＷＳＤＬ記述またはプロトコル記述の拡張。ユーザインタフェースは、例えば、ＸＦｏｒｍｓ（例えばhttp://www.w3.org/MarkUp/Forms/参照）、ＸＵＬ（例えばwww.mozilla.org/projects/xul/参照）またはそれに対するレンダリングエンジン（rendering engine）が存在するという条件で任意の他の言語などの任意の抽象的ユーザインタフェース言語で表現することができる。
ｉｖ）ValueタグのＩＤとウェブサービスが期待する入力との間の関連付け。この関連付けは、拡張性エレメントを使用するウェブサービス記述内、またはサービス記述外に定義されたテーブルとして表現することができる。
ｂ）サービス記述がロードされると、相互作用マネジャのインスタンスの生成（instantiation）が以下のステップと一致するように実行される。
ｉ）サービスのＷＳＤＬ記述とサービスプロトコルとが与えられると、携帯電話機は、サービスクライアントのインスタンスを生成する。このステップは、ウェブサービス・スタック・ライブラリ（Web Services stack libraries）を用いて実行することができる。このステップはウェブサービス・スタック・ライブラリを用いて実行することができ、これは相互作用マネジャの実行に関連して言及したのと同じタイプのライブラリによって実行できる。サービスクライアントは、サービス側で（サービスプロトコルと一致するように）どの動作を呼び出すべきかを決定し、それらの動作を（ＷＳＤＬ記述と一致するように）呼び出すために使用される。
ｉｉ）ユーザインタフェースの記述が与えられると、携帯電話機は、作業についての何の情報がユーザが与えられ、何の情報がユーザから求められるかを指定する具体的ユーザインタフェース（concrete User Interface）を生成することができる。この目的のため、ユーザインタフェース言語に対して任意のレタリングエンジンが可能である。斯かるレタリングエンジンは、ＨＴＭＬタグを表示するＷｅｂブラウザから、ユーザインタフェースを表現するために使用される言語に応じて、例えばＳＵＬＵ（http://sulu.sourceforge.net/参照）／ＸＦｏｒｍエンジン（http://alphaworks.ibm.com/tech/xmlforms参照）までがありうる。
ｉｉｉ）Valueタグの値ストア（value store）が生成される。斯かるストアは、そのキーが値のｉｄであるハッシュテーブルと同程度にシンプルにすることができる。値は、タグの実際の値である。
ｉｖ）３つのコンポーネント、すなわちサービスクライアント、ユーザインタフェース、および値ストアは、一緒にパッケージされ、相互作用マネジャを形成するものである。
５．生成された相互作用マネジャは、オブジェクトから読み出された他のタグを処理するために使用されるように相互作用マネジャレジストリに格納される。相互作用マネジャのインデックス付け（indexing）は、サービス記述のＵＲＬに基づく必要がある。これにより、インスタンスが生成された相互作用マネジャによってそのサービスクライアントがユーザ用機器にいまや生成されているウェブサービスと相互作用するよう設計された別のタグにユーザが遭遇した場合に、それを再び呼び出すことが可能となる。
６．相互作用マネジャは、既に述べたようにサービスとの相互作用を制御するために使用される。
【００６７】
当業者であれば、相互作用マネジャ（またはその一部であるウェブサービスクライアント）の“移動中の（on the fly）”の生成は、ウェブサービスクライアントがその対応するタグとの相互作用が可能になるためにハードワイヤード（つまりハードウェアに組み込まれている）または事前インストールされる必要があった以前のアプローチに対する重要な利点であることは理解されよう。しかしながら、当業者であれば、その目的のためには、携帯機器に相互作用マネジャの“移動中の（on the fly）”の生成を可能にするフレームワークがインストールされなければならないことは理解されよう。これは、携帯電話機に例えば相互作用マネジャの実行に関連して既に言及したライブラリを実装することによって実現することができる。このおかげでユーザインタフェースの生成も可能になる。
【００６８】
本発明の実施形態の機能を実装するために必要なその他のコンポーネントは、標準的なプログラミング技術、例えば携帯電話用アプリケーションを生成するための標準的なプログラミング言語であるＪａｖａ（登録商標）を用いることによって実装することができる。
【００６９】
［サービスとの相互作用の管理］
上記ステップの結果、相互作用マネジャが生成され、それを通じて機器は、サービスと相互作用する。相互作用マネジャのアーキテクチャを図５に示す。この図は、幾分詳しく相互作用マネジャの構造と、その異なるコンポーネント同士の間の関係を図解している。
【００７０】
相互作用マネジャが利用可能になると、相互作用マネジャは、電話機にロードされているサービス記述と合致するようにサービスおよびユーザとの相互作用の制御を担う。一般的に言えば、動作（オペレーション）の起動は携帯電話機側に２つの働きをもたらす。第１の働きは、サービスにデータを送信すること、第２の働きは、サービスからデータを受信することである。その過程で、電話機はユーザに情報を表示し、ユーザが入力する情報を読み取る。
【００７１】
サービスにデータを送るために、携帯電話機は以下のステップを行う必要がある。
１）サービス側でどの動作（オペレーション）を実行すべきかを決定する。作業は以下の場合に実行可能となる。
ａ）それはプロトコル言語で記述された順序における次の作業である。
ｉ）非決定論的選択の場合、携帯電話機は、ＵＩアクションがこの問題に対処するために指定されているのであればユーザに決定を求めるか、または自律的に選択を行うことができる。
ｂ）その動作は、Actionタグを通じてユーザによって選択されている。
ｃ）その動作の入力パラメータが取り得る全ての値は、Valueタグを読取ることによってまたは直接的なユーザ入力によって指定されている。
２．ユーザインタフェースを表示する。ユーザインタフェースは、サービス記述の中の動作に関連する抽象的ユーザインタフェース記述によって指定される。抽象的ＵＩの表示は、以下のステップを含む。
ａ）実行すべき表示アクションを選択する。この動作の結果、データが表示される、またはエラーおよび警告メッセージが表示される。
ｂ）ユーザに表示すべきデータを選択する。この選択はタグから読み出された値のＩＤに基づいている。
ｃ）データを抽象的ユーザインタフェース仕様と合致するように表示する。
ｄ）場合によってはユーザインタフェースによって要求される場合にユーザからの入力を読み取る。ユーザ入力もＩＤが割り当てられ、値ストアに格納される。
３．サービスに送るべきデータを選択する。この選択は値ストア内のデータのＩＤとサービスによって要求される入力との間の関連付けを活用して実行される。
４．サービスクライアントを使ってデータを送信する。ＷＳＤＬ記述を使用するサービスクライアントは、送信データの適切なフォーマットと使用するポートおよびプロトコルを選択する。
【００７２】
第２の働き、すなわちサービスからデータを受信するステップは、サービスからの応答を待機することと、サービスが送ったデータを読み取ることとを含む。具体的には、相互作用マネジャは、
１．サービスクライアントから到来するデータを待機する；
２．そのデータにＩＤを割り当て、値ストアにそれを格納する；
３．ＵＩを起動する；
４．サービスのプロトコル記述における次のステップに進む。
プロセスの実行が完了すると、相互作用マネジャは、ステップ１にループバックして別のプロセスを実行するかどうか、あるいはサービスとの相互作用を一時中断してステップ５に進むかどうかを決定する。ステップ５において相互作用マネジャは、相互作用マネジャレジストリに格納される。
５．サービスとの相互作用を一時中断すると、相互作用マネジャは、相互作用マネジャ・レジストリに保管（アーカイブ）され、実行プロセスは、ステップ１にループバックして別のタグを処理するために待機する、またはプロセスとの相互作用が完了した場合にはそれは破棄される。
【００７３】
次に、図１を参照して、本発明の実施の一形態によるシステムがどのように動作するか、そして映画チケットを購入するためにそれがどのように使用されることがあるかについて具体例を使ってより具体的に説明する。ポスターは、４つの映画を宣伝しており、それはこれらの映画を上映する映画館に対応するタグ（左上のタグＴ１、Ｔ２、Ｔ３）と、ユーザが購入したいと考えるチケット数（左下の１、２、３、４）と、上映時間（右上の午後３時、午後５時、午後７時）と、交通機関の選択肢（右下のバス、地下鉄）とを含んでいる。
【００７４】
本例では、ポスターは、２つのサービス（ａおよびｂ）を提供する。
ａ）映画サービスは、３つの動作を含むプロトコルを有し、それらの動作は、以下に列挙した順序で実行しなければならない。
１．Select_Theater_and_Movie、これは入力として映画館および映画を受信し、出力としてその映画がその映画館で上映しているかどうかを返信する。
２．Select_Time_and_People、これは入力として所望の上映時間とチケット数を受信し、座席が入手可能かどうかを示すスタブを返信する。
３．Payment、これは入力として前のプロセスのスタブとクレジットカード番号とを受信し、チケットを返信する。
ｂ）第２のサービスは、入力としてクレジットカード番号およびチケットのタイプを受信し、出力としてトランスポートチケットを返信する、シンプルなトランスポートサービスである。
【００７５】
ユーザは、ポスターに接近して最初に映画タグの１つに携帯電話機器をかざす。するとタグがユーザ用機器によって読み取られる。このタグはHybridタグであって、値として、映画タイトル−例えばGeisha、サービスのＵＲＬ、およびサービスによって実行されるべき作業−Select_Theater_and_Movie−を含む。
【００７６】
タグを読み取るとすぐに、制御は［相互作用マネジャの生成および／または検索］のところで述べたアルゴリズムに従って相互作用マネジャ・レジストリにシフトする。サービスに対する相互作用マネジャはまだ存在しないので、サービス記述（これはタグ内の対応するＵＲＬに示される）に基づいて新しい相互作用マネジャが生成され、それはその記述のＵＲＬでレジストリにインデックス付けされる。
【００７７】
相互作用マネジャが生成されると、その相互作用マネジャは、サービスとの相互作用の制御を担う。値ペア（movie、Geisha）が値ストアに格納される。movieはＩＤで、Geishaはその値である。まだ何の動作（オペレーション）も実行できないので（動作Select_Theater_and_Movieはまだ１つの入力を欠いている）、相互作用マネジャは、その実行を一時中断して次の入力を待機する。
【００７８】
ユーザの第２のアクションは、購入チケット数を例えば２に設定するタグを読み取ることでよい。サービスに対する相互作用マネジャは既に知っているので、それが再利用される。値ペア（tickets，２）が値ストアに追加される。何の動作も実行可能でないので何も実行されない。
【００７９】
ユーザの第３のアクションは、タグを（タグの上に携帯電話機をさかざすことによって）読み取って映画館を選択することでよい。この場合も同様に適切な相互作用マネジャが検索され、値ペア（theater，Rex）が値ストアに格納される。これで動作Select_Theater_and_Movieが実行できる。というのも動作Select_Theater_and_Movieは、プロトコルにおける次の作業であり、全ての値が利用可能で、しかも対応するActionタグまたはHybridタグがユーザによって選択されているからである。結果として、サービスクライアントは、サービス上の動作を呼び出す。これは応答としてその映画がその映画館で上映中であることを表すBooleanを与える。ユーザインタフェース記述が動作の出力に関連していると仮定すると、それはユーザにその映画が所望の映画館で上映中であることを伝達する。最後に、動作の実行が完了し、次の動作の実行が許可される。
【００８０】
相互作用を継続して、ユーザは上述のプロセスと同様のプロセスをトリガーする他のタグを選択することができる。すなわち、タグが既知のサービスと関係しているときは適切な相互作用マネジャが検索される。代わりにそれらが新しいサービスに関係するとき、例えば初めて交通機関タグが読み出される場合には、新しい相互作用マネジャが生成される。最後に、Payment動作といった動作がユーザ入力を要求し、それらは、ユーザに情報を明示的に求めるようなユーザインタフェースをトリガーすることができる。
【００８１】
サービスのプロトコルが終了し、チケットの購入が完了すると、対応する相互作用マネジャは、もはや必要がなくなるので破棄される。ユーザが更なるチケットを購入するために同じポスターを利用しようとする場合には、そのチケット購入プロセスを制御するために新しい相互作用マネジャのインスタンスが生成される。しかしながら、ユーザ用機器の処理能力とメモリ能力とに応じて、相互作用マネジャを、例えば少なくともしばらくの間、ユーザ用機器に保持しておくことも可能である。
【００８２】
本発明の実施の一形態によれば、サービス記述を通じて与えられるユーザインタフェースは、オブジェクトの代わりに使用することができる。本実施形態の背後にあるアイデアは、次のようなものである。図１に示されたポスターのようなオブジェクトは、ユーザがそのおかげで４つの映画の中から１つの映画、３つの上映時間から１つの上映時間などを選択することができる１セットのメニューと見なすことができる。ユーザがオブジェクトとの相互作用を開始し、インタフェースをロードするとき、オブジェクトによって提示されたのと同じ選択肢がユーザインタフェースにも提示される。その目的のため、（物理的タグに格納された）対応するデータは、サーバのどこかに格納しておくこともでき、ウェブサービス記述およびユーザインタフェース記述がダウンロードされるときに、ダウンロードすることができる。結果、携帯電話機のユーザは、物理的オブジェクトとの相互作用を（例えば映画館を選択するために、電話機を対応するタグにかざすことによって）継続するか、あるいはオブジェクトから離れて、携帯電話機のスクリーンとの相互作用を（例えば、対応するラジオボタンを選択することによって）継続するかを選択する。この特徴は、ユーザがオブジェクトとの相互作用をそれが終了する前に例えば接続性ロスその他の理由から中断する必要がある場合に非常に有用となりうる。
【００８３】
一般的に、これは以下の２つの側面を活用して遂行することができる。
ａ．ユーザインタフェースは、物理的オブジェクトを通じてユーザに全ての選択肢を提供するものとする。
ｂ．ユーザインタフェースは、オブジェクトによって転送される全ての隠されたデータをユーザに知られることなく提供するものとする。
【００８４】
最初の要件（ａ）は、ユーザインタフェースが忠実にそれがそこから取得されたオブジェクトを表現することを保証するために必要とされる。二番目の要件（ｂ）は、サービスクライアントがサービスと相互作用するために必要とされる全ての情報を持つことを保証するために必要とされる。
【００８５】
これは、実際には、同じオブジェクトに対して２つのインタフェース−１つはタグを通じての物理的インタフェース、もう１つは携帯電話機のスクリーンを通じての仮想インタフェース−が存在することを意味する。仮想インタフェースは、相互作用マネジャのインスタンスが生成される際にウェブサービスクライアントと一緒に生成され、それに必要な対応するデータは、同じサーバ上に格納することができ、さらに、インタフェースが生成されるときにダウンロードすることができる。
【００８６】
上記システムは、サービスをオブジェクトそのものではなく、オブジェクトに含まれるタグと関連付ける。結果、オブジェクトは、非常に異なるサービスと関連付けられたタグを含むことができる。例えば、図１に示されたポスターは、主に映画の宣伝とチケットの販売に関するものであるが、それだけではなく乗り物チケットの購入も提案している。映画チケットは、映画館が提供するサービスを使って購入される。一方、乗り物チケットは、地域の公共交通機関運営会社が提供するサービスによって提供される。
【００８７】
複数のサービスとの相互作用をサポートするには追加のメカニズムは一切必要ない。ユーザは、映画チケットの購入を開始してよく、映画チケットサービスの相互作用マネジャが提供される。このサービスとの相互作用を終了する前に、ユーザはトランスポートチケットの購入を決める場合がある。トランスポートサービスに対して今度はトランスポートタグにタッチすると、別の相互作用マネジャが提供される。２つの相互作用マネジャはそれらが共に実行を完了するまで独立に使用される。
【００８８】
複数の相互作用マネジャがインデックス付けでき、それによりそれらを互いに独立に呼び出すことが可能になる相互作用マネジャ・レジストリにより、ユーザは２つの相互作用マネジャをそれらが両方とも実行を完了するまで独立に使用することが可能となる。２つの相互作用マネジャは、例えばそれらの間で切り替えが可能である。例えば、ある特定の相互作用マネジャがある時にアクティブになっている場合がある。相互作用マネジャ・レジストリにおける検索（lookup）に基づき別の相互作用マネジャに対応するタグが読み出された場合、アクティブになっているこの他の相互作用マネジャへの切替が行われ、対応するアクションが実行される。このようにして、複数の相互作用マネジャはそれら全ての実行が完了するまで独立に使用される。
【００８９】
前述の説明では、タグ（好ましくは各任意のタグ）は、ウェブサービスを記述する対応するウェブサービス記述の格納先へのリファレンス（reference）を含む。しかしながら、実施の一形態によれば、タグそれ自体がタグ上に十分な空き領域があれば、完全なウェブサービス記述を含むことができる。斯かる場合、タグ読取り動作（オペレーション）は、ＵＲＬといったリファレンスで特定される遠隔の格納先を参照することなく、この完全なウェブサービス記述を直接読み出すことができる。
【００９０】
実施の一形態において、斯かる場合には、タグは好ましくはウェブサービス記述を識別する識別子（ＩＤ）も含み、このおかげで相互作用マネジャ・レジストリは、このＩＤに基づいて既に存在する相互作用マネジャにインデックス付けことができる。タグが読まれた場合、相互作用マネジャ・レジストリは（既に述べたように）、対応する相互作用マネジャが既に存在するかどうか、または最初にそれが生成される必要があるかどうかをチェックする。
【００９１】
実施の一形態によってサポートされる特徴は、ユーザのアクションのサービスのプロトコルからの独立性である。以下、それについてより詳細に説明する。
【００９２】
実施の一形態によれば、相互作用マネジャは、図２に示すように、タグから読み出されたデータを格納するための値ストアを含んでいる。この値ストアは、相互作用マネジャを生成するときに例えばタグから読み出されたデータを格納するための所定の記憶領域を確保または保管することによって、生成または管理することができる。
【００９３】
タグから読み出された任意のデータは、斯かる値ストアに、好ましくはウェブサービス記述の格納先へのレファレンスまたはウェブサービス記述の識別子と一緒に格納することができる。これにより、このデータがパラメータ（例えば、チケット購入サービスの場合、ユーザが映画を観に行きたいと思う映画館）と解釈される実際のサービスが呼出または開始されていなくとも、このデータを格納し、その後、このデータを正しく識別することが可能となる。続いて映画館を識別するデータが値ストアに格納され、後に、ユーザが映画チケットを購入するために（例えば対応するActionタグの上をタグリーダをかざすことによって）実際のウェブサービスを開始する場合に、このとき呼び出されたサービスに対するパラメータ−例えば本例ではユーザによって既に選択された映画館−を既に含んでいるかどうかについて値ストアが検索される。
【００９４】
ユーザは、作業の通常の方法とは対照的に、パラメータ値を、それらを実際に使用しなければならいアプリケーションが開始される前に入力することができる。これは、これらのデータについて値ストアを管理（メンテナンス）し、これらのデータを値ストアにこれらのデータがパラメータとしての機能を果たすサービスのウェブサービス記述の識別子またはウェブサービス記述の格納先へのリファレンスと一緒に格納することによって可能になる。ウェブサービスが実行されると、それは値ストアを調べて、関係のあるパラメータが既に値ストアに格納されており、使用できるかについてチェックすることができる。
【００９５】
このようにして、パラメータの入力は順序に依存しないが、ある程度までは時間と場所にも依存しない。ユーザは例えば、正午前、中央駅でポスターの図１におけるタグＴ２を選択することによって映画館を選択し、次にユーザはその他の入力を完了する前に中央駅を後にしなければならず、同じポスターが貼られた別の駅でその他の関係するパラメータ（チケット数など）を選択することによってこの入力を完了し、そして対応するActionタグを選択することによってウェブサービスを開始することができる。
【００９６】
斯かる実施形態は、ウェブサービスとの相互作用がそれによって可能なフレキシビリティを改善する。異なるウェブサービスをそれらが実質上同時に実行されるように互いに独立に呼び出すことが（上述した相互作用マネジャ・レジストリのおかげで）可能であるばかりか、タグに対応するデータの入力も順序に関係なく入力することが可能である。従来技術のシステムでは、プログラムフローは、ある特定の入力が要求された場合にはこの入力が受信されるまで手続きが停止するようになっている必要があるが、本発明の実施形態は、タグを読み取ることでデータを入力するよりフレキシブルなやり方を実現することができる。その目的のため、タグから読み出されたデータを格納することができる値ストアが提供される。値ストアにはそのデータだけでなく、ウェブサービス記述の格納先へのリファレンスまたはウェブサービス記述の識別子も格納される。
【００９７】
このように、こうして格納されたデータを後で使用することが可能になり、プログラムフローで指定された順序でデータを読み出すことはもはや重要ではない。ウェブサービスが始まる前でもタグを読み取るも可能になる。ウェブサービスが始まったら、それは値ストアを検索してプログラムフローに従って、いま必要なデータが値ストアに既に存在しているかどうかチェックする。
【００９８】
このように、値の入力が順序に依存しなくなるだけでなく、ある程度までは場所にも依存しなくなる。なぜなら、サービスは、異なる場所で、そのサービスを実行するにはまだ欠けているデータを持つタグを読み取ることによって継続することができるからである。
【００９９】
当業者であれば、上述した実施形態は、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアの組み合わせによって実施することができることは理解されるだろう。本発明の実施形態に関連して説明したモジュールおよび機能は全体的または部分的に、本発明の実施形態に関連して説明された方法に従って働くように適切にプログラムされており適切なインタフェースおよび周辺機器（例えばタグリーダなど）を有するマイクロプロセッサまたはコンピュータによって実装することができる。当業者であれば、上記説明に基づいてマイクロプロセッサまたはコンピュータ並びにそれらの対応する例えばタグリーダなどの周辺機器を、それらが本発明の実施形態で機能するように適切にプログラムすることによって本発明の実施形態を実施することができるであろう。従って特許請求の範囲の請求項に定められた本発明のモジュールは、当業者には明らかであろうが、適切なメモリおよび場合によってはデータ交換またはタグの読取りのためのインタフェースなどの周辺機器と共に上記説明で述べたように動作するように適切にプログラムされたマイクロプロセッサまたはコンピュータによって実施することができる。斯かる実施は、当業者にとってみれば上記説明に基づいて困難なく可能であろう。
【０１００】
本発明の実施形態によれば、データ記憶媒体に格納された、または何か他の方法で記録媒体もしくは伝送リンクといった物理的手段によって具現化された、コンピュータ上で実行されたときに上述した本発明の実施形態の通りに動作することを可能にするコンピュータプログラムが提供される。
【図面の簡単な説明】
【０１０１】
【図１】本発明の実施形態に関連して使用することができるタグを有するポスターを示している図である。
【図２】本発明の実施形態によるシステムを示している図である。
【図３】本発明の実施形態に関連して使用することができるタグのコンテンツの例を示している図である。
【図４】本発明の実施形態に関連して使用することができるタグのコンテンツの例を示している図である。
【図５】本発明の実施形態によるシステムのコンポーネントがどのように相互作用するかを説明するための図である。
【技術分野】
【０００１】
本発明はウェブサービスと相互作用（interaction）するための方法および装置に関する。
【背景技術】
【０００２】
ＮＦＣ（Near Field Communication）、ＲＦＩＤ（Radio Frequency Identification）、および２次元視覚的タグなどの多数の技術は、デジタル情報を任意のオブジェクトと関連付けるための方法を提供する。結果として、それらの技術のおかげで、ユーザがそのユーザらの環境内にある任意のオブジェクトを通じて情報にアクセスし、次いでサービスにアクセスするという、あらゆるものが繋がるインターネット（ＩｏＴ：Internet of Things）と広い意味で呼ばれている１つの構想が現実のものとなる。
【０００３】
１Ｄまたは２ＤバーコードリーダからiMode-FeliCa（より詳しくは後述）などのサービス商品に至るまで、これらの技術を活用する多数のソリューションが既に開発されている。しかしこれまでのところ、オブジェクトをインターネット上で利用可能なサービスと動的に関連付ける問題に取り組んだソリューションは存在していない。言い換えると、今日までのところ、適切なリーダで電子タグまたは視覚的タグが強化された任意のオブジェクトに接近し、そのオブジェクトに関連するサービスと自動的に相互作用することは不可能である。現在までの全てのソリューションは、特定のサービスと協働する前にリーダがカスタマズされることを必要とする。
【０００４】
以下、当該分野で周知のいくつかのソリューションについて説明する。
【０００５】
サービスとタグとを関連付けることは、新しいアイデアではない。実際、学術論文や技報の中で多数のソリューションが提案されている。既存の用途および学術的なプロジェクトではサービスとタグとの関係は常にハードコード（hard-coded）されている。このため、既存のシステムでは、タグとサービスとの間に事前に定められたハードコードされた関係が一切存在しない場合には、任意のオブジェクトを使ってサービスを利用することは不可能である。
【０００６】
さらに、従来技術におけるオブジェクトとの相互作用は、常に単一の読取り行為に限定される。具体的には、相互作用は、タグを読取り、その値をサービスに送信することに限定される。それに対し、図２に示すように複数の映画を宣伝する映画ポスターなどのオブジェクトと相互作用するには、複数のタグに付随した値がサービスに送信されることが要求される。
【０００７】
以下、従来技術のアプローチについてより詳細に説明する。
【０００８】
サービスとタグとを結びつける複数の方法が存在している。第１のやり方では、タグはサービスと結びついたアクティブリーダ（active reader）で構成され、ユーザは情報が格納されたカードを保持する。サービスを開始するには、ユーザはカードをリーダの前にさっとかざし、リーダはカードの所定の場所を読取り、読み出したデータをサービスに直接伝達する。最後は、情報がサービスから返信され、応答としてカードに書き込まれうる。このソリューションは非常に有効であり、公共交通機関から建物までのアクセスなど、多くの用途で利用されている。しかし、最悪の場合、ユーザは使用する各サービスごとに異なるカードが必要になるので、これは非常に柔軟性がない。カードが、例えば日本のFeliCa対応の携帯電話機の場合のように複数のアプリケーションで共有されていても、アプリケーションプロバイダは、カードのどの部分を読取りおよび書き込みするかについて合意しておく必要がある。このため複数のプリケーションプロバイダは事前の取り決めなくして同じカードでビジネス展開することは不可能である。さらに、ユーザは、カードが設定していない新たなサービスと連携してカードを利用することができない。なぜなら、これら新しいサービスがカード上のデータを利用することができないからである。また、最悪の場合、新たなサービスが斯かるデータにオーバライドしてカードが利用不能になる可能性がある。
【０００９】
第２のやり方は、ＩＤをオブジェクトと関連付ける視覚的コード（visual code）を利用するものである。この場合、ユーザは、特定のタイプのタグを読み取ってユーザの機器上でサービスをトリガーするための、ユーザの機器に組み込まれたリーダを保持する。例えば、日本では広告に２Ｄ視覚的コードが頻繁に利用されている。携帯電話機上で適切なアプリケーションを使用することによって、ユーザは視覚的コードの写真を撮り、自動的にブラウザに広告会社のウェブページをロードする。この場合、視覚的マーカ（visual marker）で可能なサービスはウェブページのダウンロードだけであるため、その関係がまだハードコードされている。
【００１０】
第３のやり方では、タグとの相互作用と、サービスとの相互作用とは別々に分けられたままである。それでもタグを通じて集められた情報は、サービスに情報を提供するために利用することができる。このソリューションの一例は、非特許文献１で提供されている。このＲＦＩＤを使用するシステムは、オブジェクトまたは人が在室であることを識別するために利用され、それに対し、ウェブサービスはサービスを提供するために利用される。ウェブサービスおよびＲＦＩＤが同じシステムで使用される事実にもかかわらず、それらは２つの非常に異なるタスクを実行し、それらは決して一緒には働かない。ＲＦＩＤは識別にのみ使用され、これを言い換えると、環境内の人とオブジェクトとにあるＲＦＩＤタグが、非常に受動的で、それらが識別するオブジェクトのＭＡＣｉｄを報告するだけであるということを意味する。他方、サービスはＳＯＡ（Service Oriented Architecture）によって記述されるインフラストラクチャ（infrastructure）を通じて呼び出される。実際には、ウェブサービスはＵＤＤＩレジストリに登録され、それらはＵＤＤＩレジストリを通じて発見される。サービスは、直接相互作用し、ＳＯＡサイクルの間においてＮＦＣまたはＲＦＩＤタグは、環境内のオブジェクトと人とに関する識別情報を提供する以外には決して使用されない。
【００１１】
第４のやり方では、多数のサービスクライアント（service client）が電話機に既にロードされうる。そしてサービスとの相互作用を制御する適切なクライアントを選択し、相互作用している間、情報をサービスに伝送するためにＩｏＴタグが利用される。このタイプのアプリケーションの例としては、日本のＮＴＴドコモ社が開発したiMode-FeliCaが挙げられる（非特許文献２参照）。iMode-FeliCaのおかげでＮＴＴドコモ社の顧客は、例えば経常収支または利用明細書、および支払サービスなどの異なるタイプのサービスを利用することができるが、これらのサービスを利用するにはユーザはサービスクライアントの機能を果たすｉアプリ・スタブ（i-appli stub）を最初にダウンロードする必要がある。ｉアプリは携帯電話機のｉモードプラットフォームで動作するＪａｖａ（登録商標）のＤｏＪａダイアレクトで書かれたｉモード用Ｊａｖａ（登録商標）アプリケーションである。ダウンロードされると、ｉアプリは、FeliCaプラットフォームサーバを通じて検証される。そして最後に、検証後、ｉアプリはアクティブになり、FeliCaカードにアクセスすることが可能である。サービスとのあらゆる相互作用は、最初に適切なｉアプリの識別が必要であり、次にサービスクライアントの機能を果たすｉアプリの利用が必要となる。
【００１２】
ＲＦＩＤを使ってサービスをいかに呼び出すかを記述した、オウル（Oulu）大学により開発されたプロジェクトが更に存在している（非特許文献１参照）。その基本的なアイデアは、各ＲＦＩＤが例えば印刷サービスといったサービスのタイプを示すというものである。タグを読み取るとすぐに、携帯電話にロードされたサービス・ミドルウェア・エンジン（service middleware engine）が、選択されたサービスのタイプに対応するサービス・スタブを起動し、サービス・スタブは最もよく適合する利用可能なサービスを探して、そのサービスを開始させる。このシステムは、このスタブが既にロードされておりミドルウェアに利用可能であることを必要とする。例えば、印刷スタブがロードされていなければ、印刷サービスが例え利用可能であるとしても印刷アイコンをスワイプしても何のサービスも始まらない。
【００１３】
iMode-FeliCaなどのソリューションは、銀行取引明細書または交通システムにアクセスするなどの長期にわたって存続し続けるサービスを可能にするのに効果的である。これらの場合、クライアントは一回インスタンス化され、必要であれば検証され、その後はユーザがサービスを必要とするときにそのサービスにアクセスするために使用される。しかし未知のタグ付けされたオブジェクトとの不用意な相互作用には対応していない。
【００１４】
以上の概説は、タグをサービスと関連付ける多くのやり方が存在することを示している。それらは全て、いまのところ、ハードコードされたソリューションをもたらすだけであって、ユーザが未知のサービスと相互作用しようとしてもうまく機能しない。例えば、仮に４本の映画を宣伝する映画ポスターであって、しかもそれらの映画や映画館などについての情報を含み、ユーザがウェブサービスと相互作用して或る特定の映画館において４本の映画のうち１本以上の映画を観るためにチケットを予約したりあるいは購入したりすることを可能にするＲＦＩＤタグが組み込まれた映画ポスターにユーザが遭遇する状況を想定することができる。従来技術では、ユーザが、タグを読取りウェブサービスを呼び出してそれと相互作用するための、サービスに対応するアプリケーションを、携帯電話機にインストールしていない場合には、ユーザは、タグ付きの映画ポスターを使ってウェブサービスを呼び出し、それを利用することは不可能であろう。
【００１５】
サービスとの接続の問題に加えて、ユーザとオブジェクトとの間の相互作用によって別の次元が定義される。通常、ユーザはタグの前に携帯電話機またはカードをさっとかざすまたは視覚的マーカを写真に撮るといった唯一のアクションを行う必要がある。こうしたアクションは、サービスを呼び出し、そのサービスに適切なデータを送信することになる。既に指摘したように、このユーザ相互作用メカニズムは、サービスを呼び出すのに複数のアクションを必要とするような例えば映画ポスターに関連して説明した問題に対処するには十分でない。具体的には、ユーザは、チケットを購入することができる前に、（１）所望の映画、（２）所望の上映時間、（３）所望の映画館、および（４）所望のチケット数を指定する必要がある。
【００１６】
従来技術では、ユーザによる複数のアクションは知られていない。通常使用されるポイント＆クリックではなく例えば投げ縄ツール選択（lasso selection）などのより複雑なジェスチャを用いる方法を提供する提案が存在している（例えば非特許文献３参照）。ユーザは、投げ縄ツールを使って地図から複数の情報を同時に選択することができるが、それでもまだユーザは複数のアクションの代わりに唯一のアクションを行う。タグ付きオブジェクトに関連したアクションへの異なるアプローチは、非特許文献４で研究されている。そこでは“ポインティング”および“スキャニング”といった異なる相互作用技術が調べられている。まだここでもユーザはオブジェクトから情報を収集するのに１回の単一アクションを行う必要がある。
【００１７】
ＮＦＣタグを使ってオブジェクトを拡充し、斯かるオブジェクトを使って例えば映画チケットや公共交通機関の乗り物チケットなどの商品を購入する問題について述べている刊行物が存在している（例えば、非特許文献５、６および７参照）。
【００１８】
上記刊行物は、斯かる購入をサポートする仮想システムのインフラを提示しており、第２に低フィデリティのペーパープロトタイプ（low fidelity paper-prototype）が議論されている。そのアーキテクチャは２つの要素に分割される。１つは相互作用プロキシ（Interaction Proxy）で、これはサービスの構成（Service Composition）、推論（Reasoning）、ユーザインタフェース生成（User Interface Generation）のようなタスクを担う。もう１つは携帯電話機上に存在するユニバーサルクライアント（Universal Client）であり、これはユーザインタフェース（Use Interface）を提供し、ＰＭＬフレームワークを活用したタグの読取りを担う。ＰＭＬは、特にインターネットを通じて物理的環境の監視と制御に使用される、物理的オブジェクトを記述するための一般言語である。その用途としては、在庫追跡、自動取引、サプライチェーン管理、マシン制御およびオブジェクト間通信などが含まれる。ＰＭＬについての詳細はhttp://web.mit.edu/mecheng/oml/index.htmlを参照されたい。
【００１９】
構想を提供したり、システムの要件を記述するほかに、上記論文は、潜在的なユーザが本発明のリポートに提示された能力の一部を有することができる仮想システムに応答することを求められているペーパープロトタイプ（paper-prototype）の実験を議論している。ペーパープロトタイプ（paper-prototype）の実験は、検査対象のシステムのペーパーモックアップ（paper mockups）、基本的にはシステムが存在した場合にユーザが見るであろうスクリーンショットのペーパーリーフレット（paper leaflets）を使用して実行される。それらは、潜在的なユーザの斯かるシステムに対する応答を評価するために使用される。
【非特許文献１】J. Riekki, T. Salminen, I. Alakarppa; Requesting Pervasive Services by Touching RFID Tags; IEEE Pervasive computing, 2006
【非特許文献２】Yoshinaga H., Hattari Y., Sato T., Yoschida M. and Washio S. i-Mode FeliCa; NTT DoCoMo Technical Journal, Vol 6, No 3, Dec 2003 and deployed by NTT DoCoMo in Japan
【非特許文献３】Reilly, D., Welsman-Dinelle, M., Bate, C., and lnkpen, K. (2005). Just Point and Click? Using Handhelds to Interact with Paper Maps. In Proceedings of Mobile HCl 2005
【非特許文献４】Enrico Rukzio, Karin Leichtenstem, Vic Callaghan, Albrecht Schmidt, Paul Holleis, Jeannette Chin; An Experimental Comparison of Physical Mobile Interaction Techniques: Touching, Pointing and Scanning; Eighth International Conference on Ubiquitous Computing (Ubicomp 2006), California, USA. 17-21 September 2006
【非特許文献５】Gregor Broll, Sven Siorpaes, Enrico Rukzio, Massimo Paolucci, John Hamard, Matthias Wagner, Albrecht Schmidt.; Supporting Service Interaction in the Real World; In Permid Workshop 2006 in conjunction with Pervasive 2006, Dublin, Ireland, May 7 2006
【非特許文献６】Enrico Rukzio, Massimo Paolucci, Matthias Wagner, Hendrik H. Berndt, John Hamard, A. Schmidt.; Mobile Service Interaction with the Web of Things; 13th International Conference on Telecommunications (ICT 2006), Funchal, Madeira island, Portugal, May 9-12 2006
【非特許文献７】Sven Siorpaes, Gregor Broll, Massimo Paolucci, Enrico Rukzio, John Hamard, Matthias Wagner, Albrecht Schmidt.; Mobile Interaction with the Internet of Things; In Late Breaking Result and Poster at 4th International Conference on Pervasive Computing (Pervasive 2006), May 7-10, 2006, Dublin, Ireland
【００２０】
上記論文には完全なプロトタイプが提供されているという主張がなされているが、基本的な細部が欠けている。具体的に言えば、
１．サービス記述（service description）がタグとどのように関係しているのかについての議論が全くない。例えば“タグのコンテンツは何か？”あるいは“相互作用プロキシ（Interaction Proxy）またはユニバーサルクライアント（Universal Client）は相互作用するためのプロセスをどのようにして見つけるのか？”といった最も素朴な問いかけも答えられていない。
２．サービスは事前に知られていないために、インフラ全体が移動中に（on the fly）生成される必要があるが、それがどのように生成されるのか、どんな能力が携帯電話機またはプロキシに期待されるかについての議論がまだ全く存在しない。
３．ユーザインタフェースがサービス記述とどのように関係するかについての議論も全く存在しない。もちろん、サービスとの相互作用やユーザとの相互作用は同期する必要があるが、まだそのようなメカニズムは提案されていない。
４．この取り組みの１つの重要な特徴は、複数のユーザアクションがオブジェクトと相互作用するのに必要とされるという点にある。しかしながら、インフラがこのプロセスをどのようにサポートするかについて説明がまだなされていない。インフラは新しいタグが読み取られるごとに再インストールされるのか？あるいはそれは再利用されるか？タグからの値はすぐにサービスに渡されるのか？あるいはそれらは将来の利用のためにどこかに保存されるのか？そして相互作用の結果はどこに保存されるのか？
５．複数のサービスが同じオブジェクトを通じて使用されうるが、まだそのようなケースに対するインフラは提供されていない。
６．何のアルゴリズムも提示されていない。従って、斯かるシステムを再現することができるようなこの分野の専門家またはプログラマがいない。
【００２１】
結局のところ、上記論文は、現実世界のオブジェクトとの相互作用をサポートすることができるシステムの構想とアイデアを提供するが、しかしながら斯かるシステムが実際にどのように働くかについての技術的な詳細は何も提供されていないのである。
【発明の開示】
【００２２】
本発明は、上記課題を解決するため、ユーザの携帯機器と物理的オブジェクトに添付されたタグに対応するウェブサービスとの間の相互作用（interaction）を実行するための方法を提供する。
当該方法は、
ある物理的オブジェクトに付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るステップであって、前記タグ情報が、ウェブサービス記述（description of the Web service：以下ウェブサービス記述という）または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、ステップと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするステップと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするステップと、
相互作用マネジャがある相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中でインデックス付けされるような相互作用マネジャ・レジストリ、または、相互作用マネジャが前記ウェブサービス記述を識別する前記識別子を用いてその中でインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするステップと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするステップと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するステップと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するステップとを含み、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該方法は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するステップと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするステップとを更に含む。
【００２３】
このおかげで、携帯機器はウェブサービスクライアントが携帯機器上にまだインストールされていなくてもタグに対応するウェブサービスと相互作用することができる。
【００２４】
相互作用マネジャ・レジストリを管理することで、相互作用マネジャまたはサービスクライアントをそれが一旦生成されたら再利用することが可能となる。各タグが格納場所の識別子を有する場合、タグが読み取られるごとに、上記チェックを実行することができ、新しい相互作用マネジャを生成すべきかまたは既に存在する相互作用マネジャを使用するべきかを決定することができる。
【００２５】
それゆえ、各生成された相互作用マネジャ（およびそれらの対応するサービスクライアント）ごとに相互作用マネジャ・レジストリを管理することで、システムは読み取られているタグに基づくある特定のウェブサービスに対して対応するサービスクライアント（相互作用マネジャ）が既に生成されているかどうかをチェックすることが可能となる。既に生成されている場合、既に生成された相互作用マネジャが再利用され、まだ生成されていない場合は、最初にサービスクライアントが生成される。
【００２６】
さらに、それを通じて複数の相互作用マネジャがインデックス付けされ、その結果、互いに独立に呼出が可能なこの相互作用マネジャ・レジストリのおかげで、２つの相互作用マネジャをそれらが共に実行を完了するまで独立に使用することが可能となる。
【００２７】
値ストアを管理することで、パラメータの順序に依存しない入力が可能となり、アクションを順序に関係なく実行することができる。
【００２８】
本方法の一態様によれば、前記ウェブサービス記述は、ユーザインタフェースの記述を更に含み、当該方法は、
前記ウェブサービス記述に基づいて、どういった情報がユーザに提供されるかと、どういった情報がユーザから求められるかとを特定するユーザインタフェースを生成するステップを更に含む。
【００２９】
このおかげで、ウェブサービスに属する任意のユーザインタフェースを利用することができる。
【００３０】
本方法の一態様によれば、前記ウェブサービス記述は、
ウェブサービスの動作をどの順序で実行するかを指定する、ウェブサービスのプロトコルの記述を含むものである。
【００３１】
このおかげで、サービスクライアントのプログラム論理がウェブサービスの要件に応じて実行されるように相互作用マネジャを生成することができる。
【００３２】
本方法の一態様によれば、タグは、前記ウェブサービスが入力として使用する値のほかに、前記値のＩＤおよび／または前記ウェブサービス記述の前記格納先へのリファレンスもしくは前記ウェブサービス記述の前記識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含むタグのＩＤと、前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである。
【００３３】
このおかげで、任意の情報を含む任意のタグを利用することができる。
【００３４】
本方法の一態様によれば、タグは前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、
前記アクション識別子は、
前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含み、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる。
【００３５】
斯かる“アクションタグ（action tags）”を使用するおかげで、ユーザが携帯機器でタグを読み取ることで、ウェブサービスによって実行されるべきアクションをトリガーすることができる。
【００３６】
本方法の一態様によれば、前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性をユーザに与え、それによりユーザが前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じてそのデータを入力することができる。
【００３７】
このおかげで、ユーザは接続性が失われたとしても相互作用を継続することができる。さらに、ユーザがユーザインタフェースによる入力の方がより便利だと分かれば、タグから入力を読み取る代わりにユーザインタフェースを選択することができる。
【００３８】
本発明は、上記課題を解決するため、あるユーザの携帯機器とある物理的オブジェクトに付されたタグに対応するウェブサービスとの間の相互作用を実行するための装置を提供する。当該装置は、
ある物理的オブジェクトに添付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るモジュールであって、前記タグ情報が、ウェブサービスの記述（以下、ウェブサービス記述）または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、モジュールと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするモジュールと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするモジュールと、
相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中で相互作用マネジャがインデックス付けされるような相互作用マネジャ・レジストリ、または、前記ウェブサービス記述を識別する前記識別子を用いてその中で相互作用マネジャがインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするモジュールと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするモジュールと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するモジュールと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するモジュールとを備え、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該装置は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するモジュールと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするモジュールとを更に備えるものである。
【００３９】
本装置の一態様によれば、前記ウェブサービス記述は、ユーザインタフェースの記述を更に含みものであり、当該装置は、
前記ウェブサービス記述に基づいて、どういった情報がユーザに提供されるかと、どういった情報がユーザから求められるかとを特定するユーザインタフェースを生成するモジュールを更に備えるものである。
【００４０】
本装置の一態様によれば、前記ウェブサービス記述は、
ウェブサービスの動作をどの順序で実行するかを指定する、ウェブサービスのプロトコルの記述を含むものである。
【００４１】
本装置の一態様によれば、タグは、前記ウェブサービスが入力として使用する値のほかに、前記値のＩＤおよび／または前記ウェブサービス記述の格納先へのリファレンスもしくは前記ウェブサービス記述の識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含むタグのＩＤと前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである。
【００４２】
本装置の一態様によれば、タグは前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、前記アクション識別子は、
前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含み、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる。
【００４３】
本装置の一態様によれば、前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性をユーザに与え、それによりユーザは前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じてデータを入力することができる。
【００４４】
本装置の一態様によれば、タグに含まれる情報は、前記ウェブサービスの記述が格納された格納先へのリンク情報を含むものである。
【００４５】
このおかげで、ウェブサービス記述のダウンロードと、ウェブサービスクライアントの生成とが、そのウェブサービスクライアントが事前にインストールされていなくとも可能である。
【００４６】
本発明は、上記課題を解決するため、コンピュータ上で実行されたときに上記いずれかの方法を実行することを可能にするプログラムコードを含むコンピュータプログラムも提供される。
【発明を実施するための最良の形態】
【００４７】
以下、本発明の実施の最良の形態を添付図面を参照して詳細に説明する。本発明の実施形態は機能が拡充された任意のオブジェクトを（Ｗｅｂ）サービスと関連付けることが可能である。ここで言うウェブサービス（Web service）とは、ＷＳＤＬ文書で記述することができる、インタネット上で利用可能な任意のプログラムを最低限包含するものであると理解されたい。ＷＳＤＬは、ウェブサービス記述言語（Web Service Description Language）である。ＷＳＤＬについての詳細はhttp://www.w3.org/TR/2006/CR-wsdl20-20060327から入手可能な非特許文献［Chinnici R., Moreau J., Ryman A.; Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language; W3C Candidate Recommendation 27 March 2006］とその関連文書を参照されたい。
【００４８】
Ｗ３Ｃ定義によれば、ウェブサービスとは、「標準的なＷｅｂプロトコル、記法および命名法を使用して送られたメッセージを使ってアクセス可能なサービスである（この標準的なＷｅｂプロトコル、記法および命名法は、ＸＭＬプロトコル（またはＸＭＬプロトコルが標準化されるまではＳＯＡＰ）を含むものである）。ウェブサービスは、ウェブサービスインタフェースを定義するためのＷＳＤＬおよびＵＤＤＩなどの補助メカニズムの利用も暗示している場合もある」。
【００４９】
ウェブサービスとは、ネットワーク上の相互動作可能なマシン間の相互作用（interaction）をサポートするように設計されたソフトウェアシステムであると言うこともできる。それは機械処理可能なフォーマット（具体的にはＷＳＤＬ）で記述されるインタフェースを有する。他のシステムは、ウェブサービスと、ＳＯＡＰメッセージを使用するウェブサービス記述によって指示された方法で相互作用する。このＳＯＡＰメッセージは、一般的には、他のＷｅｂ関連標準と併せてＸＭＬシリアライゼーション（XML serialization）でＨＴＴＰを使用して搬送されるものである。
【００５０】
本発明の実施形態の説明を続ける前に、最初に以下の説明で使用される用語について明らかにする。
ＨＴＴＰ（Hypertext Transfer Protocol）：ハイパーテキスト転送プロトコル
ＩｏＴ（Internet of Things）：あらゆるものが繋がるインターネット
ＮＦＣ（Near Field Communication）：近距離無線規格
ＯＷＬ−Ｓ（OWL Service Ontology）：ウェブサービスに関するオントロジーを記述するためのマークアップ言語
ＲＦＩＤ（Radio Frequency Identification）：電波方式認識. 電磁波を使って、物品や人物などの個体識別を自動的に行う技術の総称
ＳＯＡＰ（Simple Access Object Protocol）：ＸＭＬとＨＴＴＰなどをベースとした、他のコンピュータにあるデータやサービスを呼び出すためのプロトコル
ＵＩ（User Interface）：ユーザインタフェース
ＵＲＩ（Universal Resource Identifier）：統一資源識別子
ＵＲＬ（Universal Resource Locator）：統一資源位置子
ＷＳＤＬ（Web Services Description Language）：ウェブサービス記述言語
ＸＭＬ（Extensible Markup Language）：拡張可能マークアップ言語
【００５１】
以下、ユーザの機器がタグによって提供された情報からサービスクライアントと必要に応じてユーザインタフェースとを自動的に生成することを可能にする本発明の実施形態について説明する。生成されたサービスクライアントを使用することで、ユーザはウェブサービスと相互作用することができる。
【００５２】
以下の説明からより明らかになるように、使用されるタグ付け技術のタイプは関係がなく、サービス記述（service description）のアドレスと、例えばそのサービスで実行される動作やそのサービスに送られる値などの追加情報とを提供するような或る種のタグの存在が重要である。
【００５３】
図１おいて、サンプルの用途として本発明を適用することが可能な映画ポスターを示している。ポスターの中心にある４つの絵は異なる映画を示している。また左上にある３つの小さなボックスは映画を上映する映画館、右上にある小さなボックスは上映時間、左下の小さなボックスは取得可能なチケット数、右下の小さなボックスは映画館までの公共交通機関の選択肢が示されている。各ボックスには、ポスターの裏側から関連するＮＦＣタグが貼付されている。こうしてポスターは、入力としてユーザが観たい映画、その映画を上映している映画館、ユーザが希望する上映時間を取得し、出力として映画チケットを発行するサービスと関連付けられる。ＮＦＣ対応携帯電話機を携帯する移動ユーザは、ポスターのタグを読取り、自動的にサービスを呼び出して映画チケットと映画館までの乗り物チケットを購入することができる。
【００５４】
次に、ユーザがウェブサービスと相互作用するための対応するサービスクライアントをユーザの機器にインストールしていない状況を想定する。この問題を解決するため、本発明の実施の一形態によれば、オブジェクトとの相互作用を通じてサービスクライアントが生成され、更にそのオブジェクトはサービスとの相互作用を制御するために使用される。このソリューションは、ウェブサービス技術に基づいている。従って、最初に、サービスによって実行される動作（オペレーション）のワークフローと、それらの動作を実施するために交換されるメッセージと、これらのメッセージのフォーマットと、入出力ポートの仕様と、クライアントとサーバとの間でこれらのメッセージを交換するために使用される転送プロトコルとに関して、サービスの相互作用プロトコルの宣言的仕様が設定される。結果として、サービスとの相互作用を制御するためにクライアントが移動中に生成され、相互作用が完了したらそのクライアントは破棄される。
【００５５】
実施の一形態によれば、タグ付けされたオブジェクトを通じての機器のサービスとの相互作用をサポートするため、図２に示すような以下の３つのコンポーネントが提供される。
１．ユーザの機器がアクセスするインターネットまたはローカルネットワークを通じて到達可能なサービス。このサービスの振る舞いは、例えば、ＷＳＤＬ、ＯＷＬ−ＳまたはＷＳ−ＢＰＥＬなどのウェブサービス記述言語を使って記述される。後者の記述はユーザの機器によっても到達可能でなければならない。
２．視覚的または電子タグで拡充されたオブジェクト。タグは、サービス記述、サービスで実行される動作、および／またはサービスに送られる値に関係している。
３．ユーザがそれを使ってタグを読取り、サービスを呼び出すことができる機器。
【００５６】
ユーザの機器としては、携帯電話機、スマートフォン、あるいは例えばＰＤＡもしくはサブノートパソコンなどの何か他の類似の機器が挙げられる。携帯電話によっては以下に述べる全ての機能を実行するのに必要な計算能力を持たない場合があるため、一部の処理は、例えばオペレータが提供するサーバまたは時としてユーザのホームコンピュータなどへの遠隔の手続き呼出しを使って遠隔サーバで実行されうる。
【００５７】
ユーザ用機器内のコンポーネントは、ユーザ用機器がタグを通じてサービスにアクセスすることを制御するアルゴリズムの３つのメインステップに関与する。これらのコンポーネントを図２に示している。具体的に言えば、タグリーダ（Tag Reader）はアルゴリズムの第１のステップとしてタグを読み取るために当然必要とされる。タグリーダは、タグを読み取るために必要とされるハードウェア−視覚的コードの場合はカメラ、またはＮＦＣもしくはＲＦＩＤリーダ−のほか、そのハードウェアを操作するために必要とされるソフトウェアと、ＡＰＩをシステムの残りの部分に公開するのに必要なソフトウェアとを両方含まなければならない。
【００５８】
アルゴリズムの第２のステップは、タグによって提供された情報を使用して、タグリーダからサービスヘの情報の流れとユーザインタフェースとを管理する責任を負う相互作用マネジャ（Interaction Managers）のインスタンスを生成（instantiate）することである。相互作用マネジャ・レジストリ（Interaction Managers Registry）はこれらの相互作用マネジャを生成し、それらを将来のタグの読取りで使用するために格納する責任を負う。
【００５９】
アルゴリズムの第３のステップは、相互作用マネジャを使用して、タグとサービスとユーザとの間のデータフローを制御することである。斯かるプロセスをサポートするために２つのコンポーネントが必要とされる。第１のコンポーネントは、ウェブサービスとの相互作用に関与する。斯かるコンポーネントは、ウェブサービスとの相互作用をサポートする１セットのライブラリを通じて実行時間に実現される。斯かるライブラリは、多くの場合、ラベル付きのウェブサービススタック（Web Services Stack）であり、斯かるライブラリは、ネットワーク管理と、ＳＯＡＰおよびＨＴＴＰ処理と、ＷＳＤＬ解釈と、ウェブサービスプロトコルの実行のためのＡＰＩとを提供する。ウェブサービススタックの例は、Apache Axis（ws.apache.org/axis/参照）、Ｊ２ＥＥ、Microsoft.Netといったライブラリのほか、ＯＷＬ−Ｓ ＡＰＩ（http://www.mindswap.org/2004/owl-s/api/参照）といったライブラリを含む。第２のコンポーネントは、サービス記述に記述された抽象的ユーザインタフェースを、ユーザに表示される具体的ユーザインタフェースに変換する働きをするＵＩプロセッサである。
【００６０】
これらの３つのステップを使ってユーザはウェブサービスと相互作用することができる。
【００６１】
アルゴリズムの３つのステップを以下の３つのセクションで詳しく説明する。
【００６２】
［タグの読取り］
アルゴリズムの第１のステップは、タグの読取りである。タグは現在利用可能な多くの異なるタグ付け技術のいずれかを用いてコード化することができる。現在利用可能なタグ付け技術としては、ＮＦＣ／ＲＦＩＤからセマコード（記述はhttp://www.semacodes.org参照）を使用する視覚的コード（ビジュアルコード）まで、場合によってはBluetoothまたはＷＬＡＮなどの他の標準に基づく他のタグ付け技術などが挙げられる。タグ付け技術のタイプは、ユーザ用機器がタグの読取りを通じて情報を取得する限りは、本発明ではどんなタイプでも構わない。重要なものはタグの内容である。本発明の実施形態によれば、以下の３つのタイプのタグが存在する。
１．Actionタグ：チケットの予約または商品の購入などのサービスによって実行される動作と関連付けることが可能なタグ。Actionタグは、（ａ）作業が記述されたウェブサービス記述のＵＲＬと、（ｂ）サービス記述内の動作のｎａｍｅまたはＵＲＩとを提供することによって、実行される動作を一意に識別する必要がある。
２．Valueタグ：値に関連するタグ。例えば、観たい映画または上映時間などに関連するタグ。これらのタグは実施の一形態によれば、４つの情報：（ａ）データの値、（ｂ）データのタイプ、（ｃ）データをサービスに送られる情報とユーザに表示される情報との両方と関連付けるために使用されるＩＤ、および（ｄ）サービス記述のある場所を示すＵＲＬ、を含む。
３．Hybridタグ：実行されるアクションと値との両方を表現することによって前の２つのタイプのタグを組み合わせるタグ。
【００６３】
ActionタグとValueタグとの例を、図３と図４とにそれぞれ示している。図３におけるActionタグの例は、サービスによって実行される動作（オペレーション）bookMovieを指定する。そのサービス記述は以下のＵＲＬを参照されたい。
http://perci.medien.ifi.lmu.de:8080/axis/serviceDescription/extendedCinema
【００６４】
図４のValueタグについては、データの値は映画のタイトルGeisyaで与えられ、データのタイプは<abstractType>、ＩＤは<id>movie</id>、そしてサービスＵＲＩは上と同じＵＲＩで与えられる。
http://perci.medien.ifi.lmu.de:8080/axis/serviceDescription/extendedCinema
<abstractType>といった追加のタグは追加の推論に利用することができるようタグの意味的な値（semantic value）を特定するために使用される。タグ<label>および<desc>は、開発者を対象とする文書化に利用される。
【００６５】
斯かるタグを使用して、ユーザ用機器は第１のステップとしてタグの読取りを実行することができる。
【００６６】
［相互作用マネジャの生成および／または検索］
アルゴリズムの第２のステップは、サービスと相互作用するために相互作用マネジャのインスタンスを生成（instantiate）する目的を有する。手短に述べたように、相互作用マネジャは、サービスクライアントとユーザインタフェースを制御するものである。択一的な２つの可能性が存在する。１つの可能性は、サービスは既知で、この場合、携帯電話機は既にそのサービスに対するクライアントを有している。もう１つの可能性は、サービスは未知で、この場合、携帯電話機はサービスおよびユーザインタフェース記述についての利用可能な情報を用いて新たな相互作用マネジャのインスタンスを生成する必要がある。斯かるプロセスは以下のステップによって制御される。
１．相互作用マネジャ・レジストリは、サービス記述のＵＲＬからそのサービスと相互作用するために必要とされる相互作用マネジャへの対応を管理する。
２．タグから読み出したＵＲＬが与えられると、携帯電話機は、相互作用マネジャ・レジストリからそのサービスに対応する相互作用マネジャ、または斯かる相互作用マネジャが存在しない場合には空値を検索する。
３．相互作用マネジャが見つかった場合、手続きは、“サービスとの相互作用の管理”に後述されるように、アルゴリズムはサービスとの相互作用の管理に戻る。
４．相互作用マネジャが見つからない場合、携帯電話機は新たな相互作用マネジャを構築する。そのプロセスは以下のステップ（ａおよびｂ）を含む。
ａ）サービスＵＲＬからサービス記述をロードする。本発明の実施の一形態によれば斯かるサービス記述は３つのコンポーネントを含む。
ｉ）サービス動作（オペレーション）、メッセージ動作およびポートに関するＷＳＤＬ記述。
ｉｉ）動作をどういった順番で実行するかを指定するウェブサービスのプロトコルの記述。プロトコル記述は、例えば、抽象的ＷＳ−ＢＰＥＬまたはＯＷＬ−Ｓなどのウェブサービス記述言語で表現することができる。
ｉｉｉ）サービスの抽象的ユーザインタフェースを記述するＷＳＤＬ記述またはプロトコル記述の拡張。ユーザインタフェースは、例えば、ＸＦｏｒｍｓ（例えばhttp://www.w3.org/MarkUp/Forms/参照）、ＸＵＬ（例えばwww.mozilla.org/projects/xul/参照）またはそれに対するレンダリングエンジン（rendering engine）が存在するという条件で任意の他の言語などの任意の抽象的ユーザインタフェース言語で表現することができる。
ｉｖ）ValueタグのＩＤとウェブサービスが期待する入力との間の関連付け。この関連付けは、拡張性エレメントを使用するウェブサービス記述内、またはサービス記述外に定義されたテーブルとして表現することができる。
ｂ）サービス記述がロードされると、相互作用マネジャのインスタンスの生成（instantiation）が以下のステップと一致するように実行される。
ｉ）サービスのＷＳＤＬ記述とサービスプロトコルとが与えられると、携帯電話機は、サービスクライアントのインスタンスを生成する。このステップは、ウェブサービス・スタック・ライブラリ（Web Services stack libraries）を用いて実行することができる。このステップはウェブサービス・スタック・ライブラリを用いて実行することができ、これは相互作用マネジャの実行に関連して言及したのと同じタイプのライブラリによって実行できる。サービスクライアントは、サービス側で（サービスプロトコルと一致するように）どの動作を呼び出すべきかを決定し、それらの動作を（ＷＳＤＬ記述と一致するように）呼び出すために使用される。
ｉｉ）ユーザインタフェースの記述が与えられると、携帯電話機は、作業についての何の情報がユーザが与えられ、何の情報がユーザから求められるかを指定する具体的ユーザインタフェース（concrete User Interface）を生成することができる。この目的のため、ユーザインタフェース言語に対して任意のレタリングエンジンが可能である。斯かるレタリングエンジンは、ＨＴＭＬタグを表示するＷｅｂブラウザから、ユーザインタフェースを表現するために使用される言語に応じて、例えばＳＵＬＵ（http://sulu.sourceforge.net/参照）／ＸＦｏｒｍエンジン（http://alphaworks.ibm.com/tech/xmlforms参照）までがありうる。
ｉｉｉ）Valueタグの値ストア（value store）が生成される。斯かるストアは、そのキーが値のｉｄであるハッシュテーブルと同程度にシンプルにすることができる。値は、タグの実際の値である。
ｉｖ）３つのコンポーネント、すなわちサービスクライアント、ユーザインタフェース、および値ストアは、一緒にパッケージされ、相互作用マネジャを形成するものである。
５．生成された相互作用マネジャは、オブジェクトから読み出された他のタグを処理するために使用されるように相互作用マネジャレジストリに格納される。相互作用マネジャのインデックス付け（indexing）は、サービス記述のＵＲＬに基づく必要がある。これにより、インスタンスが生成された相互作用マネジャによってそのサービスクライアントがユーザ用機器にいまや生成されているウェブサービスと相互作用するよう設計された別のタグにユーザが遭遇した場合に、それを再び呼び出すことが可能となる。
６．相互作用マネジャは、既に述べたようにサービスとの相互作用を制御するために使用される。
【００６７】
当業者であれば、相互作用マネジャ（またはその一部であるウェブサービスクライアント）の“移動中の（on the fly）”の生成は、ウェブサービスクライアントがその対応するタグとの相互作用が可能になるためにハードワイヤード（つまりハードウェアに組み込まれている）または事前インストールされる必要があった以前のアプローチに対する重要な利点であることは理解されよう。しかしながら、当業者であれば、その目的のためには、携帯機器に相互作用マネジャの“移動中の（on the fly）”の生成を可能にするフレームワークがインストールされなければならないことは理解されよう。これは、携帯電話機に例えば相互作用マネジャの実行に関連して既に言及したライブラリを実装することによって実現することができる。このおかげでユーザインタフェースの生成も可能になる。
【００６８】
本発明の実施形態の機能を実装するために必要なその他のコンポーネントは、標準的なプログラミング技術、例えば携帯電話用アプリケーションを生成するための標準的なプログラミング言語であるＪａｖａ（登録商標）を用いることによって実装することができる。
【００６９】
［サービスとの相互作用の管理］
上記ステップの結果、相互作用マネジャが生成され、それを通じて機器は、サービスと相互作用する。相互作用マネジャのアーキテクチャを図５に示す。この図は、幾分詳しく相互作用マネジャの構造と、その異なるコンポーネント同士の間の関係を図解している。
【００７０】
相互作用マネジャが利用可能になると、相互作用マネジャは、電話機にロードされているサービス記述と合致するようにサービスおよびユーザとの相互作用の制御を担う。一般的に言えば、動作（オペレーション）の起動は携帯電話機側に２つの働きをもたらす。第１の働きは、サービスにデータを送信すること、第２の働きは、サービスからデータを受信することである。その過程で、電話機はユーザに情報を表示し、ユーザが入力する情報を読み取る。
【００７１】
サービスにデータを送るために、携帯電話機は以下のステップを行う必要がある。
１）サービス側でどの動作（オペレーション）を実行すべきかを決定する。作業は以下の場合に実行可能となる。
ａ）それはプロトコル言語で記述された順序における次の作業である。
ｉ）非決定論的選択の場合、携帯電話機は、ＵＩアクションがこの問題に対処するために指定されているのであればユーザに決定を求めるか、または自律的に選択を行うことができる。
ｂ）その動作は、Actionタグを通じてユーザによって選択されている。
ｃ）その動作の入力パラメータが取り得る全ての値は、Valueタグを読取ることによってまたは直接的なユーザ入力によって指定されている。
２．ユーザインタフェースを表示する。ユーザインタフェースは、サービス記述の中の動作に関連する抽象的ユーザインタフェース記述によって指定される。抽象的ＵＩの表示は、以下のステップを含む。
ａ）実行すべき表示アクションを選択する。この動作の結果、データが表示される、またはエラーおよび警告メッセージが表示される。
ｂ）ユーザに表示すべきデータを選択する。この選択はタグから読み出された値のＩＤに基づいている。
ｃ）データを抽象的ユーザインタフェース仕様と合致するように表示する。
ｄ）場合によってはユーザインタフェースによって要求される場合にユーザからの入力を読み取る。ユーザ入力もＩＤが割り当てられ、値ストアに格納される。
３．サービスに送るべきデータを選択する。この選択は値ストア内のデータのＩＤとサービスによって要求される入力との間の関連付けを活用して実行される。
４．サービスクライアントを使ってデータを送信する。ＷＳＤＬ記述を使用するサービスクライアントは、送信データの適切なフォーマットと使用するポートおよびプロトコルを選択する。
【００７２】
第２の働き、すなわちサービスからデータを受信するステップは、サービスからの応答を待機することと、サービスが送ったデータを読み取ることとを含む。具体的には、相互作用マネジャは、
１．サービスクライアントから到来するデータを待機する；
２．そのデータにＩＤを割り当て、値ストアにそれを格納する；
３．ＵＩを起動する；
４．サービスのプロトコル記述における次のステップに進む。
プロセスの実行が完了すると、相互作用マネジャは、ステップ１にループバックして別のプロセスを実行するかどうか、あるいはサービスとの相互作用を一時中断してステップ５に進むかどうかを決定する。ステップ５において相互作用マネジャは、相互作用マネジャレジストリに格納される。
５．サービスとの相互作用を一時中断すると、相互作用マネジャは、相互作用マネジャ・レジストリに保管（アーカイブ）され、実行プロセスは、ステップ１にループバックして別のタグを処理するために待機する、またはプロセスとの相互作用が完了した場合にはそれは破棄される。
【００７３】
次に、図１を参照して、本発明の実施の一形態によるシステムがどのように動作するか、そして映画チケットを購入するためにそれがどのように使用されることがあるかについて具体例を使ってより具体的に説明する。ポスターは、４つの映画を宣伝しており、それはこれらの映画を上映する映画館に対応するタグ（左上のタグＴ１、Ｔ２、Ｔ３）と、ユーザが購入したいと考えるチケット数（左下の１、２、３、４）と、上映時間（右上の午後３時、午後５時、午後７時）と、交通機関の選択肢（右下のバス、地下鉄）とを含んでいる。
【００７４】
本例では、ポスターは、２つのサービス（ａおよびｂ）を提供する。
ａ）映画サービスは、３つの動作を含むプロトコルを有し、それらの動作は、以下に列挙した順序で実行しなければならない。
１．Select_Theater_and_Movie、これは入力として映画館および映画を受信し、出力としてその映画がその映画館で上映しているかどうかを返信する。
２．Select_Time_and_People、これは入力として所望の上映時間とチケット数を受信し、座席が入手可能かどうかを示すスタブを返信する。
３．Payment、これは入力として前のプロセスのスタブとクレジットカード番号とを受信し、チケットを返信する。
ｂ）第２のサービスは、入力としてクレジットカード番号およびチケットのタイプを受信し、出力としてトランスポートチケットを返信する、シンプルなトランスポートサービスである。
【００７５】
ユーザは、ポスターに接近して最初に映画タグの１つに携帯電話機器をかざす。するとタグがユーザ用機器によって読み取られる。このタグはHybridタグであって、値として、映画タイトル−例えばGeisha、サービスのＵＲＬ、およびサービスによって実行されるべき作業−Select_Theater_and_Movie−を含む。
【００７６】
タグを読み取るとすぐに、制御は［相互作用マネジャの生成および／または検索］のところで述べたアルゴリズムに従って相互作用マネジャ・レジストリにシフトする。サービスに対する相互作用マネジャはまだ存在しないので、サービス記述（これはタグ内の対応するＵＲＬに示される）に基づいて新しい相互作用マネジャが生成され、それはその記述のＵＲＬでレジストリにインデックス付けされる。
【００７７】
相互作用マネジャが生成されると、その相互作用マネジャは、サービスとの相互作用の制御を担う。値ペア（movie、Geisha）が値ストアに格納される。movieはＩＤで、Geishaはその値である。まだ何の動作（オペレーション）も実行できないので（動作Select_Theater_and_Movieはまだ１つの入力を欠いている）、相互作用マネジャは、その実行を一時中断して次の入力を待機する。
【００７８】
ユーザの第２のアクションは、購入チケット数を例えば２に設定するタグを読み取ることでよい。サービスに対する相互作用マネジャは既に知っているので、それが再利用される。値ペア（tickets，２）が値ストアに追加される。何の動作も実行可能でないので何も実行されない。
【００７９】
ユーザの第３のアクションは、タグを（タグの上に携帯電話機をさかざすことによって）読み取って映画館を選択することでよい。この場合も同様に適切な相互作用マネジャが検索され、値ペア（theater，Rex）が値ストアに格納される。これで動作Select_Theater_and_Movieが実行できる。というのも動作Select_Theater_and_Movieは、プロトコルにおける次の作業であり、全ての値が利用可能で、しかも対応するActionタグまたはHybridタグがユーザによって選択されているからである。結果として、サービスクライアントは、サービス上の動作を呼び出す。これは応答としてその映画がその映画館で上映中であることを表すBooleanを与える。ユーザインタフェース記述が動作の出力に関連していると仮定すると、それはユーザにその映画が所望の映画館で上映中であることを伝達する。最後に、動作の実行が完了し、次の動作の実行が許可される。
【００８０】
相互作用を継続して、ユーザは上述のプロセスと同様のプロセスをトリガーする他のタグを選択することができる。すなわち、タグが既知のサービスと関係しているときは適切な相互作用マネジャが検索される。代わりにそれらが新しいサービスに関係するとき、例えば初めて交通機関タグが読み出される場合には、新しい相互作用マネジャが生成される。最後に、Payment動作といった動作がユーザ入力を要求し、それらは、ユーザに情報を明示的に求めるようなユーザインタフェースをトリガーすることができる。
【００８１】
サービスのプロトコルが終了し、チケットの購入が完了すると、対応する相互作用マネジャは、もはや必要がなくなるので破棄される。ユーザが更なるチケットを購入するために同じポスターを利用しようとする場合には、そのチケット購入プロセスを制御するために新しい相互作用マネジャのインスタンスが生成される。しかしながら、ユーザ用機器の処理能力とメモリ能力とに応じて、相互作用マネジャを、例えば少なくともしばらくの間、ユーザ用機器に保持しておくことも可能である。
【００８２】
本発明の実施の一形態によれば、サービス記述を通じて与えられるユーザインタフェースは、オブジェクトの代わりに使用することができる。本実施形態の背後にあるアイデアは、次のようなものである。図１に示されたポスターのようなオブジェクトは、ユーザがそのおかげで４つの映画の中から１つの映画、３つの上映時間から１つの上映時間などを選択することができる１セットのメニューと見なすことができる。ユーザがオブジェクトとの相互作用を開始し、インタフェースをロードするとき、オブジェクトによって提示されたのと同じ選択肢がユーザインタフェースにも提示される。その目的のため、（物理的タグに格納された）対応するデータは、サーバのどこかに格納しておくこともでき、ウェブサービス記述およびユーザインタフェース記述がダウンロードされるときに、ダウンロードすることができる。結果、携帯電話機のユーザは、物理的オブジェクトとの相互作用を（例えば映画館を選択するために、電話機を対応するタグにかざすことによって）継続するか、あるいはオブジェクトから離れて、携帯電話機のスクリーンとの相互作用を（例えば、対応するラジオボタンを選択することによって）継続するかを選択する。この特徴は、ユーザがオブジェクトとの相互作用をそれが終了する前に例えば接続性ロスその他の理由から中断する必要がある場合に非常に有用となりうる。
【００８３】
一般的に、これは以下の２つの側面を活用して遂行することができる。
ａ．ユーザインタフェースは、物理的オブジェクトを通じてユーザに全ての選択肢を提供するものとする。
ｂ．ユーザインタフェースは、オブジェクトによって転送される全ての隠されたデータをユーザに知られることなく提供するものとする。
【００８４】
最初の要件（ａ）は、ユーザインタフェースが忠実にそれがそこから取得されたオブジェクトを表現することを保証するために必要とされる。二番目の要件（ｂ）は、サービスクライアントがサービスと相互作用するために必要とされる全ての情報を持つことを保証するために必要とされる。
【００８５】
これは、実際には、同じオブジェクトに対して２つのインタフェース−１つはタグを通じての物理的インタフェース、もう１つは携帯電話機のスクリーンを通じての仮想インタフェース−が存在することを意味する。仮想インタフェースは、相互作用マネジャのインスタンスが生成される際にウェブサービスクライアントと一緒に生成され、それに必要な対応するデータは、同じサーバ上に格納することができ、さらに、インタフェースが生成されるときにダウンロードすることができる。
【００８６】
上記システムは、サービスをオブジェクトそのものではなく、オブジェクトに含まれるタグと関連付ける。結果、オブジェクトは、非常に異なるサービスと関連付けられたタグを含むことができる。例えば、図１に示されたポスターは、主に映画の宣伝とチケットの販売に関するものであるが、それだけではなく乗り物チケットの購入も提案している。映画チケットは、映画館が提供するサービスを使って購入される。一方、乗り物チケットは、地域の公共交通機関運営会社が提供するサービスによって提供される。
【００８７】
複数のサービスとの相互作用をサポートするには追加のメカニズムは一切必要ない。ユーザは、映画チケットの購入を開始してよく、映画チケットサービスの相互作用マネジャが提供される。このサービスとの相互作用を終了する前に、ユーザはトランスポートチケットの購入を決める場合がある。トランスポートサービスに対して今度はトランスポートタグにタッチすると、別の相互作用マネジャが提供される。２つの相互作用マネジャはそれらが共に実行を完了するまで独立に使用される。
【００８８】
複数の相互作用マネジャがインデックス付けでき、それによりそれらを互いに独立に呼び出すことが可能になる相互作用マネジャ・レジストリにより、ユーザは２つの相互作用マネジャをそれらが両方とも実行を完了するまで独立に使用することが可能となる。２つの相互作用マネジャは、例えばそれらの間で切り替えが可能である。例えば、ある特定の相互作用マネジャがある時にアクティブになっている場合がある。相互作用マネジャ・レジストリにおける検索（lookup）に基づき別の相互作用マネジャに対応するタグが読み出された場合、アクティブになっているこの他の相互作用マネジャへの切替が行われ、対応するアクションが実行される。このようにして、複数の相互作用マネジャはそれら全ての実行が完了するまで独立に使用される。
【００８９】
前述の説明では、タグ（好ましくは各任意のタグ）は、ウェブサービスを記述する対応するウェブサービス記述の格納先へのリファレンス（reference）を含む。しかしながら、実施の一形態によれば、タグそれ自体がタグ上に十分な空き領域があれば、完全なウェブサービス記述を含むことができる。斯かる場合、タグ読取り動作（オペレーション）は、ＵＲＬといったリファレンスで特定される遠隔の格納先を参照することなく、この完全なウェブサービス記述を直接読み出すことができる。
【００９０】
実施の一形態において、斯かる場合には、タグは好ましくはウェブサービス記述を識別する識別子（ＩＤ）も含み、このおかげで相互作用マネジャ・レジストリは、このＩＤに基づいて既に存在する相互作用マネジャにインデックス付けことができる。タグが読まれた場合、相互作用マネジャ・レジストリは（既に述べたように）、対応する相互作用マネジャが既に存在するかどうか、または最初にそれが生成される必要があるかどうかをチェックする。
【００９１】
実施の一形態によってサポートされる特徴は、ユーザのアクションのサービスのプロトコルからの独立性である。以下、それについてより詳細に説明する。
【００９２】
実施の一形態によれば、相互作用マネジャは、図２に示すように、タグから読み出されたデータを格納するための値ストアを含んでいる。この値ストアは、相互作用マネジャを生成するときに例えばタグから読み出されたデータを格納するための所定の記憶領域を確保または保管することによって、生成または管理することができる。
【００９３】
タグから読み出された任意のデータは、斯かる値ストアに、好ましくはウェブサービス記述の格納先へのレファレンスまたはウェブサービス記述の識別子と一緒に格納することができる。これにより、このデータがパラメータ（例えば、チケット購入サービスの場合、ユーザが映画を観に行きたいと思う映画館）と解釈される実際のサービスが呼出または開始されていなくとも、このデータを格納し、その後、このデータを正しく識別することが可能となる。続いて映画館を識別するデータが値ストアに格納され、後に、ユーザが映画チケットを購入するために（例えば対応するActionタグの上をタグリーダをかざすことによって）実際のウェブサービスを開始する場合に、このとき呼び出されたサービスに対するパラメータ−例えば本例ではユーザによって既に選択された映画館−を既に含んでいるかどうかについて値ストアが検索される。
【００９４】
ユーザは、作業の通常の方法とは対照的に、パラメータ値を、それらを実際に使用しなければならいアプリケーションが開始される前に入力することができる。これは、これらのデータについて値ストアを管理（メンテナンス）し、これらのデータを値ストアにこれらのデータがパラメータとしての機能を果たすサービスのウェブサービス記述の識別子またはウェブサービス記述の格納先へのリファレンスと一緒に格納することによって可能になる。ウェブサービスが実行されると、それは値ストアを調べて、関係のあるパラメータが既に値ストアに格納されており、使用できるかについてチェックすることができる。
【００９５】
このようにして、パラメータの入力は順序に依存しないが、ある程度までは時間と場所にも依存しない。ユーザは例えば、正午前、中央駅でポスターの図１におけるタグＴ２を選択することによって映画館を選択し、次にユーザはその他の入力を完了する前に中央駅を後にしなければならず、同じポスターが貼られた別の駅でその他の関係するパラメータ（チケット数など）を選択することによってこの入力を完了し、そして対応するActionタグを選択することによってウェブサービスを開始することができる。
【００９６】
斯かる実施形態は、ウェブサービスとの相互作用がそれによって可能なフレキシビリティを改善する。異なるウェブサービスをそれらが実質上同時に実行されるように互いに独立に呼び出すことが（上述した相互作用マネジャ・レジストリのおかげで）可能であるばかりか、タグに対応するデータの入力も順序に関係なく入力することが可能である。従来技術のシステムでは、プログラムフローは、ある特定の入力が要求された場合にはこの入力が受信されるまで手続きが停止するようになっている必要があるが、本発明の実施形態は、タグを読み取ることでデータを入力するよりフレキシブルなやり方を実現することができる。その目的のため、タグから読み出されたデータを格納することができる値ストアが提供される。値ストアにはそのデータだけでなく、ウェブサービス記述の格納先へのリファレンスまたはウェブサービス記述の識別子も格納される。
【００９７】
このように、こうして格納されたデータを後で使用することが可能になり、プログラムフローで指定された順序でデータを読み出すことはもはや重要ではない。ウェブサービスが始まる前でもタグを読み取るも可能になる。ウェブサービスが始まったら、それは値ストアを検索してプログラムフローに従って、いま必要なデータが値ストアに既に存在しているかどうかチェックする。
【００９８】
このように、値の入力が順序に依存しなくなるだけでなく、ある程度までは場所にも依存しなくなる。なぜなら、サービスは、異なる場所で、そのサービスを実行するにはまだ欠けているデータを持つタグを読み取ることによって継続することができるからである。
【００９９】
当業者であれば、上述した実施形態は、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアの組み合わせによって実施することができることは理解されるだろう。本発明の実施形態に関連して説明したモジュールおよび機能は全体的または部分的に、本発明の実施形態に関連して説明された方法に従って働くように適切にプログラムされており適切なインタフェースおよび周辺機器（例えばタグリーダなど）を有するマイクロプロセッサまたはコンピュータによって実装することができる。当業者であれば、上記説明に基づいてマイクロプロセッサまたはコンピュータ並びにそれらの対応する例えばタグリーダなどの周辺機器を、それらが本発明の実施形態で機能するように適切にプログラムすることによって本発明の実施形態を実施することができるであろう。従って特許請求の範囲の請求項に定められた本発明のモジュールは、当業者には明らかであろうが、適切なメモリおよび場合によってはデータ交換またはタグの読取りのためのインタフェースなどの周辺機器と共に上記説明で述べたように動作するように適切にプログラムされたマイクロプロセッサまたはコンピュータによって実施することができる。斯かる実施は、当業者にとってみれば上記説明に基づいて困難なく可能であろう。
【０１００】
本発明の実施形態によれば、データ記憶媒体に格納された、または何か他の方法で記録媒体もしくは伝送リンクといった物理的手段によって具現化された、コンピュータ上で実行されたときに上述した本発明の実施形態の通りに動作することを可能にするコンピュータプログラムが提供される。
【図面の簡単な説明】
【０１０１】
【図１】本発明の実施形態に関連して使用することができるタグを有するポスターを示している図である。
【図２】本発明の実施形態によるシステムを示している図である。
【図３】本発明の実施形態に関連して使用することができるタグのコンテンツの例を示している図である。
【図４】本発明の実施形態に関連して使用することができるタグのコンテンツの例を示している図である。
【図５】本発明の実施形態によるシステムのコンポーネントがどのように相互作用するかを説明するための図である。
【特許請求の範囲】
【請求項１】
あるユーザの携帯機器とある物理的オブジェクトに付されたタグに対応するウェブサービスとの間の相互作用を実行するための方法であって、
ある物理的オブジェクトに付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るステップであって、前記タグ情報が、ウェブサービス記述または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、ステップと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするステップと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするステップと、
相互作用マネジャがある相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中でインデックス付けされるような相互作用マネジャ・レジストリ、または、相互作用マネジャが前記ウェブサービス記述を識別する前記識別子を用いてその中でインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするステップと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするステップと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するステップと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するステップとを含み、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該方法は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するステップと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするステップと
を更に含む、方法。
【請求項２】
前記ウェブサービス記述は、ユーザインタフェースの記述を更に含み、当該方法は、
前記ウェブサービス記述に基づいて、どういった情報が前記ユーザに提供されるかと、どういった情報が前記ユーザから求められるかとを特定するユーザインタフェースを生成するステップを更に含む、請求項１に記載の方法。
【請求項３】
前記ウェブサービス記述は、
前記ウェブサービスの動作をどの順序で実行するかを指定する、前記ウェブサービスのプロトコルの記述を含むものである、請求項１または２に記載の方法。
【請求項４】
タグは、前記ウェブサービスが入力として使用する値のほかに、該値のＩＤおよび／または前記ウェブサービス記述の前記格納先へのリファレンスもしくは前記ウェブサービス記述の識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含む前記タグのＩＤと、前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
タグは、前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、前記アクション識別子は、
前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含むものであり、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性を前記ユーザに与え、それにより、前記ユーザが、前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じて前記データを入力することができるようにすることを含む請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
あるユーザの携帯機器とある物理的オブジェクトに添付されたタグに対応するウェブサービスとの間の相互作用を実行する装置であって、
ある物理的オブジェクトに添付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るモジュールであって、前記タグ情報が、ウェブサービス記述または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、モジュールと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするモジュールと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするモジュールと、
相互作用マネジャがある相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中でインデックス付けされるような相互作用マネジャ・レジストリ、または、相互作用マネジャが前記ウェブサービス記述を識別する前記識別子を用いてその中でインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするモジュールと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするモジュールと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するモジュールと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するモジュールとを備え、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該装置は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するモジュールと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするモジュールと
を更に備えるものである、装置。
【請求項８】
前記ウェブサービス記述は、ユーザインタフェースの記述を更に含み、当該装置は、
前記ウェブサービス記述に基づいて、どういった情報が前記ユーザに提供されるかと、どういった情報が前記ユーザから求められるかとを特定するユーザインタフェースを生成するモジュールを更に備えるものである、請求項７に記載の装置。
【請求項９】
前記ウェブサービス記述は、
前記ウェブサービスの動作をどの順序で実行するかを指定する、前記ウェブサービスのプロトコルの記述を含むものである、請求項７または８に記載の装置。
【請求項１０】
タグは、前記ウェブサービスが入力として使用する値のほかに、該値のＩＤおよび／または前記ウェブサービス記述の格納先へのリファレンスもしくは前記ウェブサービス記述の識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含む前記タグのＩＤと、前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである、請求項７乃至９のいずれか一項に記載の装置。
【請求項１１】
タグは前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、前記アクション識別子は、
前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含むものであり、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる、請求項７乃至１０のいずれか一項に記載の装置。
【請求項１２】
前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性を前記ユーザに与え、それにより前記ユーザが、前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じて前記データを入力することができるようにすることを備えるものである、請求項７乃至１１のいずれか一項に記載の装置。
【請求項１３】
コンピュータ上で実行される際に請求項１乃至６のいずれか一項に記載された方法を実行するプログラムコードを含むコンピュータプログラム。
【請求項１】
あるユーザの携帯機器とある物理的オブジェクトに付されたタグに対応するウェブサービスとの間の相互作用を実行するための方法であって、
ある物理的オブジェクトに付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るステップであって、前記タグ情報が、ウェブサービス記述または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、ステップと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするステップと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするステップと、
相互作用マネジャがある相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中でインデックス付けされるような相互作用マネジャ・レジストリ、または、相互作用マネジャが前記ウェブサービス記述を識別する前記識別子を用いてその中でインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするステップと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするステップと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するステップと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するステップとを含み、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該方法は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するステップと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするステップと
を更に含む、方法。
【請求項２】
前記ウェブサービス記述は、ユーザインタフェースの記述を更に含み、当該方法は、
前記ウェブサービス記述に基づいて、どういった情報が前記ユーザに提供されるかと、どういった情報が前記ユーザから求められるかとを特定するユーザインタフェースを生成するステップを更に含む、請求項１に記載の方法。
【請求項３】
前記ウェブサービス記述は、
前記ウェブサービスの動作をどの順序で実行するかを指定する、前記ウェブサービスのプロトコルの記述を含むものである、請求項１または２に記載の方法。
【請求項４】
タグは、前記ウェブサービスが入力として使用する値のほかに、該値のＩＤおよび／または前記ウェブサービス記述の前記格納先へのリファレンスもしくは前記ウェブサービス記述の識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含む前記タグのＩＤと、前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
タグは、前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、前記アクション識別子は、
前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含むものであり、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性を前記ユーザに与え、それにより、前記ユーザが、前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じて前記データを入力することができるようにすることを含む請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
あるユーザの携帯機器とある物理的オブジェクトに添付されたタグに対応するウェブサービスとの間の相互作用を実行する装置であって、
ある物理的オブジェクトに添付されたタグに含まれるタグ情報を前記携帯機器のタグ読取りモジュールを使って読み取るモジュールであって、前記タグ情報が、ウェブサービス記述または該ウェブサービス記述が格納された格納先へのリンク情報を含むものである、モジュールと、
前記携帯機器を使って前記格納先にアクセスし、前記ウェブサービス記述をダウンロードするモジュールと、
前記ダウンロードされたウェブサービス記述に基づいてサービスクライアントを含む相互作用マネジャを生成して、前記ユーザの前記携帯機器が、前記タグに対応する前記ウェブサービスと相互作用することができるようにするモジュールと、
相互作用マネジャがある相互作用マネジャに対応する前記ウェブサービス記述が格納された格納先へのリンク情報によってその中でインデックス付けされるような相互作用マネジャ・レジストリ、または、相互作用マネジャが前記ウェブサービス記述を識別する前記識別子を用いてその中でインデックス付けされるような相互作用マネジャ・レジストリを保持して、対応する相互作用マネジャが既に存在するか否かを判定することができるようにするモジュールと、
タグが読み取られた場合には、前記相互作用マネジャ・レジストリにおいて、前記タグ情報の中の前記リンク情報によって識別される前記ウェブサービス記述の前記格納先を調べて、対応する相互作用マネジャが前記携帯機器の中に既に存在するかどうかをチェックするモジュールと、
前記相互作用マネジャが既に存在する場合には、前記相互作用マネジャを用いて前記ウェブサービスとの相互作用を実行するモジュールと、
前記相互作用マネジャがまだ存在しない場合には、前記格納先にアクセスして前記ウェブサービス記述をダウンロードし、前記相互作用マネジャのインスタンスを生成するモジュールとを備え、
２つの相互作用マネジャは、それらが共に実行を完了するまでは独立に使用することが可能であり、
当該装置は、
各タグが前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の識別子を含み、斯かるタグから読み出されたデータを格納する値ストアを管理するモジュールと、
タグ上に含まれたデータを前記ウェブサービス記述の前記格納先への前記リファレンスまたは前記ウェブサービス記述の前記識別子と一緒に前記値ストアに格納して、前記ウェブサービスは、該ウェブサービスが開始されると、前記値ストアを検索して関係のあるパラメータが前記値ストアに既に格納されており使用することができるかどうかをチェックし、それにより前記パラメータの入力が順序に依存しないようにすることができるようにするモジュールと
を更に備えるものである、装置。
【請求項８】
前記ウェブサービス記述は、ユーザインタフェースの記述を更に含み、当該装置は、
前記ウェブサービス記述に基づいて、どういった情報が前記ユーザに提供されるかと、どういった情報が前記ユーザから求められるかとを特定するユーザインタフェースを生成するモジュールを更に備えるものである、請求項７に記載の装置。
【請求項９】
前記ウェブサービス記述は、
前記ウェブサービスの動作をどの順序で実行するかを指定する、前記ウェブサービスのプロトコルの記述を含むものである、請求項７または８に記載の装置。
【請求項１０】
タグは、前記ウェブサービスが入力として使用する値のほかに、該値のＩＤおよび／または前記ウェブサービス記述の格納先へのリファレンスもしくは前記ウェブサービス記述の識別子を更に含むものであり、
前記ウェブサービス記述は、前記ウェブサービスが入力として使用する値を含む前記タグのＩＤと、前記ウェブサービスが期待する対応する入力との間の関連付けを含むものである、請求項７乃至９のいずれか一項に記載の装置。
【請求項１１】
タグは前記ウェブサービスによって実行されるアクションを識別するアクション識別子を含むものであり、前記アクション識別子は、
前記ウェブサービス記述の前記格納先へのリファレンスまたは前記ウェブサービス記述の前記識別子と、
前記ウェブサービス記述内で前記アクションを識別する識別子とを含むものであり、
前記携帯機器で前記タグを読み取ることによって、前記アクション識別子によって識別されたアクションの実行がトリガーされる、請求項７乃至１０のいずれか一項に記載の装置。
【請求項１２】
前記ユーザインタフェースは、タグ付けされたオブジェクトから読み出せるデータを入力する可能性を前記ユーザに与え、それにより前記ユーザが、前記タグ付けされたオブジェクトからまたは前記ユーザインタフェースを通じて前記データを入力することができるようにすることを備えるものである、請求項７乃至１１のいずれか一項に記載の装置。
【請求項１３】
コンピュータ上で実行される際に請求項１乃至６のいずれか一項に記載された方法を実行するプログラムコードを含むコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００８−１６５７３６（Ｐ２００８−１６５７３６Ａ）
【公開日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【外国語出願】
【出願番号】特願２００７−２７２７９６（Ｐ２００７−２７２７９６）
【出願日】平成１９年１０月１９日（２００７．１０．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ｉモード
２．ｉ−ａｐｐｌｉ
３．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【出願番号】特願２００７−２７２７９６（Ｐ２００７−２７２７９６）
【出願日】平成１９年１０月１９日（２００７．１０．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ｉモード
２．ｉ−ａｐｐｌｉ
３．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]