JP2013502013A - イベントトリガされたサーバサイドマクロ - Google Patents

Abstract

コンピュータマクロを管理するコンピュータ実装方法が開示される。この方法は、インターネットアクセスが可能なホスト型コンピュータシステムでコンピュータマクロに関するコードを格納すること、および、格納されたコードをホスト型コンピュータシステム上のユーザアカウントに関連付けることを含む。この方法は、ユーザアカウントに関連付けられたユーザが現在ホスト型コンピュータシステム上でアクティブであるかどうかに関係なく、ホスト型コンピュータシステムを使用して、マクロを対象としているものとして定義付けられるトリガイベントを自動的に識別することを含む。さらにこの方法は、マクロ結果を生成するために、ホスト型コンピュータシステム上で実行中のアプリケーションを使用してマクロを実行すること、および、マクロ結果をホスト型コンピュータシステム上に格納することを含む。

Description

本書は、電子コンテンツのネットワークベースの送達に関する。

本出願は、米国特許法第119条(3)の下で、参照によりその開示が本明細書に組み込まれている、2009年8月13日に出願したEVENT-TRIGGERED SERVER-SIDE MACROSという名称の米国特許出願第12/540846号の優先権を主張するものである。

マクロは、1つまたは複数のコンピュータアプリケーション内部で、それらアプリケーションとの拡張された自動相互作用性を提供するために実行可能な命令のセットであり、マクロの少なくとも一部は、場合によってはアプリケーションのユーザによって手動で実行可能なステップを表す。たとえばマクロは、スプレッドシートアプリケーション内のある数から値を計算し、この値を、デスクトップコンピュータ上の関連するワードプロセッシングアプリケーションへとコピーするように、作成可能である。ユーザは、「ホットキー」組み合わせをマクロに割り当て、ユーザがこのホットキー組み合わせを押すことによって、マクロが容易に実行できるようにすることができる。他の例として、マクロは、コンピューティングデバイスのユーザによってより容易に見られるように、(たとえば配偶者、クライアント、または上司からの)ある電子メッセージの重要性を引き上げるようにも作成可能である。良く知られているマクロベースシステムの1つが、MICROSOFT OFFICE生産性向上スイート用のVisual Basic for Applicationsである。

本書は、しばしば「クラウド」と呼ばれる、ホスト型コンピューティングシステム(hosted computing system)においてマクロを作成および使用するためのシステムおよび技法について論じる。マクロは、クライアントデバイスからではなく、マクロサーバサブシステムから格納および実行することが可能であり、したがって、すべての認定されたユーザが、ネットワーク上にあり、その証明を提供できる限り、多くの場所からマクロにアクセス可能であるため、マクロをユーザ間で容易に共有することができる。

加えてマクロは、ホスト型コンピューティングシステムによって提供される、またはホスト型コンピュータシステムとは別の第3者システムからの、いくつかのアプリケーションおよびサービスに容易にアクセス可能である。こうしたサービスは、様々なユーザの位置(たとえば彼らのモバイルデバイス上のGPSなどから決定される)に関する情報を提供するサービス、ニュース番組および気象番組を提供するサービス、ならびに他のこうしたサービスを、含むことができる。アプリケーションは、たとえば電子メールおよび他のメッセージングアプリケーション、スプレッドシートおよびワードプロセッサなどの生産性向上アプリケーション、地図アプリケーション、ならびに、(ユーザによってアクセス可能であり、マクロからのカスタマイズされた出力を提供するためにユーザによる開発さえ可能な)単一の表現で共に提示可能な様々なアプリケーションのマッシュアップなどを、含むことができる。

アプリケーションは、ウェブブラウザを使用して表示される1つまたは複数のウェブページを介してユーザに提示可能である。システムは、マクロの記録も提供可能であり、ここでユーザはマクロレコーダを呼び出すことが可能であり、レコーダはコンピュータ上でのユーザのアクションを追跡し、それらのアクションをマクロコードに変換することが可能であるため、結果としてユーザが後にマクロを実行する場合に自動的にアクションを反復することが可能である。

あるマクロは、ユーザがホスト型システムにログインしていない場合を含む、ユーザが特定のマクロによって対処されるアプリケーションと相互作用していない場合であっても発生するイベントから、呼び出すことができる。特に、マクロがサーバサブシステム上で格納および実行される場合、マクロによって対処されるシステム全体において特定のイベントを監視するために、サーバサブシステムを確立することができる。次に、こうしたイベントがマクロの呼び出しをトリガすることが可能であり、マクロはサーバサブシステム上で実行可能である。

マクロは、システム上のサービスまたは第3者サービスにアクセス可能である。システム上のサービスは、あるユーザ構成可能セキュリティがアクセスに適用された状態で、システムに登録された特定のユーザに対応するデータストアへのアクセス権を付与することができる。たとえばマクロは、電子メールメッセージがユーザのアカウントに着信したことに応答して呼び出し可能であり、次に、(たとえば、ユーザが、それらすべての着信メッセージからの件名欄を示すスプレッドシートを自動的に作成するように)メッセージからの情報を、ユーザのアカウントに割り当てられたスプレッドシートにコピーすることができる。こうしたマクロは、位置サービス、気象関係ウェブサイトのデータなどの、1つまたは複数のサービスもチェックするか、あるいは、マクロに関するデータを収集し、マクロを使用して意思決定するために、ホスト型システムまたはホスト型システム外部のシステムのリソースを使用する、他のアクションを起こすことができる。次にマクロは、スプレッドシート内にメッセージ情報を配置すること、ユーザのアカウントに対応する番号に電話をかけること、または他のこうしたアクションなどによって、ユーザがシステム内でアクティブ状態である必要なしに(たとえば、ホスト型システムにログインしていないか、またはユーザのクライアントコンピューティングデバイスで)、アクションを起こすことができる。

マクロがアクセス可能な第3者サービスは、SOAPサービス、または、サービスを提供するドメインとは別のドメインからアクセス可能であり、インターネットを介して情報を共有するための周知のメカニズムを提供する、他の同様のサービスを含むことができる。たとえば第3者サービスプロバイダは、最新の気象データを集めること、および、要求時に他のサービスがこのデータを使用できるようにすることが可能である。

一実装形態では、コンピュータマクロを管理するコンピュータ実装方法が開示される。この方法は、インターネットアクセスが可能なホスト型コンピュータシステムでコンピュータマクロに関するコードを格納すること、格納されたコードをホスト型コンピュータシステム上のユーザアカウントに関連付けること、および、ユーザアカウントに関連付けられたユーザが現在ホスト型コンピュータシステム上でアクティブであるかどうかに関係なく、ホスト型コンピュータシステムを使用して、マクロを対象としているものとして定義付けられるトリガイベントを自動的に識別することを、含む。この方法は、マクロ結果を生成するために、ホスト型コンピュータシステム上で実行中のアプリケーションを使用してマクロを実行すること、および、マクロ結果をホスト型コンピュータシステム上に格納することも含む。さらにこの方法は、マクロの結果をユーザに通知する、ユーザアカウントに関連付けられた通信アドレスへのメッセージを生成することも含むことができる。

いくつかの態様では、トリガイベントは、ユーザアカウントに向けて送られるデジタル通信の着信を含む。またトリガイベントは、アカウントホルダ(accountholder)に関連付けられたコンピュータデバイスユーザの位置の決定を含むこともできる。さらにこの方法は、マクロをホスト型コンピュータシステムの登録ユーザに関連付けること、および、登録ユーザによって識別されたアクセス制限に従って、ホスト型コンピュータシステムの他のユーザがマクロを使用できるようにすることを、含むことができる。加えてマクロには、複数の異なるユーザアカウントからのトリガイベントに応答して、アクセスすることができる。

さらに他の態様では、この方法は、ホスト型コンピュータからリモートの複数の異なるクライアントコンピュータ上で実行中の複数のアプリケーションからマクロを実行する旨の要求を受信すること、位置からの各要求に対してホスト型コンピュータシステム上でマクロを自動的に実行すること、および、マクロの実行に応答して、複数のアプリケーションのうちのそれぞれのアプリケーションにマクロの実行結果を提供することを、さらに含む。マクロを実行することは、ホスト型コンピュータシステムによって提供された複数の異なるホスト型サービスへの呼び出しを行うことを含むことができる。また、マクロを実行することは、ホスト型コンピュータシステムとは無関係の第3者情報プロバイダによって提供されるウェブサービスへの呼び出しを行うことを含むこともできる。加えてこの方法は、ホスト型コンピュータシステム上で実行中の第1のアプリケーションによって生成された情報を異なるフォーマットに変換することと、変換された情報をホスト型コンピュータシステム上で実行中の第2のアプリケーションに提供することと、ホスト型コンピュータシステムに登録された複数の異なるユーザに関する複数の異なるアカウントに、マクロの実行結果を自動的に提供することとを、含むことができる。

他の実装形態では、ホスト型コンピュータシステム上でマクロを実行するためのコンピュータ実装システムが開示される。システムは、ホスト型コンピュータシステムから動作可能な複数のホスト型アプリケーションと、それぞれがホスト型コンピュータシステム上のユーザアカウントに割り当てられ、それぞれが複数のホスト型アプリケーションのうちの少なくとも1つによって実行されることになる一連のアクションを定義付ける、複数のマクロを格納するマクロデータストアと、システム内のトリガイベントを識別し、複数のマクロのうちの1つに対応する識別されたトリガイベントに応答して、複数のマクロのうちの1つの実行を開始する、スケジューリングモジュールを動作させるためのプロセッサと、を備える。システムは、マクロの結果をユーザに通知する、ユーザアカウントに関連付けられた通信アドレスへのメッセージを生成するようにプログラミングされたインターフェースを動作させる、プロセッサも含むことができる。

いくつかの態様では、トリガイベントは、ユーザアカウントに向けて送られるデジタル通信の着信を含む。システムは、システムに関するアカウントホルダの位置を追跡するための位置サービスも含むことが可能であり、ここでトリガイベントは、それに代わってマクロが実行される第1のアカウントホルダに関連付けられた第2のアカウントホルダの位置の決定を含むこともできる。マクロには、複数の異なるユーザアカウントからのトリガイベントに応答してアクセスすることが可能であり、システムは、システムに関する複数のアカウントホルダに関連付けられた複数の文書を含むことも可能であり、ここで複数の文書は、マクロデータストアに格納されたマクロへのポインタを含む。さらにシステムは、マクロからの呼び出しに応答してホスト型コンピュータシステムに登録されたユーザの位置に関する情報を提供するための、位置サービスを含むことができる。また位置サービスは、そのアカウント内でマクロが実行中であるユーザが、その位置情報が提供されることになるユーザに関連付けられているものとしてシステムによって識別された場合にのみ、位置に関する情報を提供することができる。

さらに他の実装形態では、ホスト型コンピュータシステム上でマクロを実行するためのコンピュータ実装システムは、ホスト型コンピュータシステムから動作可能な複数のホスト型アプリケーションと、それぞれがホスト型コンピュータシステム上のユーザアカウントに割り当てられ、それぞれが複数のホスト型アプリケーションのうちの少なくとも1つによって実行されることになる一連のアクションを定義付ける、複数のマクロを格納するマクロデータストアと、特定のアカウントホルダに関連付けられたトリガイベントの識別に応答して、複数のマクロを実行するための手段と、を含み、トリガイベントは、特定のアカウントホルダがシステムにログインしているかどうかに関係なく発生する。

1つまたは複数の実施形態の詳細について、添付の図面および以下の説明で述べる。他の特徴および利点は、この説明および図面から、ならびに特許請求の範囲から、明らかとなろう。

ホスト型コンピューティングシステムにおけるマクロ動作を示す概念図である。 共有マクロの動作が可能なホスト型コンピュータシステムを示す概略図である。 ホスト型コンピューティングシステム上でマクロを実行するためのプロセスを示す流れ図である。 イベントトリガされたマクロを管理するためのプロセスを示す流れ図である。 ウェブページ上で実行中のアプリケーションから呼び出されたマクロを実行するためのプロセスを示す流れ図である。 ホスト型コンピューティングシステム上でマクロを記録および実行するためのプロセスを示すスイミングレーン式(swim lane)流れ図である。 マクロシステムにおけるオブジェクトの例示的構造を示す図である。 マクロ構成システムの例示的スクリーンショットを示す図である。 本書で考察されるアクションを実行するために使用可能な汎用コンピュータデバイスの例を示す図である。

様々な図における同様の参照番号は、同様の要素を示す。

図1は、ホスト型コンピューティングシステム100におけるマクロ動作を示す概念図である。こうした動作は、マクロをその格納位置へ作成および/またはコピーしたユーザが、そのデスクトップコンピュータから、そのネットブックコンピュータから、またはインターネットカフェ内のコンピュータなどの公共利用可能なコンピュータから、アプリケーションを実行中に、マクロへのアクセスを試行した場合、様々なクライアントからのマクロの動作を実行可能にすることによって、クライアントデバイス上、または(たとえばリモートデスクトップ接続サービスまたはＶＰＮを介して)単一のクライアントデバイス向けのサーバ上での、マクロ動作と対比することができる。またマクロは、他のユーザ(たとえば初期のユーザと同じドメインからシステムにアクセスするユーザ)が彼ら自身のアプリケーションを使用している場合にマクロを実行できるようにする旨の、マクロに関するアクセス制限を第1のユーザが定義することによって、ユーザ間で容易に共有することができる。またマクロは、ユーザおよびユーザのコンピュータの外部入力がマクロの実行をトリガした場合など、ユーザがオンラインでない場合であっても、そのユーザに対して実行可能である。さらに、ホスト型システムが互いに関連する(たとえばすべて同じ企業組織で働く)複数の登録ユーザを有する場合、ホスト型システムで実行中のマクロは、複数のこうしたユーザに対応するアプリケーションおよび/またはデータストア全体にわたる複雑なワークフローを生成することができる。

前述のように、マクロは、電子メールメッセージの受信などの外部イベントによってトリガ可能である。マクロは、ユーザのクライアントシステムとは別個であり、その上で他のサービスまたはアプリケーションが実行中の任意のサブシステムとは別個である、マクロサーバサブシステム上で実行可能である。たとえば、他のサブシステム上のサービスは、メインシステムに対する内部サービス(たとえば位置サービスおよび電子メールサービス)および(たとえば商用のオンラインストアまたはオークションサイト、気象サイトなどからの)第3者サービスを含む、情報を得るためにマクロがアクセスするいずれのサービスも含むことができる。

システムに関連付けられたマクロサーバサブシステムは、マクロコードを作成するユーザが統合された一貫した方法でマクロを作成できるようにするものであり、これによってプログラミングエクスペリエンスをエンドユーザにとって容易なものにすることができる。たとえば、スプレッドシートおよびカレンダの操作、ウェブコンテンツのフェッチ、電子メールの送信、それらのカレンダへのアクセス、テキストの翻訳などの、エンドユーザに公開される異なるサービスに関してオブジェクトモデルを定義することができる。オブジェクトモデルは、たとえばJava(登録商標)オブジェクトを使用して表すことができる。各Java(登録商標)オブジェクトは、基礎となるサービスへのアクセス方法をラップする(wrap)ことができる。スプレッドシートおよび言語翻訳サービスは、内部直接ネットワーク呼び出し(たとえばリモート手続き呼び出し)を使用することが可能であり、ウェブコンテンツフェッチングは、たとえばSOAPまたは同様のサービスを使用することができる。これらのサービスの多くは、エンドユーザに直接公開される必要はない。

システム100は、基礎となるJava(登録商標)オブジェクト周囲に「ラッパー(wrapper)」または「デコレータ(decorator)」のいくつかの層を作成することによって、エンドユーザに内部サービスを公開するリスクをなくすことができる。たとえばシステム100は、所与のユーザによって所与のサービスを呼び出すことが可能な回数を制限する、クォータ強制層(quota enforcing layer)を含むことができる。システム100は、機能ベースセキュリティが使用可能であり、きめの細かい(たとえば、基礎となるデータへの読み取りアクセスは可能であるが書き込みアクセスは不可能な)アクセス制御を可能にする、セキュリティ層を含むことができる。システム100は、すべてのユーザ呼び出しをキャプチャ可能であり、それらのセッションのトランスクリプトを提供可能な、ロギング層を含むこともできる。クォータおよびセキュリティが均一に適用され、サービス全体にわたってアドホックでない場合、プログラマのエラー機会(および結果として生じるセキュリティ侵害)は減少する可能性がある。

システム100は、コンピュータマクロを管理するための様々なコンピュータ実装メカニズムを含むことが可能であり、コードは、インターネットアクセス可能なホスト型コンピュータシステム内のある位置のマクロに関して格納され、以下の機能を実行するように動作可能である。ホスト型コンピュータシステムに対してリモートのクライアントコンピュータ上で実行中のアプリケーションなどから、マクロを実行する旨の要求を受信すると、マクロはホスト型コンピュータシステム上で実行可能である。たとえばマクロは、マクロマネージャまたはその通信可能に結合された構成要素の内部で、直接実行することができる。マクロの実行結果は、クライアントコンピュータ上で実行中のアプリケーション(たとえば、ユーザのコンピュータ上のブラウザで実行中のスプレッドシートアプリケーション)に提供可能である。マクロが動作するようにプログラミングされている文書とは別に、この状況でマクロに関するコードを格納し、これにアクセスすることができる。たとえば、コードはホスト型サービスサーバ上で実行可能であるが、マクロコードによって更新されたスプレッドシートは、ユーザのラップトップコンピュータ上、またはホスト型サービスの他の位置に常駐可能であり、ここでマクロは、ホスト型サービスに登録された任意数のユーザに代わって実行中の任意数のアプリケーションを自由に指示し、これらからのアクセスが可能である。

いくつかの実装形態では、各マクロをホスト型コンピュータシステムの登録ユーザに関連付けることが可能であり、登録ユーザによって識別されたアクセス制限に従って、マクロをホスト型コンピュータシステムの他のユーザ(またはより具体的には、他のユーザのアカウントで実行するアプリケーション)が使用できるようにすることが可能である。たとえば、マクロを「所有する」ユーザは、それらのユーザIDを介して、またはそれらユーザが属するグループを介して、彼のマクロを使用することが認可された他のユーザを識別することが可能である。他のケースでは、ユーザは、マクロへのリンクまたはURLを提供し、マクロの実行に関連付けられたある権利を含むことができる。

アクセス制限は、ホスト型コンピュータシステムによって登録ユーザが割り当てられた1つまたは複数のグループによって定義可能である。たとえば、ユーザは「MyOnlineFriends」と命名されたグループへのアクセス権をマクロに付与し、そのグループ内のすべての人々に、自分のソーシャルネットワーキングサイト(たとえばFacebook、Orkutなど)上で識別された自分の「友人(friends)」を表すことができる権利を割り当てることができる。

いくつかの実装形態では、マクロを実行する旨の要求を受信することが可能であり、この要求は、ホスト型コンピュータからリモートの複数の異なるクライアントコンピュータ上で実行中の複数のアプリケーションから発信される。たとえばアプリケーションは、マクロの定義において、マクロの実行を開始するか、あるいは待機状態の後にマクロの実行を再開または続行するように設計された、「イベント」を生成または始動(fire)することができる。システム100は、位置からの各要求に対してホスト型コンピュータシステム上でマクロを自動的に実行することができる。さらにシステム100は、マクロの実行に応答して、複数アプリケーションのうちのそれぞれのアプリケーションに、マクロ実行の結果を提供することができる。いくつかの実装形態では、複数のアプリケーションが単一のアカウントホルダに対応する。たとえば、マクロの実行を要求する各アプリケーションが、結果を受信することができる。いくつかの実装形態では、複数のアプリケーションが複数の異なるアカウントホルダ(たとえば、システム100の複数の登録ユーザ)に対応する。

マクロの実行は、ホスト型コンピュータシステムによって提供される複数の異なるホスト型サービスの呼び出し実行を含むことができる。たとえばマクロは、カレンダサービス、連絡先サービス、位置提供サービス(たとえば、ユーザまたはユーザの友人の位置を示すサービス)などを呼び出すことができる。代替または追加として、マクロの実行は、(たとえば、異なるドメインにあり、ホスト型コンピュータシステムの組織とは異なる組織によって運営されている)ホスト型コンピュータシステムとは無関係の第3者情報プロバイダによって提供されるウェブサービスの呼び出し実行を含むことができる。

ホスト型コンピュータシステム上で実行中の第1のアプリケーションによって生成された情報は、第1のフォーマットから第2のフォーマットへの変換も可能であり、変換された情報は、ホスト型コンピュータシステム上で実行中の第2のアプリケーションに提供可能である。たとえばデータは、ワードプロセッシングアプリケーションによって、カンマで区切ったフォーマットで作成可能であり、その後このデータを、スプレッドシートアプリケーションに特有のフォーマットでスプレッドシートセルに貼り付けるために、スプレッドシートアプリケーションに提供することができる。

マクロ実行の結果は、ホスト型コンピュータシステムに登録された複数の異なるユーザに関する複数の異なるアカウントに、自動的に提供することもできる。たとえば、マクロ実行の結果は、いくつかのコンピュータシステム上の何人かのユーザに対して、彼らの各システム上で共通のスプレッドシートセルを更新するなどのために提供可能である。いくつかの実装形態では、マクロを実行する旨の要求は、クライアントコンピュータ上のブラウザが、ホスト型コンピュータシステム内のマクロ実行サブシステム上のJavaScript(登録商標)マクロへのポインタを有するウェブページをロードすることに応答して、受信される。たとえば、マクロへのリンクまたはURLを渡すことによってマクロが共有される場合、マクロを(たとえばJavaScript(登録商標)または任意の他の関連言語で)実行する旨の要求を、リンクまたはURLの形で提供することができる。

次に、図１に関してより具体的に参照し、前述の機能の一部またはすべてを実装するための例として、システム100は、1つまたは複数のアプリケーション102(それぞれが、アクセスされた場合にマクロを実行させる、マクロフック104へのアクセス権を有する)、1つまたは複数の外部イベント105、マクロサーバサブシステム106、ソーシャルネットワーク108、位置サービス110、およびマクロコード112を含む。

アプリケーション102は、電子メールアプリケーション、スプレッドシートアプリケーション、ワードプロセッシングアプリケーション、写真共有アプリケーション、プレゼンテーションパッケージ、金融プランニングアプリケーションなどの、ユーザが実施または実行させることが可能な、任意の適用可能アプリケーションを含むことができる。いくつかのケースでは、ユーザは、デスクトップ上またはアプリケーションのプルダウンリスト内のアプリケーション名をダブルクリックすることによるなど、実行するアプリケーションを選択することによって、アプリケーションを明示的に開始することができる。他のアプリケーションは、ユーザが電子メールの添付ファイル(たとえばテキストファイルまたはスプレッドシート)をクリックした場合、または、ユーザが未知のファイルをクリックした場合などに、暗黙的に開始することが可能であり、どちらの場合も、ファイルの拡張子名または他の定義された関連付けに基づくなど、ファイルに関連付けられた対応するアプリケーションの実行を自動的に開始することができる。ユーザは、ホスト型アプリケーションなどのアプリケーションを対象とするURLへナビゲートすることによって、アプリケーションを開始することもできる。

アプリケーションの開始または実行のさらに他の例では、あるアプリケーションの実行を開始または再開することが可能な、電子メールメッセージの受信などの、イベント105が発生可能である。たとえばイベント105(たとえば、受信された電子メールメッセージ)は、(たとえば、スプレッドシートの更新、件名欄の追加のために)マクロをトリガすることができる。イベントの発生は、ホスト型システム上で実行し、システムに登録された各ユーザに関するイベントを追跡する、イベントハンドラによって検出することができる。各イベントは、報告された後、マクロの実行などの特定のアクションと相関されることが可能であり、アクションをトリガすることができる。

各アプリケーション102は、マクロフック104へのアクセス権を有する。最も単純な実装形態では、マクロフックは単に、システム100上に格納され、システム100上で実行可能な、マクロに関するコードを指示する、URLとすることができる。たとえばフック104は、JavaScript(登録商標)コードを指示するURLとすることが可能であり、ウェブページに含めることが可能であるため、このウェブページがロードされた場合、またはウェブページの動作に関連付けられたあるイベントが発生した場合、コードにアクセスして実行することができる。そのアプリケーション102内のマクロの定義を容易にすることに加えて、またはその代替として、マクロフック104はイベント追跡を実行し、外部イベント105とマクロサーバサブシステム106との間の接続を提供することができる。たとえばマクロフック104は、電子メールアプリケーション102内で受信された電子メールに関するイベントに関連付けられたマクロを、ユーザが定義できるようにすることができる。マクロは、電子メールアプリケーション102が提供できるものとは異なるオブジェクトを識別することができる。さらに、マクロのマクロコード112は、電子メールアプリケーション102内のマクロのネイティブ言語とは異なる言語とすることができる。マクロフック104は、マクロに関するいずれのイベントも追跡可能であり、適切な時点にマクロサーバサブシステム106と相互作用することが可能である。マクロフック104は、マクロを記録するためまたは既存のマクロを実行するためのオプションを選択することによって、ユーザによってインスタンス化または実現することができる。

外部イベント105は、(たとえば電子メールアプリケーション内での)電子メールメッセージの受信、(たとえば、クォータを超えている、ユーザアクセスが拒否される、プロセスが完了したなどの)ある条件が存在する旨の(たとえばアプリケーションによる)決定などを含む、マクロの実行をトリガするための多様なイベントを含むことができる。こうしたイベントは、イベントハンドラによって追跡可能であり、追跡されることになる特定のイベントは、システム100内での特定のイベントの発生時にマクロが実行されることを希望する各ユーザに関して、イベントハンドラに登録可能である。

いくつかの実装形態では、イベントは、コードの行がある条件(たとえば変数がある値に達した、またはアカウンティング更新が夜の間に実行されるなど)に合致した旨を決定した場合などに、コード内にトラップ可能である。外部イベント105は、テキストメッセージ、ブログエントリ、着信RSSフィードなどの、メッセージの検出を含むこともできる。外部イベント105は、たとえばオークションアイテムのタイトルまたは説明(たとえば「年代物のバチカンの鑑札」)によって決定できるような、オンラインオークションサイト上での特定アイテムのポスティングの検出を含むことができる。

外部イベント105のトリガ条件は、条件の異なる組み合わせを含むことができる。たとえば、電子メールアプリケーションに関するイベントのトリガに使用される条件は、電子メールの件名欄、送信者ID(たとえば、上司、配偶者、子供など)、受信者(たとえば「宛先」と「Cc」と「Bcc」の組み合わせを使用する)、受信者の数(たとえば、自分が唯一の受信者の場合は通知するなど)、添付ファイルの有無、電子メールの送信元の位置、メッセージ本文におけるキーワード、あるいは、電子メールがスパムであることが予想されるかどうか、などを含むことができる。ワードプロセッシングアプリケーションに対応することが可能な条件は、文書のサイズ、文書のソース、文書の作成日および/または最も新しい修正日、文書の作成者などを含むことができる。スプレッドシートアプリケーションの場合、イベントのトリガに使用されることが可能な条件は、特定のスプレッドシートセルの値、セルの値が変更されたかどうか、スプレッドシート内の実際のデータの行または列の数、スプレッドシートの作成者、スプレッドシートのサイズなどを含む。他のタイプの文書に適用される条件は、その文書に変更が発生したばかりであるかどうかを含むことができる。他のトリガイベントは、たとえば、特定の町に竜巻が向かっていることを警告するオンライン気象サービスサイトによってポストされた警報などの、ウェブ上のソースまたはサービスによって生成可能である。こうしたケースでは、気象に慎重なユーザは、外部の気象関係イベントを傍受し、自分の家族または隣人へのテキストおよび/または電話呼び出しを生成するように、すでにマクロを構築している可能性がある。

イベントは、いくつかの異なるソースからの組み合わせとすることも可能である。たとえば、初期イベントは、特定のユーザから電子メールを受信することによって初期にトリガすることができるが、マクロは、そのイベントが発生し、電子メールを送信または受信するユーザが位置追跡サービスによって特定の位置に居ることが決定された後にのみ、実行可能である。他のサービスからの情報を使用する追加または代替の条件を課することもできる。

マクロサーバサブシステム106は、アプリケーション102によって伝搬されるイベントなど(たとえば電子メールメッセージなど)の、システム100内の特定のイベントを監視することができる。マクロサーバサブシステム106に関係のある特定のイベントは、マクロサーバサブシステム106に対する命令(たとえば、「さらなる通知があるまで、サーバXYZ、アプリケーションABC、またはユーザJohn Doeとの通信を中断」)としての役割を果たすことが可能なイベントに加えて、マクロによって対処可能な任意の関連イベントを含むことができる。

様々なサービスが、イベントに関するトリガ、トリガに応答して実行中のマクロに関する入力、またはマクロからの出力であることのいずれかによって、システム100と相互作用することができる。たとえば、ソーシャルネットワーク108は、イベントをどのように処理するかを決定するために有用な情報をシステム100に提供することができる。一例として、Bettyに送信された電子メールを受信し、その電子メールが(たとえば1つまたは複数のソーシャルネットワーク上で定義された)Bettyの友人のうちの1人からである場合にのみ、動作を実行するように、マクロを定義することができる。他の例では、マクロは、自動電子メールまたは他の通知を(たとえば、ソーシャルネットワーキングサイトまたはグループによって定義された)すべてのBettyの「友人」に送信するように、設計することができる。ソーシャルネットワーク108を実行する組織は、サブシステム106を実行する組織とは異なることが可能であり、前者のシステム108のオペレータは、APIを介してある情報へのアクセス権を、サブシステム106のオペレータがこうしたアクセス権を与えられている限り、提供することができる。

他の例として、位置追跡サービス110は、ユーザによって求められた場合、ユーザが自分の友人を発見できるように、またはその逆が可能なようになど、ユーザに関連付けられたモバイルデバイスの位置を追跡することができる。たとえばマクロは、ユーザに電子メールまたはテキストを送信するように定義可能であり、電子メールまたはテキストの宛先はその時点でのユーザの位置に依存することができる。たとえば、ユーザが携帯電話または他のモバイル(たとえばGPSベースの)デバイスを有する場合、ユーザの位置は位置追跡サービス110によって追跡または認識可能である。ユーザの位置に依存して、マクロの実行によって伝搬される電子メールを、ユーザのモバイルデバイス、または自宅にあるデバイス(たとえば、ユーザが自宅の方に近い場合、または位置サービス110が、ユーザがおそらくその方向に向かっているものと判断した場合)に送信することができる。

たとえばユーザのGPS対応デバイスから送信された「今どこ？」という位置情報に加えて、ユーザは、位置追跡サービス110を介して「どこへ行く？」という情報も受信することができる。この情報は、たとえばGPS座標または簡単なテキストメッセージ(たとえば「ここを曲がり、10107まで坂を上る」)を含むことができる。

サブシステム106は、マクロコードの様々なインスタンスを格納、追跡、アクセス、共有、および実行することができる。マクロを構成するマクロコード112は、任意の適切な言語とすることができるが、典型的には、システム100によって使用される好ましいマクロ言語(たとえばJavaScript(登録商標)など)で作成またはプログラミング可能である。マクロがよく知られた方法で実行される場合、マクロサーバサブシステム106は、「名前取得(get name)」機能114、「名前チェック(check name)」機能116、「位置取得(get location)」118、あるいは、マクロサーバサブシステム106が考慮すべき任意の他の機能またはマクロなどの、マクロコード112の機能関連およびマクロ関連セグメントを解析(または検索)することができる。マクロコード112に埋め込まれた機能または動作のそれぞれが、ファイルへのアクセスに対するユーザの認可のチェックなどの様々なタイプの処理を、マクロサーバサブシステム106に実行させることができる。

マクロコード112は、中央マクロリポジトリまたはインターネットアクセス可能なホスト型コンピュータシステムなどの、多様な位置に格納することができる。いくつかの実装形態では、マクロコード112の集合全体を分散様式で格納し、1つまたは複数のネットワークによって互いに論理的に結合することができる。いくつかの実装形態では、マクロコード112が、機密性が高い(たとえばユーザの個人情報を含むかまたは更新する)、または国防のために分類される(たとえば機密、最高機密など)場合、マクロコード112は、セキュアサーバ上などの別の位置に明示的に格納することができる。

いくつかの実装形態では、イベント追跡用に「リスナー(listener)」を使用することができる。たとえば、スプレッドシートがサーバ上にロードされ、そのHTMLがブラウザに送信された場合、新しいスプレッドシートがオープンされた旨を示すサーバサイドイベントをトリガすることができる。このイベントに関するスプレッドシートサーバ上のリスナーは、そのスプレッドシートに関するスクリプトのリストを有するかどうかをチェックすることができる。リストを有していない場合、基本的に、(スクリプトサーバに対して)「このスプレッドシートに関するスクリプトはあるか？」と問合せをし、スプレッドシートキーを渡し、そのスクリプトのリストを格納することができる。その後、スプレッドシートサーバ上のイベントハンドラは、いずれかのスクリプトメソッドが「onOpen」と呼ばれているかどうかをチェックすることができる。そのように呼ばれている場合、そのメソッドを実行するために(たとえばGoogle Apps Scriptサーバへ)メッセージを送信することができる。この流れは、編集イベントなどの他のシナリオでも使用可能である。

他の例では、マクロは、たとえば件名欄、電子メール送信者、電子メールメッセージに非常に大きなスプレッドシートの添付ファイルが存在するかどうか、(任意の種類の)添付ファイルが存在するかどうか、などに依存する、あるメッセージルーチンを実行するためにセットアップされている電子メールアプリケーションに関連付けることができる。こうした様式で定義されたマクロは、位置追跡サービス110によって提供されるような、位置情報を使用することも可能である。たとえば、ユーザの会社電子メールに宛てられた電子メールメッセージが大きなスプレッドシート添付ファイルを有し、(そのモバイルデバイスからのGPS信号がユーザの自宅として登録されている位置に対応することから)ユーザが在宅であると決定された場合、コピーをユーザの自宅電子メールに転送するよう、マクロを確立することができる。こうした状況では、添付ファイルは、翌日の会社でのプレゼンテーションまたはプロジェクト用に再検討が必要な会社関係のスプレッドシートである可能性が高い場合がある。代替として、ユーザが自宅近くには位置しないことがわかったような場合、電子メールが存在することをユーザに警告する、ユーザのモバイル電子メール対応デバイスに小さなメッセージを送信するように、マクロを確立することができる。

いずれの場合も、マクロコード112は、マクロサーバサブシステム106上に格納し、マクロを実行させるいずれの電子メールアプリケーション102からも除去することができる。受信されたあらゆる着信電子メールメッセージについて、電子メールアプリケーション102は、フック104を用いてマクロコードを指示することによって、マクロをトリガすることができる。その後マクロは、特定の送信者がアカウントホルダのソーシャルネットワークのメンバであるかどうかなどの、メッセージの様々な態様を識別することができる。ソーシャルネットワークのチェック結果が肯定的である場合、マクロは、アカウントホルダの送信者の地理的位置を決定するために位置追跡サービス110をさらにチェックし、こうした位置に基づいてあるアクションを実行させることができる。たとえばマクロサーバサブシステム106は、アカウントホルダ(またはユーザ)の位置に基づいて、ある状況でアカウントホルダに通知することができる。他のケースでは、マクロサーバサブシステム106は、(たとえば、VOIPを使用するユニバーサルコールルーティングシステムを介して)アカウントホルダを呼び出させること、および/またはSMSメッセージを送信させること、あるいはマクロによって定義された他のアクションが可能である。

マクロは、システム100上で実行する様々なアプリケーションにアクセスすることによって、1つまたは複数の確認型APIを介して、こうした情報を取得および提供することができる。複数の異なるAPIが存在する場合、変換サービスにサブシステム106を提供することが可能であるため、作成者は、全く異なるアプリケーションで作業をしながら、サブシステム106用の単一のマクロ言語について作成可能である。

ユーザのクライアントコンピューティングデバイスとは別個のマクロサーバサブシステム上でマクロがホストされている場合、いくつかの恩恵が生じる可能性がある。たとえばマクロは、多くの異なるアプリケーションにわたって使用することができる。またマクロは、ユーザがオンラインの間に、そのデスクトップコンピュータ、いずれかの人のコンピュータ、ネットブック、またはスマートフォンなどの様々なアクセスポイントから、トリガすることが可能であり、マクロは、ユーザがオンラインでないかまたはそのコンピュータに居ない場合であっても、トリガすることができる。こうしたマクロは、1つのタイプのアプリケーション(たとえば電子メール)を傍受し、他のアプリケーション(たとえば、ユーザに関する着信電子メールメッセージの件名欄がスプレッドシート内に自動的にコンパイルされる、スプレッドシート)内のデータを更新するように、定義することができる。

他の恩恵は、手動でコピーする必要なしに、ユーザ間でマクロを完全に共有できる機能とすることができる。これに代わって、1つまたは複数のセキュリティレベルを各マクロ上に設定し、それによって、マクロを作成したかまたは最初に保存したユーザが決定したように、他のユーザにアクセスすることができる。たとえばユーザは、たとえばオンライン写真共有サイトなどの一般的なウェブプロパティについて実行できるように、マクロに関するアクセスセキュリティレベルを設定し、マクロのURLを他の人物に提供することができる。

マクロサーバサブシステム上でホストされるマクロは、あるインスタンスでは、様々なユーザからのデータに照らしてマクロを実行するため、またはマクロの実行結果を様々なユーザに提供するための機能を、提供する恩恵も有することができる。たとえば共有マクロを使用して、何人かの作者による投稿を、何人かの人々によって書かれた詩や論文などのより大きなボリュームに組み合わせることができる。各寄稿者の文書を所定の位置に保存することが可能であり、寄稿者がその位置へのアクセス権を提供している場合、マクロはこれにアクセスできる。組み合わされたボリュームを単一の文書としてそれぞれの寄稿者およびおそらくは追加のユーザ達が使用できるようにすることが可能である。他の例として、承認のために文書をルーティングするためなどに、ホスト型サブシステム上のマクロを使用して業務ワークフローアプリケーションを作成することが可能であり、文書は常時サーバシステム上にローカルに格納されている。

図２は、共有マクロの動作が可能なホスト型コンピュータシステム200を示す概略図である。一般に、システム200は、ユーザによってホスト型システム上でのマクロの作成、保存、共有、アクセス、および実行が可能な様式の一例を示す、様々な構成要素を提供する。

このシステム200では、マクロサーバサブシステム202は、スクリプト情報ストレージデータストア206内に永続的にマクロコードを保存するための位置を提供し、保存される情報は、マクロライブラリ名、スクリプトコンテンツ、およびマクロ所有者の識別子(たとえば、難読化された(obfuscated)ユーザID、または他の識別子を使用する)を含むことができる。マクロが実行された場合、所与のマクロを実行するために、コマンドをマクロサーバサブシステム202に送信することができる。次にスクリプト情報ストレージデータストア206からコードを取り出し、スクリプトエンジン、またはスクリプト実行プログラム208内にインスタンスを作成することができる。

異なるサーバサイドアプリケーションに関するプログラムAPIを表すJava(登録商標)オブジェクトを構築することが可能であり、機能ベースのセキュリティラッパー内にラップすることが可能であり、プログラマに可視のラップサービス(または「beans」)となる。ラップサービス210は、マクロサーバサブシステム202が、たとえばマクロの実行に関するラップサービスの消費者に対してサービスを提供することが可能な、すべての関連サービスを含むことができる。ラップサービス210は、順に回すことが容易なようにパッケージングされた他のオブジェクトの集合である、任意の関連オブジェクトとすることができる。

ラップサービスは、バックエンドサービスと相互作用する公開方法を公表するJava(登録商標)業務デリゲート(delegate)を含むことができる。この公開方法は、メソッド、クラス、文字列、スプレッドシート、アプリケーションプログラミングインターフェース(API)、および、様々なコンピュータ言語(たとえばJava(登録商標)など)によって提供される他のツールをパッケージングするために、パッケージまたは他のメカニズムに含めることができる。公開方法は、たとえばマクロの定義および実行に使用可能なリソースを公表する(または公開する)ことができる。公開方法の実装形態のある細部は非公開で保持され、好適なレベルの情報の隠蔽および抽象化を提供することができる。公開方法は、いくつかの異なるタイプのオブジェクトにわたって同様であるように見え、ある程度一貫した外観と使い勝手をマクロユーザに公開し、ある程度の多態性(polymorphism)を提供することができる。結果として、ラップサービスの集合は、オブジェクト指向のイベント駆動型環境での、ユーザによるマクロの使用を容易にすることができる。

これらのラップサービス、またはbeansは、この例示的システム200において、各プロパティ(たとえばスプレッドシート、カレンダなど)について公開メンバを有する、トップレベルのJava(登録商標)オブジェクトに接続される。このトップレベルのJava(登録商標)オブジェクトは、標準および所定のラベルを備えたスクリプト実行プログラムの環境に関する範囲内に挿入される。いくつかの実装形態では、スクリプト実行プログラムは、公開メンバ(および公開メンバのみ)を、スクリプティング環境に反映させる。

したがって、ユーザのJavaScript(登録商標)コードが
var doc = google.spreadsheets.create (“my new doc”) (1)
を実行した場合、トップレベルのオブジェクトの「spreadsheets」フィールド内のJava(登録商標)オブジェクト上の「create」Java(登録商標)メソッドが呼び出される。このメソッドのJava(登録商標)実装は、「CREATE」コマンドおよび新しいタイトル(たとえば「my new doc」)に対応する引数、ならびにスクリプト実行者の難読化された識別子によって、スプレッドシートサーバへのリモート手続き呼び出しを実行する。スプレッドシートサーバは、新しいスプレッドシートを作成し、リモート手続き呼び出しに応答してそのキーを戻す。マクロサーバは、新しいキーを含む、新しく作成されたスプレッドシートを表す新しいJava(登録商標)オブジェクトを作成する。Java(登録商標)オブジェクトは、「rename」、「insertSheet」などの、いくつかのスプレッドシート動作に関するメソッドを含む。このオブジェクトは、機能ベースのセキュリティラッパー内にもラップされ、戻される。スクリプト実行プログラムは、このオブジェクトをNativeJavaObjectラッパー内に内部的にラップし、これを上記の変数「doc」に戻す。

ラッピングオブジェクトのいくつかの実装形態では、任意の適切なサービス(たとえばスプレッドシート、カレンダ、電子メールなど)は、Java(登録商標)動的プロキシ内にラップされたオブジェクトを戻すことができる。セキュリティ、ログ、およびクォータ用などに、明確なプロキシが存在可能である。各プロキシは、公開方法を定義することが可能な、公開中のサービス(たとえば、「Spreadsheet」、「SpreadsheetRange」、「EmailService」などの、Java(登録商標)インターフェース)の説明を組み込むかまたは使用することができる。インターフェース上には、異なるラッパーに適したアノテーションが存在可能である。

たとえば、スプレッドシートサービス上の「create」メソッドは、新しいスプレッドシートを作成することができる。これは、メソッドがWRITEメソッドを宣言する1つの注釈を有することが可能であり、たとえばスクリプトがそれらのスプレッドシート文書の集合への書き込みを試みようとする(および、ユーザがそのスクリプトに関してWRITE特権を認可されていない場合、スクリプトがランタイム時に失敗することになる)旨を、ユーザに警告するためのメカニズムを提供する。基本的に、セキュリティラッパーは、宣言された所与のメソッドの要求するパーミッション(書き込み許可など)が、ユーザの認可トークン内にあることを保証するために役立つ。メソッドは認可された場合、次の層への呼び出しを渡す。

セキュリティは、特定のユーザがマクロに関する動作にアクセスできる回数を制限することによっても、提供可能である。こうした機能を実行するために、「create」メソッドには、このメソッドへの呼び出しがエンドユーザの「スプレッドシート作成」クォータに照らしてカウントされるべきである旨の、クォータ注釈が存在可能である。クォータラッパーは、所与のユーザが動作を何回実行させるかを追跡し続けるクォータサービスを、呼び出すかまたは使用することができる。このメソッドは、たとえばユーザがクォータを超えている場合、失敗する可能性があり、超えていない場合は、再度次の層へ渡す。ユーザに関するクォータは、1日、1週間、1か月間などの、設定された期間にわたって測定可能であり、定期的にリセットまたは減分可能である。

マクロ実行のトランスクリプトは、呼び出された各メソッドの文字列バージョン、および提供された引数を記録する、ロギング層によっても提供可能である。

ラップサービス作成プログラム212は、トップレベルのラップサービスを作成可能であり、その範囲はマクロおよびその環境に依存する。たとえば、ラップサービス作成プログラム212は、マクロを実行中のエンドユーザが明示的にマクロに認可した機能を検査することが可能であり、マクロの状態に対応するトップレベルのbeansを作成することができる。この状態には、たとえば現行の文書(たとえば電子メール、テキスト文書、図面、スプレッドシートなど)、および、あればユーザ認証を含むことができる。ラップサービス作成プログラム212は、環境に基づいた機能を有するトップレベルのラップサービスを生成することが可能であり、たとえばユーザがマクロの定義および実行が可能なスクリプト実行プログラム208の実行環境に、ラップサービス210を投入することができる。ある意味で、ラップサービス作成プログラム212は、beansのプロデューサまたはファクトリ、すなわち「beanファクトリ」とみなすことができる。

作成可能なラップサービス210のタイプには、たとえば、スプレッドシートアプリケーション、カレンダアプリケーションなどの、機能ラップインスタンスが含まれる。このJava(登録商標)オブジェクトを実行範囲に挿入することができる。オブジェクトのソースを使用して(たとえば、ラベル「TopLevel」を付けて)これを識別することができる。したがって、たとえば「TopLevel.spreadsheets」は、機能ラップオブジェクト(たとえばSpreadsheetApplicationApiオブジェクト)への参照となる可能性がある。オブジェクトの公開方法は、Java(登録商標)オブジェクトとしてJavaScript(登録商標)プログラミング環境内に反映すること、およびマクロに使用できるようにすることが可能である。

たとえば、
var doc = google.spreadsheets.getActiveSpreadsheet();
var otherDoc = google.spreadsheets.openByName(“MyOtherDoc”);
var value = doc.find(“A1”).getValue();
otherDoc.find(“B2”).setValue(value); (3)
などのJavaScript(登録商標)コードは、既存のスプレッドシート(たとえば「MyOtherDoc」と呼ばれるスプレッドシート)をオープンし、現行のスプレッドシートからのセルA1の値を、新しいスプレッドシートのセルB2へとコピーすることができる。「find」メソッドによって戻されるRangeオブジェクトなどのJava(登録商標)オブジェクトは、他のすべてと同様に機能ラップされ、認証されたユーザが関連するスプレッドシートにアクセスできない場合、失敗する可能性がある。たとえば以前に提示されたセルのコピー/ペーストの例では、正常な実行に必要なアクセスは、アクティブなスプレッドシート上での(たとえばgetValueが必要とする)読み取りアクセス、および、ターゲットスプレッドシート(たとえばスプレッドシート「MyOtherDoc」)上での(たとえばsetValueが必要とする)書き込みアクセスである。

スクリプト実行プログラム208は、マクロに関するコンテキストを作成すること、および、トップレベルのラップサービス210の実際の挿入を実行することについて、責務を負うものとすることができる。1つの実行スクリプトが他のスクリプトの全体的な範囲を「汚染する」可能性を防止するためなどに、各マクロの実行について、新しいトップレベルの範囲を作成することができる。マクロコンテキストは、承認されていない(たとえば許可されたクラスの優良リスト上にない)いずれのJava(登録商標)クラスの作成をも防止する、クラスシャッタまたはフィルタの実装と共にロード可能である。加えて、スクリプト実行プログラム208は、スクリプトが無限ループに入ったことを検出するためなどに、暴走スクリプト(runaway script)を抑圧するための命令カウンタを作成することができる。いくつかの実装形態では、暴走スクリプトはスクリプトマネージャ204によって早期に終了させることができる。

スクリプト実行プログラム208は、解析、構文チェック、機能呼び出し、マクロ実行、および再開を含む、様々な機能に対して責務を負うものとすることができる。解析機能は、スクリプトを調査し、スクリプト情報データストア206などのデータストア内のスクリプトストレージで発見された機能およびマクロのリストを戻すことができる。たとえば図1を参照すると、解析機能の結果として検出される機能およびマクロは、スクリプトまたはマクロコード(たとえばマクロコード112)に埋め込むことが可能な、名前取得機能114、名前チェック機能116、位置取得機能118、または任意の他の機能、マクロなどを含むことができる。

システムによってサポートされる他の機能は、サーバサイドシステム200上でのマクロの集合の管理を助けるために使用することもできる。たとえば、構文チェック機能は、スクリプトを格納する前に、内部のスクリプト内にエラー(たとえば構文エラー、言語コンパイルエラー、キーワードの誤用など)が存在するかどうかを判定することができる。構文エラーまたは他のエラーが検出された場合、エラーを送信して、ユーザまたはスクリプトプログラマに警告することができる。

呼び出し機能はマクロ内の機能を「呼び出す」(または実行を開始する)ことができる。この呼び出し機能は、セル内(たとえばスプレッドシート内)の機能呼び出しに付与された権利を有するバージョンなどの、マクロの制限付き実行バージョンとすることができる。たとえばマクロの制限付きバージョンは、値を戻すことのみに制限されており、副作用を生じさせることがない。

マクロの実行および再開機能は、マクロの開始および再開に使用可能である。たとえば、マクロ実行機能は、マクロの初期実行を開始することができる。いくつかのケースでは、マクロの実行にはユーザからの追加の入力を必要とする場合がある。このケースでは、マクロの実行を中断するか、または待機状態に入って、ユーザからの入力を保留することができる。ユーザ入力が提供されると、マクロ再開機能が、停止されていたマクロの実行を続行することができる。

スクリプト情報リポジトリ206は、スクリプト/マクロの作成、格納、取り出し、更新、削除などの動作を、提供および/またはサポートする、データストアの役割を果たすことができる。スクリプト情報リポジトリ206に格納されたスクリプトは、ユーザライブラリ、個々のスクリプト、またはアプリケーション(たとえば、電子メール、スプレッドシート、ワードプロセッシング文書などに関するアプリケーション)によって編成可能である。動作は、ユーザのライブラリ全体、またはライブラリ内の個々の要素上で、実行可能である。たとえば、1つの動作で、ユーザライブラリをそのID(たとえばライブラリの名前に基づいた主キールックアップ)によって取り出すことができる。他の動作で、マクロまたはスクリプトを表す文書などの、所与の文書にリンクされたすべてのユーザライブラリを取り出すことができる。

スクリプト情報リポジトリ206によって提供される取り出し動作は、所与のユーザライブラリ上の所与のユーザに関する認可の取り出し、所与のユーザが所有するすべてのユーザライブラリの取り出し、そのIDによる継続レコードの取り出しなどの、動作を含むことができる。

スクリプト情報リポジトリ206によって提供される作成/更新動作は、ユーザライブラリを作成/更新するための動作、ライブラリから抽象オブジェクトのキー(たとえば文書ID)への関連付けを作成するための動作、所与のライブラリ上の所与のユーザに関する認可を作成/更新するための動作、新しい継続レコードおよびライブラリを(たとえば所与のユーザに関するシリアル化されたバイナリデータを用いて)作成するための動作、ならびに、他の作成/更新動作を、含むことができる。

削除を実行するスクリプト情報リポジトリ206によって提供される動作は、継続レコードを削除する動作、ライブラリから抽象オブジェクトへの関連付けを削除する動作、ならびに、ライブラリを削除し、すべての子オブジェクトを除去し、認可およびリンク継続に関連付けられた子オブジェクトを含める動作を、含むことができる。スクリプト情報リポジトリ206の例示的論理構造については、図５を参照しながら以下で説明する。

スクリプトマネージャ204は、マクロサーバサブシステム202の基礎となる構成要素206から219にコマンドを委託することができる。特定の例示的コマンドの説明が続き、基礎となる構成要素206から219への委託制御パスは、一連の番号付プロセス矢印1から6でマーク付けされ、これは一般に時系列で番号付けされるが、あるアクションは可能であれば他の順序で実行可能である。

スクリプトマネージャ204が(たとえば委託によって)実行可能なコマンドの1つは、ユーザライブラリを格納するものである。このコマンドは、たとえばユーザの特権または他のセキュリティに基づいて、その実行を制限することができる。たとえば、ユーザライブラリ表現(たとえばプロトバッファまたはプロトコルバッファ)がライブラリIDを含む場合、スクリプトマネージャ204は、既存のユーザがライブラリを修正できることを保証することができる。認可が発生した場合、スクリプトマネージャ204はこれをストレージ層に書き込み、ライブラリの新しい表現を戻すことができる。IDが存在しない場合、新しいIDを作成し、この新しく生成されたIDを含む表現を戻すことができる。ライブラリの格納には、たとえば、ライブラリ内の機能の解析(たとえばスクリプト実行プログラム208を使用)、ライブラリDAOオブジェクトへの機能の追加、構文エラーの検出(たとえばスクリプト実行プログラム208を使用)、ライブラリコンテンツの格納、および所有者の格納を含むことができる。図2を参照すると、ユーザライブラリの格納に関与している構成要素は、たとえばプロセス矢印1、2、および6によって示すことができる。

たとえばプロトコルバッファは、ユーザライブラリ表現に使用される場合、ワイヤを介してシリアル化するか、またはデータベース内でバイナリ形式のままであることが可能な、データ構造を含むことができる。データ構造は、通信プロトコルを強化するために、強力に定型化されたフィールドを使用することができる。

スクリプトマネージャ204が実行可能な他のコマンドは、ライブラリのインポートである。このコマンドは、所与の文書(たとえば、スプレッドシート、電子メールカレンダ、または任意の他の添付可能コンテキスト)へのライブラリのリンクまたは他の関連付けを作成することができる。たとえば電子メールメッセージは、ユーザの所与のメールアカウントに関連付けることができる。リンクの目的は、たとえば「Run」メニューに表示するために、基礎となる文書が、どのマクロがリンクに関連付けられているかを即時に認識できるようにすることである。たとえば、ライブラリインポートコマンドは、データストア内に「Link」テーブルエントリを作成することができる。図2を参照すると、ライブラリのインポートに関与している構成要素は、たとえばプロセス矢印1および2によって示すことができる。

スクリプトマネージャ204が実行可能な他のコマンドであるコピーコマンドは、既存のライブラリをコピーし、そのコンテンツの複製を作成する。たとえば、ライブラリに含まれるすべてのスクリプトおよびマクロを、新しいライブラリ名にコピーすることができる。コピー動作はライブラリのコンテンツの複製を作成するが、関連付けはコピーされない。新しく作成されたライブラリの所有者は現在の所有者に設定される。コピー動作が完了すると、新しいライブラリのIDが戻される。たとえばコピーコマンドは、いずれのリンクを介したコピー、継続、または認可もなしに、データストア内に新しい「UserLibrary」テーブルエントリを作成することができる。図2を参照すると、ライブラリのコピーに関与している構成要素は、たとえばプロセス矢印1および2によって示すことができる。

ライブラリ削除コマンドは、たとえば許可をチェックした後、可能であれば、データストア(たとえばスクリプト情報206)からライブラリを削除することができる。たとえばライブラリ削除コマンドは、「UserLibrary」テーブルおよびすべての子テーブルからエントリを除去することができる。フロントエンドは、たとえば任意の「本当によいか？」の確認を実行する責務を負うことができる。ライブラリの削除に関与している構成要素は、たとえばプロセス矢印1および2によって示すことができる。

ユーザによってライブラリを取得するためのコマンドは、ユーザのIDに基づいて、所与のユーザによって所有されるライブラリを戻すことができる。たとえばコマンドは、所有者フィールドが現在のユーザである、スクリプト情報206に格納された(たとえばUserLibraryまたは他のテーブル内の)ユーザライブラリエントリを戻すことができる。図2を参照すると、ユーザに関するライブラリの取得に関与している構成要素は、たとえばプロセス矢印1、2、および4によって示すことができる。

文書によりライブラリを取得するためのコマンドは、所与の文書によってインポートされた任意のライブラリを戻すことができる。たとえば、ライブラリ取得コマンドは、一致する「文書化」フィールドに関するLinkテーブルをスキャンし、親「UserLibrary」を戻すことができる。図2を参照すると、文書に関するライブラリの取得に関与している構成要素は、たとえばプロセス矢印1、2、および4によって示すことができる。

ライブラリカテゴリ化コマンドは、「SAMPLES.」などの「仮想」文書への関連付けを追加することができる。たとえばライブラリカテゴリ化コマンドは、所与の名前(SAMPLESなど)を使用してLinkテーブル内にエントリを作成することができる。図2を参照すると、ライブラリのカテゴリ化に関与している構成要素は、たとえばプロセス矢印1および2によって示すことができる。

カテゴリに関するライブラリ取得コマンドは、所与のカテゴリ化を伴うすべてのライブラリを戻すことができる。たとえば、カテゴリに関するライブラリ取得コマンドは、文書に関するライブラリの取得と同様とすることができる。図2を参照すると、カテゴリによるライブラリの検索に関与している構成要素は、たとえばプロセス矢印1および2によって示すことができる。

機能評価コマンドは、ライブラリから機能を取り出し、実行のためにこれをスクリプト実行プログラム208に渡すことができる。図2を参照すると、機能の評価に関与している構成要素は、たとえばプロセス矢印1、2、3、5、および6によって示すことができる。

マクロ評価コマンドは、入力パラメータ(たとえばライブラリID、マクロ名、および、あれば現在の文書に関するコンテキスト情報)が提供された場合、ラッパーを用いてプログラムbeansを作成し、ラップされたサービスを実行のためにスクリプト実行プログラム208に渡すことができる。図2を参照すると、マクロの評価に関与している構成要素は、たとえばプロセス矢印1、2、3、5、および6によって示すことができる。

マクロ継続コマンドは、マクロライブラリIDおよび継続IDが与えられた場合、スクリプト実行プログラム208上の継続動作を呼び出すことができる。たとえば、こうしたコマンドは、一時停止された実行中のマクロに、アクティブな実行を継続させることができる。図2を参照すると、マクロの継続に関与している構成要素は、たとえばプロセス矢印1、2、3、および6によって示すことができる。

認可更新コマンドは、所与のユーザおよび所与のマクロライブラリに関する認可のセットについて、データストア内のエントリを更新(または追加)することができる。図2を参照すると、認可の更新に関与している構成要素は、たとえばプロセス矢印1および2によって示すことができる。いくつかの実装形態では、「ライブラリ取得」および他のコマンドは、通常、スクリプトストレージ層上のみで動作可能であり、スクリプト実行プログラム208を呼び出すことはできない。

次に、システム200の他の構成要素を参照すると、コマンドサーブレット216は、マクロコントローラ(たとえばJavaScript(登録商標)マクロコントローラ「MacroController.js」)からの要求に応答することによって、マクロコマンドを実行させることができる。応答は、ユーザに対してトランスペアレントかつ自動的であるリダイレクトなどの、リダイレクトとして発生可能である。例示的リダイレクト技法では、ブラウザクライアントが特定のURLに要求を行う時点で、リダイレクト規則は、その要求をマクロサーバサブシステム202などのマクロサーバにリダイレクトすることができる。コマンドサーブレット216が処理可能な要求のタイプは、たとえば、GET_ADMIN_PANEL、SET_SCRIPTなどの名前を備えた、いくつかの要求を含むことができる。

たとえば、GET_ADMIN_PANEL要求は、マクロ管理パネルの完全なHTMLを戻すことが可能であり、マクロコントローラ(たとえばMacroController.js)は、HTMLをクロージャダイアログに挿入することができる。SET_SCRIPT要求は、スクリプトコンテンツおよびユーザライブラリIDを、コマンドサーブレット216に送信することができる。コマンドサーブレット216は、ユーザライブラリを作成/更新するために、スクリプトマネージャ204を呼び出すことが可能であり、その結果としてパネルの左側(カテゴリおよびライブラリ名を含む)に関する(たとえばGXPによって生成された)HTMLを戻すことができる。macrocontroller.jsは、そのHTMLを、左側パネルに関するdivにレンダリングすることができる。

GET_SCRIPT要求は、ScriptManagerから所与のライブラリに関するスクリプトコンテンツをフェッチし、そのスクリプトを編集するための(GXPを介して生成された)コンテンツペイン(pane)を戻すことができる。macrocontroller.jsは、そのHTMLをパネルのコンテンツdivに入れることができる。

IMPORT_LIB要求は、ライブラリインポートコマンドを用いてScriptManagerを呼び出すことができる。この要求は、GXPを介してパネルの左側をレンダリングし、これをmacrocontroller.jsに戻すことができる。

COPY_LIB要求はIMPORT_LIBコマンドと同様であるものとすることができるが、インポートコマンドではなくコピーコマンドを使用する。DELETE_LIB要求はIMPORT_LIBコマンドと同様であるものとすることができるが、たとえばGXPを介して管理パネルHTML全体を戻すように、削除コマンドを使用することができる。CATEGORIZE_LIB要求は、「サンプルへの追加」機能として使用することができる。IMPORT_LIBと同様に、CATEGORIZE_LIBは、ライブラリカテゴリ化コマンドを使用してScriptManagerを呼び出すことが可能であり、再描画のためにパネルの左側を戻す。

RUN_MACRO要求はマクロ名、ライブラリID、および文書の状態のシリアル化表現(現行の選択など)を採用し、所与のマクロを実行するためにスクリプト実行プログラム208を呼び出すことができる。エラーが発生した場合、ユーザに表示するためにmacrocontroller.jsにエラーメッセージが戻される。ユーザがマクロを認可しなければならない場合、ユーザにプロンプトを出すために、メッセージをmacrocontroller.jsに返送することができる。

マクロサーバサブシステム202は、ネットワーク224を介してアプリケーション220および位置サーバ222と相互作用する。アプリケーション220は、ユーザのラップトップコンピュータ上で実行するウェブブラウザなどの、ユーザデバイス226を採用しているユーザによって実行されるアプリケーションとすることができる。ユーザデバイス226は、(たとえばスプレッドシートサーバを使用して)たとえばウェブページ226aを表示することができる。ユーザのウェブブラウザは、ユーザのユーザデバイス226上でのマクロの実行を制御するために、マクロコントローラ226bを採用することができる。

第3者プロセスおよびウェブページ228からの外部イベントは、マクロサーバサブシステム202内に定義されたマクロに関するトリガメカニズムとしての役割を果たすことができる。外部イベントは、インターネットなどのネットワーク230を介して受信することができる。ここでの外部イベントは、図1に関して説明された外部イベント105に対応することができる。

内部イベントに加えて、位置受信器218によって受信される位置情報などの外部イベントは、イベントサーブレット214によって追跡およびレポートすることができる。イベントサーブレット214は、システム200内で発生するイベントに対して通信ハブとしての役割を果たすサーバベースのイベントレジストリを実装することができる。

イベントレジストリには、システム上で実行中の、マクロ関係プロセスなどの関係プロセスまたは加入プロセスによってアクセス可能であり、あるイベントが発生した場合にプロセスをインスタンス化できるように、こうしたプロセスに警告を与えることができる。そのためにイベントレジストリは、イベントの消費者によって呼び出し可能なメソッドを提供する。イベントレジストリは、「listen」メソッド、「unlisten」メソッド、および、イベントを管理するために使用可能な他のメソッドなどの、様々なメソッドを公開することができる。

listenメソッドは、システム内でのイベント監視および追跡のための基準としての役割を果たし、ユーザ名、イベントフィルタ、およびターゲットなどの引数またはパラメータを有することができる。したがって、listenメソッド呼び出しのフォーマットの一例は以下のようになる可能性がある。
listen(userName, eventFilter, target);

listenメソッドの呼び出しは、認証されたユーザ(たとえば「userName」によって識別されたユーザ)に代わって特定のイベントを監視するように、および、それらが発生した場合、それらを1つまたは複数の指定された(たとえば「ターゲット」パラメータによって識別された)ターゲットにルーティングするように、イベントレジストリに通知することができる。特定のイベントは、たとえばイベントフィルタ(たとえば「eventFilter」パラメータ)によって識別することができる。イベントフィルタは、サービス識別子(たとえば電子メールサービス、カレンダサービスなど)および他のサービス固有のフィルタ(たとえば「電子メール受信」、「フォルダ作成」など)を含むことができる。ターゲットは、たとえばリモート手続き呼び出し(RPC)コールバックとすることができる。たとえば、イベントが始動または発生した場合、イベントレジストリはイベント細部をこのエンドポイント(たとえばターゲット)に送信することができる。いくつかの実装形態では、ターゲットは、イベントがトリガした場合、どのマクロを実行するかを識別する識別子を備えたマクロサーバサブシステム202の構成要素とすることができる。

対応する「unlisten」メソッドを使用して、イベントに関する通知を受信する旨の要求を取り消すことができる。unlistenメソッドを呼び出すための呼び出しは、以下のような形を取ることができる。
unlisten(userName, eventFilter, target);
unlistenメソッドを呼び出すことは、「リスナー(listener)」の取り消しまたは停止と等価であるものとすることができる。再度、このコマンドに関するパラメータは、第1の場所でのイベントに関するイベント監視を開始するために使用されたはずのパラメータをミラーリングする。

イベントサーブレット214によって、複合イベント条件を適用することもできる。たとえば、着信電子メールが到達し、電子メールの受信者または送信者がある位置に居た場合にのみ通知をトリガするように、イベントフィルタを定義することができる。こうした複合標準は、別のマクロ、たとえば、電子メールの到達によってトリガされ、その後受信者または送信者の位置に関して位置サービスをチェックし、位置が特定の値と一致した場合のみ実行を継続するマクロによって、実装可能である。標準は、マクロの実行を開始するよう加入サービスに通知する前に、複合条件が合致したかどうかを特定するための情報を収集するために、サーブレット214が実行できるプロセスを提供することなどにより、イベントサーブレット214によっても実装可能である。

ある状況では、イベント条件は、カスケードまたは連続様式などで互いに整合することができる。たとえばイベントの発生は、イベントサーブレット214がスクリプトマネージャ204にメッセージを送信することによって、マクロの開始をトリガすることができる。次のそのマクロは、イベントサーブレット214で定義された他のイベントを関係させる出力を実行および提供することができる。それに応じて、イベントサーブレット214は、スクリプトマネージャ204に異なるマクロを開始させる旨の他のメッセージをスクリプトマネージャ204に送信することができる。同様にして、単一のイベントが、2つの異なるマクロの実行を同時にトリガすることができる。たとえばユーザは、ユーザのアカウントによる任意の電子メールの受信に応答して(たとえば、電子メールから対象情報を取り去り、その情報をスプレッドシートに配置するために)、一方のマクロを実行させ、(サブシステム202を動作させるシステムおよび組織とは別個とすることが可能な)ソーシャルネットワークシステムにおいて第1のユーザの友人であると定義されたユーザが、第1のユーザからある一定の距離内にいる場合、その友人から電子メールが受信されると必ず、他方のマクロを実行させることを、希望する場合がある。したがって、こうした位置に居るこうした友人から電子メールが着信した場合、両方のマクロを同時に並行してトリガおよび実行することができる。

イベント通知は、いくつかの異なる方法で開始することができる。たとえばイベント通知は、プログラムで開始することができる。いくつかの実装形態では、イベントレジストリにイベントタイプをプログラムで登録する、「インストーラ」スクリプトまたは他のプログラムコードを作成することができる。たとえば、企業内のパッケージ追跡アプリケーションは、展開または初期インストール時に、顧客にパッケージが到着したこと、パッケージが発送されたこと、送料を受け取ったこと、商品がX地点まで輸送されたことなどを通知するように動作可能なメーリングリスト上に、イベントリスナーを登録することができる。スクリプトライブラリ(たとえば、パッケージ追跡スクリプトライブラリ)内の追加のアクションは、そのメーリングリスト上で動作が検出された場合に、自動的に実行可能である。このプログラムでの開始例では、イベント監視(listening)が、パッケージ追跡アプリケーションのインストールの一部など、前もって確立されているため、イベントリスナーを「設定する(rig up)」ためのエンドユーザの介入がほとんどまたは全く不要である。いくつかの実装形態では、リスナーを調整するため、または新しいリスナーを定義するために、追加のユーザインターフェースを提供することができる。

イベント通知を開始するための他の例示的メカニズムでは、ユーザがイベントタイプと特定のスクリプト呼び出しとを結び付けられるようにするために、イベントを提供するターゲットアプリケーションが、それ自体のインターフェースを作成および公開することができる。たとえばいくつかの電子メールアプリケーション(たとえばAppleのMail.app)は、特定のイベントの発生時にアプリケーション(たとえばAppleScript)を実行するように指定するためなどに、ユーザが採用可能なカスタムフィルタを使用することができる。他のアプリケーション(たとえばGmailなど)は、ユーザが、電子メール属性基準(たとえば、電子メールが文字列ABCを含む、電子メールが特定のアドレスから/アドレス宛であるなど)、および実行されるアクション(たとえば、電子メールのアーカイブ、電子メールのラベル付け、アドレスXYZへの転送など)を定義可能にする、フィルタを含むことができる。同様に、Gmailは、ユーザが、特定のフィルタ基準に合致した場合に実行されるアクションのうちの1つとして、「スクリプトXYZを実行」をオプションで追加可能にすることができる。他のアプリケーションは、スプレッドシートに対する変更のダイジェストを(ユーザに)電子メール送信するように動作可能な、Google Spreadsheetsの変更通知サービスなどの、同様の機能を使用することができる。いくつかの実装形態では、電子メールの送信ではなく、またはこれに加えて、マクロ呼び出しの追加オプションを提供することができる。

イベント、ユーザおよびユーザアカウント、イベントフィルタ、ならびにイベントレジストリに関連付けられたターゲットを管理するための、他のメソッドも存在し得る。たとえばユーザは、getRegisteredListenersForUserメソッドを使用することで、それらのアカウントが現在イベント監視しているすべてのイベントに関する情報(たとえばそれらのリスナーのリスト)を取得することができる。この情報は、たとえば管理パネルまたは他のユーザインターフェース内に表示することができる。他のイベント管理メソッドは、特定のuserName、eventFilter、またはターゲット、あるいはそれらの組み合わせに関する情報を提供するためのメソッドを含むことができる。

イベントサーブレット214によって実装されるイベントレジストリは、ユーザ/リスナーのペアのデータベースを維持することができる。「listen」メソッドまたはコマンドを受信すると、たとえばイベントレジストリはサービスフィルタをアンパックし、対応するサービスにメッセージを送信することができる。

各サービスは同様の「listen」メソッドで、ユーザの証明およびイベントフィルタを含む、RPCエンドポイントを公開することができる。サービスのターゲットは、イベントレジストリ自体とすることができる。たとえばサービスは、条件がイベントフィルタを満たす旨をサービスが内部的に検出した場合、イベントレジストリにイベントを送信することができる。プロセスのこの部分の(各サーバによる)内部実装は、特定のサーバに任せることが可能であるため、システムのこの部分のいかなる特定の内部実装も義務付けることはない。したがってイベントブロードキャスタは、この契約をそれらに好適なように実装可能である。

イベントレジストリによってイベントが登録(または検出)された場合、イベントレジストリは、そのデータストレージからターゲット情報をアンパックすること、およびイベントの通知をすべての関連ターゲットに送信することについて、責務を負う。通知は、イベント自体の識別と、ターゲットが必要とする可能性のある任意の他の関連情報とを含むことができる。いくつかの実装形態では、メインターゲットをマクロサーバサブシステム202とすることができる。いくつかの実装形態では、たとえば通知サービス、ロギングサービス、ウェブサービス、その他を含む、他のターゲットを使用することができる。

いくつかの実装形態では、システムは、異なる構成要素に関する設計の考慮点を互いに分離するように設計することができる。たとえば、イベントレジストリはターゲットについて知っているが、イベントブロードキャスティングサービスは知らないものとすることができる。さらにイベントブロードキャスティングサービスは、イベントフィルタの適用方法(たとえば「電子メールが送信された」、「スプレッドシートセルが更新された」、「アイテムがフォルダに入れられた」)を知っているが、イベントレジストリは知らないものとすることができる。たとえば、イベントレジストリのみが、(たとえばターゲットに関する)サービスエンドポイントの配置方法を知っているものとすることができる。この設計の分離によって、第3者などの将来の参加者がシステムのエンドを自由に実装できる特典を与えることができるが、N個の可能なターゲットへのルーティングの詳細について心配する必要はない。

移送メカニズムに関して、実装形態は、API呼び出し、ネットワーク移送プロトコルなどに関する任意の適切なメカニズムを使用することができる。たとえばイベントレジストリの何らかの第3者の参加者は、多くの外部API呼び出しに対して様々なウェブサービス(たとえば「SOAP」)を使用することができる。他の参加者は、Representational State Transfer (REST)または他の好適なAPIを移用することができる。サブシステム202を提供する組織などの他の参加者は、所有権を主張できるネットワーク転送プロトコルを内部的に使用することができる。これらの各メカニズムまたは本明細書では列挙されていないその他のメカニズムは、イベントフローのコンテンツおよびセマンティクスを保持することができる。

いくつかの実装形態では、ユーザの認証に使用される方法が、一方のアプリケーションが他方のアプリケーション上のユーザのデータにアクセスできるようにするための、たとえばOAuthまたは任意の他の適切なオープン標準を含むことができる。たとえば、ユーザがパスワードまたは他の特定の証明を提供する必要なしに、アクセスすることができる。具体的に言えば、OAuthまたは同様の方法メソッドを使用する場合、ユーザはイベントレジストリが様々なオープンアプリケーションにおいてイベントサブシステムを呼び出せるようにすることができる。この呼び出しは、それぞれのサービスが認識できるトークンを使用することができる。結果として、認証は、ユーザのために(たとえばユーザの許可なしに)電子メールを送信するなどの、他のサービスへのアクセスを禁止しながら、たとえばイベントシステムに限定することができる。

各イベントのコンテンツ(または「イベントデータ」)は、たとえば属性/値のペアのセットを含むことができる。たとえば、属性の標準セットは、一般にすべてのアプリケーションについて定義可能である(「ユーザ」および「サービス」など)。さらに、各アプリケーションはそのサービスに固有の追加の属性を定義することができる。たとえばスプレッドシートアプリケーションは、属性「スプレッドシートセル」、非スプレッドシートアプリケーションにとっては有用ではない属性を定義することができる。

いくつかの実装形態では、一部またはすべてのフィルタリングが、参加サービス内のみではなくイベントレジストリ内で、またはその2つの混合で、発生可能である。こうしたケースでは、参加サービスは、リスナーのそのストアに基づいてイベントフィルタリングを実行することになるイベントレジストリに対して、すべてのイベントを盲目的に始動することが可能である。レジストリベースのフィルタリングは、参加サービスにおけるフィルタリングを簡略化または消去することが可能であるが、こうした手法は、一部のインスタンスでシステムを過飽和状態にする可能性がある。

ここでシステムは、マクロレコーダをインスタンス化すること、マクロレコーダによって追跡されるいくつかのアクションを実施すること、およびアクションの自動的な実行のためにユーザが後で呼び出すことが可能なそれらのアクションの表示を保存することによって、ユーザがマクロを記録することを許可することもできる。本実装形態では、マクロ記録は、通常、サーバ側で実行することができる。ユーザが記録可能コマンド(たとえば、セル値の設定、シートの挿入など)を実行する場合、コマンドをスプレッドシートサーバに送信することができる。そのサーバは、「記録」モードにあるか否かに注目し、「記録」モードにある場合、コマンドを探索し、同じ効果を有することになるスクリプティングコードに対応する実行中の文字列バッファに、テキストを書き込むことができる。

たとえば、ユーザがスプレッドシートのセルA1に「hello」と入力した場合を考えてみる。コマンドは、「range設定」、値「hello」、行0、列0、およびシートID 0(第1のシートの場合)を意味するコマンドIDと共に、スプレッドシートサーバに送信可能である。これはレコーダ向けのみではなく、スプレッドシートサーバ上のセルに対して実際に変更を行うコマンドであるため、このコマンドは記録が行われるか否かに関わらず送信されることに留意されたい。したがってレコーダは、本質的に、スプレッドシートを動作させる既存のコマンドフロー上のワイヤタップ(wiretap)と等価であるものとすることができる。

レコーダは、コマンドIDを探索し、「range設定」コマンドであることがわかる。生成すべき適切なコードが「range」オブジェクト上の「setValue」呼び出しであることがわかると、レコーダは、対応するテキストを生成するための行および列を探索し、使用することができる。次にレコーダは、シート識別子を探索および使用して、そのシート用の変数がすでに存在するかどうかを判別することができる。結果として、マクロレコーダは以下のようなテキストを生成することができる。
sheet.getRange(‘a1’).setValue(‘hello’); (2)

したがって、これらの構造により、コンピュータユーザはホスト型コンピュータサービスにログオンし、いくつかの異なるアプリケーションおよびサービスにアクセスすることができる。ユーザはマクロの実行を明示的に選択できるか、またはマクロを自動的にトリガすることが可能であり、マクロは、アプリケーション内、およびマクロによって参照された場合に自動的にインスタンス化可能な他の関連アプリケーション内で、実行可能である。結果としてユーザは、ロバストオンラインサービスを生成するための多種多様なデータおよびプログラミングメカニズムにアクセスすることができる。

図3Aは、ホスト型コンピューティングシステム上でマクロを実行するためのプロセス300の流れ図である。プロセス300は、たとえばシステム100および200内でマクロを実行するために使用することができる。一般に、図示されたプロセスは、関連マクロコードの識別、コードを実行するためのオブジェクトの作成、および、ホスト型コンピュータシステム上の1つまたは複数のアプリケーションと相互作用するためのコードの実行を含む。

この例のプロセス300はボックス302から開始され、ここでマクロを実行するためのコマンドが受信される。コマンドは、図1に関して説明されたような外部イベント105の結果とすることが可能であるか、またはユーザが実行するマクロを手動で選択することが可能である。たとえば前者の場合、外部イベント105は電子メールの受信とすることが可能であり、実行するように命令されたマクロは、電子メールの件名欄を備えたスプレッドシートの更新などの、電子メールの受信に応答して動作を実行するためのマクロとすることができる。マクロフック104は、外部イベント105の検出に関与し、マクロサーバサブシステム106との通信などにより、実行すべきマクロをトリガする責務を再度負うものとすることができる。

ボックス304では、マクロコードが識別、取り出し、および実行される。たとえば図2を参照すると、スクリプトマネージャ204は、スクリプト情報206に対して、実行すべきマクロコードを識別することができる。次にスクリプト情報206は、要求されたマクロコードをスクリプトマネージャ204に戻し、次にこれがその実行を開始することができる。

マクロコードの実行の一部として、マクロが相互作用するアプリケーションに関するプログラムAPIを表すJava(登録商標)オブジェクトを有するインスタンスが作成される(ボックス306)。APIは、マクロコードが相互作用するアプリケーションに対応するものとすることができる。たとえば、スプレッドシートを更新するようにマクロコードが設計された場合、作成されるインスタンスは、対応するスプレッドシートアプリケーションに関するプログラムAPIを表すJava(登録商標)オブジェクトを含む。

オブジェクトは、ボックス308でセキュリティラッパー内にラップされる。たとえばセキュリティラッパーは、たとえばユーザによる積極的なアクションが取られない限りマクロコードを実行させない、マクロコード自体を囲む追加のコードとすることができる。いくつかの実装形態では、アクションは、「OK」をクリックするか、または何らかの他の方法でマクロを明示的に承認するものとすることができる。

セキュリティラッパーは、トロイの木馬からの攻撃、フィッシング攻撃、または他の悪意あるコードなどから、様々な方法でエンドユーザを保護することができる。いくつかの実装形態では、セキュリティラッパーは、ユーザにダイアログボックスを送達した後に構築することができる。ダイアログボックスに含まれるメッセージは、潜在的に信用できないマクロとしてマクロを識別し、さらにマクロが実行された場合に何が起こり得るかを識別することができる。いくつかの実装形態では、ダイアログボックスは、そのマクロに特有の潜在的に有害な動作のリストを識別することが可能であり、このリストはマクロのスキャンに基づいている。マクロのスキャンは、たとえば、マクロ内のテキスト文字列、または悪意あるものであった過去のマクロのコンテンツに対応する何らかの他の情報に、部分的に基づき、特有の潜在的に有害な影響を識別する際の一助となることができる。

ユーザは、マクロが有することのできるアクセス権を承認または不承認することができる。ユーザの承認を使用して、マクロに特権を読ませることはできるが、マクロにあるファイルを更新させることはできないような、上記で参照された機能ベースのセキュリティラッパーを構築することができる。このケースでは、ユーザによってマクロに付与され、セキュリティラッパー内で反映される特権または権利は、ユーザが承認したタイプのアクションに限定される。

いくつかの実装形態では、セキュリティラッパーを生成するためのプロセスは、悪意あるコードを検出するためのメカニズムを誤らせようとする悪意あるコードを検出することができる。たとえば、マクロ内に「delete(削除)」とコーディングする代わりに、真の削除動作の意図(たとえば「delete」)を隠すための試行において、従属文字列「de」および「lete」を連結することができる。ここで説明されるプロセスは、こうしたインスタンスを識別し、ユーザがマクロに対して削除承認を付与しなかった場所での削除を防ぐように、プログラミングすることができる。

ボックス310では、マクロの宛先である各アプリケーションに関する関連サーバへの呼び出しが実行される。この呼び出しは、マクロが相互作用するアプリケーションに関連付けられたメソッドまたは他のプログラムAPIを含むオブジェクトの実行を含む。たとえば呼び出しは、スプレッドシートを更新し、電子メールを転送し、ファイルをコピーするなどの、マクロコードの実行を含むことができる。

次に、各アプリケーションからのフィードバックおよびアクセスサービスとの相互作用が発生する(ボックス312)。たとえば相互作用は、マクロが動作したばかりのアプリケーションとのユーザ相互作用を含むことができる。ユーザは、たとえば、他のユーザからの電子メールをマクロが転送した結果として、ユーザが受信したばかりの電子メールを読む(および他の相互作用を実行する)ことができる。

このようにして、マクロは、システム内の別個のサブシステム上で動作する複数のアプリケーションにまたがって、中央システム上で実行することができる。マクロはセキュリティメカニズムを含むことが可能であり、様々な様式でトリガすることができる。加えて、マクロは、システム内で、またはインターネットなどのネットワークを介して他のシステムからアクセス可能な、多様な異なるサービスから情報を取得することができる。

図3Bは、イベントトリガされたマクロを管理するためのプロセスの流れ図である。一般に、プロセスは、ある基準に合致する将来のイベントで通知されることになる要望を示すように、エンティティがイベントレジストリに加入する、第1の段階と、イベントがその間に発生し、イベントレジストリが適切なエンティティに通知する、第2の段階との、2つの段階を含む。こうした段階は、どちらもプロセス中にほぼ連続的に発生し、エンティティが新しい加入を登録する一方で、他のエンティティには、以前に登録された加入を対象とするイベントに関して通知される。

プロセスはボックス320から開始され、ここでイベントレジストリは、イベントに参加する意図についての通知をエンティティから受信する。この通知は、マクロの実行を管理するためのアプリケーション(たとえば図2のスクリプトマネージャ204)とイベントレジストリとの間でのリモート手続き呼び出しなどの、多様な形で着信可能である。この通知は、前述のように、ユーザ名、イベントフィルタ、およびターゲットを含むことができる。ユーザ名は、イベントレジストリを動作させるホスト型コンピュータシステム内のユーザアカウントに関する識別子に対応可能であり、ターゲットは、イベントレジストリによってトリガイベントが識別された場合に通知が送信されることになるアドレス(たとえばURL)を表すことが可能であり、イベントフィルタは、ターゲットに通知が提供される前にイベントが満たさなければならない1つまたは複数の条件を表すことが可能である。通知を提供するエンティティは、ユーザが特定のイベントによってトリガされることになるマクロを確立した場合、マクロがイベントの発生時に実行されるように、特定のマクロを対象とするターゲットを含む通知をイベントレジストリに対して提供することが可能な、スクリプトマネージャ204を含む、いくつかのエンティティのうちのいずれかとすることができる。

ボックス322で、レジストリは加入エンティティを登録し、イベントに関する通知パラメータを保存する。登録は、通知で受信されたパラメータに関する保存情報を含むことが可能であり、ユーザが、イベントレジストリによってエントリに関する情報にアクセスおよび情報を変更できるように、システムの登録ユーザとこうした情報を関連付けることを含むことが可能である。残りの情報は、特定のイベントがどのエントリに関連しているかを判断するためにイベントが発生した場合に検索できるように、イベントレジストリが容易に利用可能な位置に格納することができる。

あるインスタンスでは、イベントレジストリは、レジストリ内のエントリに関連付けられたイベント生成サービスに加入することができる。たとえば、イベントレジストリは、電子メールアプリケーションなどのサーバベースのアプリケーションにユーザ識別を提供することが可能であり、特定のユーザアカウントに関するあるタイプのイベントをレポートすべきである旨をアプリケーションに伝える。たとえば、イベントレジストリは、ユーザJohn Doeに関する着信メッセージに関するイベントをレポートするよう電子メールアプリケーションに通知することができる。このようにして、アプリケーションは、イベントをレポートするタイミングを知ることが可能であり、直面しているすべてのイベントをイベントレジストリに提供する必要はない。

プロセスの第2段階はボックス326から開始され、ここでイベントレジストリはイベント生成サービスからの通知を受信する。たとえば電子メールアプリケーションは、特定ユーザに関する着信電子メールの形でイベントを示すことができる。この指示は、単に電子メールアプリケーションへの加入時にイベントレジストリが与えた識別番号の形を取ることが可能であり、イベントレジストリはこの番号を使用して、通知が必要な基礎となる登録を探索することができる。最初の登録時に定義された情報などの他の情報を渡すことも可能であり、イベントレジストリはこうした情報を、スクリプトマネージャ204などの加入エンティティに渡すことができるため、イベントによって実行がトリガされるマクロは、この情報に容易にアクセスすることができる。代替としてマクロは、情報を単独で、およびアプリケーションから直接、取得するようプログラミングすることができる。イベントレジストリは、こうした通知を待つ連続イベント監視モードとすることが可能であり、多くのこうした通知を多くのサービスからほぼ同時に処理することが可能であり、マクロまたはマクロ管理サービスを含む多くの異なる加入エンティティに通知をレポートすることが可能である。

ボックス328で、イベントレジストリはレジストリへのすべての加入に対する通知をテストする。通知が単一の識別番号である場合、イベントレジストリは、その番号を、加入エンティティによってイベントレジストリに最初に提供された情報などの情報を含むデータ記録と相関させる、探索を実行することができる。次にこうした情報(たとえばターゲットアドレス)を使用して、加入エンティティに通知することができる(ボックス350)。

このようにして、プロセスは好都合なことに、マクロを実行するためのメカニズムを、自動的に、およびクライアントデバイスまたはユーザステータス(たとえば、ユーザが現在ホスト型システムと相互作用できるかどうか、および、ユーザが現在システムにログインしているか否か)とは無関係に、ユーザに提供することができる。

図4Aは、ウェブページ上で実行しているアプリケーションから呼び出されたマクロを実行するためのプロセス400の流れ図である。一般にプロセスは含む。一般に、図4Aに示されたプロセスは図3Aに示されたプロセスと同様であり、複数構成要素システム内の異なる構成要素間でプロセスを共有することが可能な方法の例を示す。

例示的プロセス400は、ブラウザ401aとマクロサーバ401bとの間の相互作用に対応するステップを含む。たとえばプロセスのブラウザ側での相互作用は、スプレッドシートアプリケーションを実行中のクライアントデバイスを採用しているユーザを含むが、実行されるマクロは、マクロサーバ401bなどのデータサーバシステムで実行する(およびこれによってデータを取得する)ことが可能である。ブラウザ側に示されたプロセス400のステップは、ユーザと(たとえばスプレッドサーバシステムにより提供される)スプレッドシートアプリケーションとの間で行うことが可能な、一般的な相互作用に加えられるものであり、マクロとは無関係である。マクロサーバ側で実行されるプロセス400のステップは、たとえば、マクロサーバサブシステム202によって実行可能である。プロセス400は、図1および2に関して上記で説明されたシステム100および200上でのマクロの実行を表すこともできる。一般に、マクロサーバ401b側でのプロセス400のステップは、スクリプトマネージャ204によって制御可能である。

ボックス402で、マクロを実行する旨の要求が行われる。たとえばこの要求は、クライアントデバイス上でブラウザアプリケーションを実行しているユーザによって発信することができる。ユーザがマクロの実行をトリガするためにキーの組み合わせを実行することが可能であるか、あるいは、アプリケーション内の特定の文書を開くこと、アプリケーション上での制御のユーザ選択、または、サブシステムによって受信される外部信号によるなどのユーザとシステムとの相互作用とは別のメカニズムによって、実行を開始することが可能である。

ステップ404で、マクロの実行が開始される。この開始は、たとえばマクロサーバサブシステム202内で発生可能である。たとえば、クライアントデバイスによって渡されるかまたは識別されることが可能なアドレスに対応するマクロコードは、サブシステム上にロード可能であり、その実行は通常の様式で開始可能である。

ステップ406で、ユーザがマクロを実行するための認可を与えたかどうかが判別される。こうしたアクションは、マクロコード実行の開始時に発生可能である。たとえばユーザ認可は、前述のように悪意あるコードが実行されるのを防ぐための実践の一部とすることができる。

ユーザ認可が存在しない場合、ステップ410でユーザ認可要件がフェッチされ、ステップ412でユーザに対して認可に関するプロンプトが出される。ユーザがステップ414で認可を与えた場合、ユーザの認可はステップ416で格納され、与えない場合、プロセス400はステップ418で終了する。ユーザ認可要件は、たとえば、マクロの実行が許可された場合に発生する可能性がある、悪意ある結果のタイプのリストを含むことができる。このリストは、ステップ412でユーザに提示することができる。

ユーザ認可が存在する場合、ステップ408でラップサービスが作成される。ラップサービス(または「beans」)は、たとえばラップサービス作成プログラム212によって作成可能である。こうしたアクションはオプションとすることが可能であり、前述のように、悪意ある干渉から実行コードを保護するために使用可能である。

スクリプト(またはマクロ)は、ステップ420で、スクリプト実行プログラム内で実行される。たとえば図2を参照すると、スクリプトはスクリプト実行プログラム208によって実行可能である。この実行は、マクロの実行がクライアント上でローカルに行われるのとは対照的に、たとえばマクロサーバサブシステム202内で行われる。スクリプト実行は、通常の様式で行われることが可能であり、サブシステムの一部がスクリプト内のステップを実行していき、各ステップが満たされるとそれらのアクションを実行する。
ステップ422で、継続に遭遇したかどうかどうかが判別される。遭遇した場合、その継続はステップ428で格納される。継続は、実際には、特定の時間またはイベントが発生するまでスクリプトを一時停止するために使用することができる。継続に遭遇しない場合、処理はステップ424で再開され、ここで、エラーに遭遇したかどうかが判別される。エラーに遭遇しなかった場合、マクロの実行はステップ430で正常に終了する。ステップ424でエラーに遭遇した場合、ステップ426でユーザに警告が出された後、ステップ430でマクロの実行が終了する。
したがってこのプロセスにより、クライアントデバイス上のユーザによる(または他のイベントによる)アクションからトリガされたマクロによって提供された機能が、ユーザに提供され、マクロはクライアントデバイスとは別のサブシステム上で実行可能である。いくつかのインスタンスでは、ユーザがオンラインでない場合に実行が発生可能であり、ユーザと、システムに登録された他のユーザとが、このマクロ実行の結果を使用することができる。

継続は、実行を後で再開できるように実行をフリーズさせる、スクリプトインタプリタの実行状態の「スナップショット」としての役割を果たすことができる。これは概念上、デバッガ内でブレークポイントがどのように動作するか、または、標準的なブラウザ側の実行における「警告」呼び出しと同様である(たとえばJavaScript(登録商標))。継続は、インタプリタ内のすべてのオブジェクト(たとえばすべてのローカル変数および「beans」)のバイナリシリアル化、および現在の実行ポイントを示すポインタとして実装可能である。継続は、継続を公開された機能として実行することを可能にしうる、スクリプト実行プログラム208内で実装可能である。すべてのオブジェクト(たとえば「beans」を含む)は、たとえばJava(登録商標)の標準機能であるJava(登録商標)シリアル化を使用して、スクリプト実行プログラム208によってシリアル化することができる。オブジェクト(およびそのすべての子オブジェクト)は、Java(登録商標)シリアル化を使用して、オブジェクト識別子とすべてのフィールドの現在の値とを含むバイナリストリームに書き出すことが可能である。マクロが再開された場合、スクリプト実行プログラム208に、たとえば新しいライブJava(登録商標)オブジェクトへの非シリアル化で使用可能な継続バイナリデータが与えられる。

いくつかの実装形態では、継続はデータベースに格納可能である。継続は、たとえばマクロが再開されるまで、サーバメモリ内ではなくデータベース内に格納される。データベースに格納される理由の1つは、継続がトリガされた時点からユーザが実行を再開する(たとえばダイアログ上で「OK」ボタンを押すか、または何らかの他の再開アクションによって)時点までの間にサーバが再開できるためとすることができる。いくつかの実装形態では、継続は所定の存続期間(たとえば6時間)を有することが可能であり、その後、廃棄されてもよい。この場合、継続は、ユーザが「OK」ボタンを押すために動き回ることが決してない場合のように、ディスクスペースを占有し続けることがない。

図4Bは、ホスト型システム上でマクロを記録および実行するためのプロセスを示すスイミングレーン式流れ図である。例示的プロセス431は、ブラウザ、マクロレコーダ、マクロサーバ、およびアプリケーションの間の相互作用を含む。一般にプロセスは、サーバサブシステムからユーザにマクロ記録コントロールのセットを提供し、これによってユーザは、ユーザおよびシステムによって行われたアクションを記録しなければならないタイミングを示すために、コントロールを使用することが可能であり、次にこうしたアクションは、マクロが呼び出された場合にアクションを再実行するマクロに関するコードに再フォーマット化することができる。

プロセスはボックス432から開始され、ここでユーザによってマクロレコーダが選択される。選択は、たとえばユーザがマクロの記録を開始するためのコントロールを選択した場合、ブラウザ上で行うことが可能である。マクロレコーダはステップ434で処理される。マクロレコーダはユーザのブラウザ上で実行可能であるか、またはマクロサーバサブシステム202などでリモートに実行可能である。マクロレコーダは、たとえば現在ユーザのクライアントデバイス上にアプリケーションを表示しているウィンドウとは別のボーダレスウィンドウ内に表示することができる。レコーダは、iFrame、またはアプリケーションを表示している同じページの一部である同様の要素などの、他の方法で処理することができる。

ステップ436で、マクロレコーダはアプリケーションで表示される。たとえば、ユーザが自分のラップトップコンピュータ上の自分のブラウザ内でスプレッドシートアプリケーションを実行している場合、ポップアップまたは他の表示が現れ、マクロレコーダを示すことができる。マクロレコーダは、ユーザが選択可能な記録、一時停止、および停止のボタンなどの、レコーダの動作を制御するための様々なコントロールで表示することができる。記録はステップ438で開始され、すなわちユーザは、マクロを定義するキーストロークなどを開始することができる。こうした記録は、レコーダを表示するコードを介してレコーダを処理するサーバサブシステムに、ユーザがレコーダ上で記録コントロールを選択した旨を示すメッセージを送信することによってトリガ可能である。

ステップ440で、ユーザはアプリケーションと相互作用し、すなわちユーザは、ユーザによって使用されているアプリケーション内でマクロ機能を定義するための動作(キーストローク、選択など)を実行する。たとえばユーザは、スプレッドシート内のセルのレンジを選択すること、それらのセル上で(たとえばそれらをコピーアンドペーストするため、それらに公式を入力するためなどの)コマンドを実行すること、および、他のそうしたアクションを実行することが、可能である。

ステップ442で、ユーザがアプリケーションと相互作用している間に、マクロレコーダは、記録プロセス中にユーザによって記録されるコマンドを表示することを含むことが可能な、ユーザのアクションの記録を開始する。前述のように、レコーダは、アプリケーションが解釈するのと同様に、ユーザの入力を解釈することが可能であり、その後、こうした解釈済みのアクションを、実行された場合、マクロが後にアプリケーションに送ることが可能なコマンドに変換することができる。レコーダは、内部でユーザがコマンドを実行するアプリケーション(たとえばブラウザウィンドウ)を追跡することも可能であるため、マクロは、実行された場合、それらの様々な異なるアプリケーションへコマンドを提供することを知ることができる。

ユーザがアプリケーションと相互作用している間、アクションは記録され、ステップ444でユーザのアクションの標準的な実行が提供される。実行は、ユーザが相互作用しているアプリケーション内で行うことが可能である。したがって、アクションが記録されるように、またさらに、アプリケーションが適切な様式でアクションに反応するように、ユーザのアクションをアプリケーションとマクロレコーダとに並行して提供することが可能である。

マクロの定義が完了すると、「完了」キー、レコーダ内の「停止」ボタン、または他のコントロールを押すことなどによって、ユーザからの保存コマンドが受信される。ステップ448で、マクロに関する情報が送信される。こうした情報は、ユーザによってコマンドが実行された場合の記録時に、マクロコマンドに解釈するか、または、マクロ記録が停止した場合に解釈および変換することが可能である。次にマクロレコーダは、たとえばマクロストアに情報を送信し、後にコードに容易にアクセスできるように、マクロコードを示す1つまたは複数のポインタ(たとえばURL)を生成することができる。たとえばマクロレコーダは、後にマクロを起動するために使用されることになるキーの組み合わせを識別するよう、ユーザに要求することができる。

ステップ450で、ライブラリ名(マクロの保存先)、(マクロレコーダによって記録された)スクリプトまたはマクロコンテンツ、およびユーザIDを含む、マクロ情報が保存される。他の情報も保存し、適宜マクロと相関させることができる。

その後、しばらく後、または数日から数年後のいずれかに、ユーザがマクロの実行を決定した場合、ユーザは実行するマクロを指定することができる。マクロの選択は、たとえば、ユーザが現在相互作用しているアプリケーションに関して定義されたマクロのリストからマクロ名を選択することによって、達成可能である。たとえば、ユーザがアクセス可能なマクロのリストは、ユーザのアカウントに関連付けて格納可能であり、ユーザに対して(各マクロの製造元がマクロに関して理解しやすい名前を提供した)リストで表示することが可能である。代替として、マクロの選択は、他のマクロの実行によって、特定のユーザによるアクションとは無関係なシステム上のイベントの発生によって、または他の様式などで、自動的に実行可能である。ユーザは、最初のユーザがマクロへのアクセスを希望する他のユーザの電子メールアドレスまたは他のアカウント識別子に関するプロンプトを出すことなどによって、保存されたマクロを他のユーザが使用できるようにすることも可能である。ユーザは、メッセージンググループ(たとえば電子メールリスト)、あるいは、特定のドメインまたはサブドメインに関するすべてのユーザ(たとえば、ユーザの雇用主からシステムにアクセスするすべてのユーザ)を指示することなどによって、他のユーザのグループを提供することも可能である。

たとえば、マクロを実行するための入力は、オプションで、ユーザなどからステップ452aで受信することができる。代替として、マクロを実行するためのトリガイベントは、ステップ452bで発生可能である。いずれのメカニズムによっても、マクロに対応するマクロコードはステップ454で受信および実行される。

マクロ実行の初期段階で、マクロに関連付けられたアプリケーションに対応するAPIに関するオブジェクトが、ステップ456で作成される。こうしたオブジェクトは、マクロを実行するために必要なオブジェクトを表すことが可能であり、たとえば、コマンドのフォーマットをあるフォーマットから別のフォーマットに変換するオブジェクト、他のオブジェクトをラップするオブジェクト、クォータを課すオブジェクト、および他のこうしたオブジェクトを含むことができる。

オブジェクトは、ステップ458で、セキュリティラッパー内にラップされる。こうしたラッピングは、前述のメカニズムによって行うことが可能であり、システム上での悪意あるコードの実行からユーザを保護するために使用することができる。

ステップ460で、アプリケーションはユーザIDによって呼び出される(あるいは起動または実行される)。アプリケーションの呼び出しは、マクロサーバサブシステム202によって実行可能である。ユーザIDは、ユーザが特定ファイルの読み取り、更新、または削除について認可されていることを保証することなどによって、認可をチェックするために、呼び出しに含められる。

ステップ462で、呼び出されたアプリケーション内で実行されることになるステップに関係するアクションが実行される。たとえばアクションは、記録済みマクロに記録された個々の命令またはステップに対応するものとすることができる。ステップの実行は、マクロが記録されたブラウザから物理的にリモートであることが可能なアプリケーション内で行われる。実際に、マクロは、いくつかの例では異なるブラウザ上の全く異なるユーザによって記録および保存されている可能性がある。こうしたケースでは、異なるユーザは、最初に記録したユーザによってマクロの使用が認可された友人または家族とすることができる。

ステップ464で、さらなる実行に必要なキーが戻される。これらのキーは、たとえば、ユーザによって提供される入力、またはアプリケーション自体によって渡されるパラメータを含むことができる。ターゲットアプリケーション(たとえばスプレッドシートアプリケーション)から戻される「キー」は、所与のコマンドの結果として変更されている場合がある任意の項目を識別しうる。たとえばコマンドINSERT_SHEETを実行した結果、新しいシートが「現行」シートになる。マクロは、新しい現行シートを反映するように動作可能な、他のコマンド(たとえばgetActiveSheet)を有することが可能である。他のコマンド(たとえばINSERT_ROW)は、現行の選択を変更し、どのセルが現在アクティブであるかを変更することが可能である。現行の状態および選択データは、いずれかの後続のコマンド(たとえばgetActiveSelection)が情報を必要とする場合、格納のためにマクロに戻すことができる。

ステップ460、462、および464は、マクロが完了するまで相対的に同時に実行を継続することができる。ステップ462で最後の命令に遭遇し、これが実行された場合、または、マクロの実行におけるイベントがマクロの実行を停止した場合、終了とすることができる。

図5は、マクロシステムにおけるオブジェクトの例示的構造、具体的に言えば、図2のスクリプト情報リポジトリ206などの構造における情報に関する例示的論理構造を示す図である。論理構造500は、ノード502から508によって表される。スクリプト情報リポジトリ206に格納されたいずれか1つのマクロに関して、たとえば、少なくとも1つの構造500またはその一部が存在する可能性がある。継続ノード504、リンクノード506、およびユーザ認可ノード508は、すべて、ユーザライブラリノード502に対する0…Nの関係を有し、すなわちこれは、各ユーザライブラリ(またはヘッダ)ノードについて、任意数(ゼロを含む)の継続、リンク、およびユーザ認可が存在することを意味する。

構造のルートノードはユーザライブラリノード502であり、これは、たとえばマクロおよび/またはライブラリの名前(たとえば「Dan’s Cloud-based MacroLib」内の「Macro_XYZ」)、マクロライブラリの所有者(たとえば「Dan」)、およびマクロに関連付けられたスクリプト(たとえばマクロコード)を定義する。各マクロライブラリは、データベース主キーとして働くことも可能な、64ビッドの擬似乱数などの固有識別子を有することができる。いくつかの実装形態では、データベースからマクロを取り出す場合に、ライブラリ名などのフィールドおよびライブラリ内に含まれる機能セットは使用されず、それらは厳密にマクロライブラリを実行/表示する場合に使用するためのものである。「所有者」フィールドは、たとえば、「ユーザXYZによって所有されるすべてのマクロを取得」などの動作を伴う外部キーとして使用することができる。リンクテーブルは、たとえば、「文書XYZによって所有されるすべてのマクロを取得」などの動作で使用することができる。

継続ノード504は、継続ID、(たとえばマクロが待機状態に入った後に追加の入力でマクロを再開するためなどの、追加のエントリポイントからの)継続データ、およびユーザ名(たとえば継続ノード504を作成したユーザ)を含むことができる。所与のマクロについて複数の継続ノード504が存在可能である。主に継続の「所有者」は、たとえばユーザXがユーザYとして実行されていたマクロを再開できないように、セッションのハイジャックを防止するために記録することができる。このようにして動作は、それらが開始したマクロを、ユーザYのみが再開できることを保証することができる。1人のユーザがいくつかの継続を有することが可能であるため(たとえば別々のウィンドウ内に、それぞれがアクティブプロンプトダイアログボックスを備えた3つのオープンウィンドウ)、複数のこうした記録が可能となる。複数のユーザは、それぞれがそれら自体のダイアログプロンプトを備え、それら自体のマクロインスタンスを同時に実行中であることも可能である。

リンクノード504は、外部エンティティをマクロにリンクさせることができる。リンクノード504は、マクロを「指示する」URLまたは何らかの他のパス名とすることが可能な、文書IDを含むことができる。同じマクロについていくつかの異なる名前(および同じマクロまでのいくつかの異なるURLパスまたは他のパス)が存在する場合があるため、複数のリンクノード506が存在する可能性がある。

ユーザ認可ノード508は、マクロへの制限付きアクセスを許可する情報を含むことができる。たとえば、制限プロトバッファフィールドは値のプロトコルパターンを使用してアクセスを制御することが可能である一方で、ユーザフィールドはユーザIDに基づいてアクセスを制御することが可能である。これらのいずれかまたは両方を各ノード508で使用することができる。所与のマクロについて、それぞれが異なる認可レベルを識別する複数のユーザ認可ノード508が存在可能である。ユーザ認可ノード508は、ユーザごと、マクロごとに、1つの認可記録のみが存在するように強制することができる。この強制は、そのマクロの実行、およびマクロが実行できることに対する、ユーザの承認スタンプの表示を使用することが可能である。単に複数の異なるユーザがそれぞれ認可されたマクロを有することによって、複数の記録が可能であり、実行するためにそれについて認可された異なるアクションをそれぞれが有することが可能である。ユーザXがマクロを実行する場合、そのマクロに関するそれらの認可記録が引き上げられ、その他はすべて無視される。

マクロの実行が必要な要件を変更する、マクロに関する要件が変更された場合(たとえば作者がブロガーへの呼び出しを追加した場合)、既存のユーザ認可は無効としてマーク付けすることができる。結果として、追加の要件が追加された後に、ユーザがマクロの再実行を試行した場合、認可についてのプロンプトを再度発行することができる。たとえばプロンプトの内容は「このマクロはカレンダおよびブロガーへのアクセスが必要である」とすることができるが、以前には、マクロの内容が単に「このマクロはカレンダへのアクセスが必要である」であった可能性がある。サービスが削除された場合は、再認可のためにプロンプトを発行する必要がなく、要件が増えた場合のみ必要な可能性がある。

図6はマクロ構成システム600の例示的スクリーンショットを示す。ユーザはこのシステムを使用して、たとえば外部イベントに基づいてその後実行することが可能であるか、またはユーザが選択した場合に手動で実行することが可能な、たとえばマクロに関するパラメータおよび規則を確立することができる。一般にシステムは、マクロ構成を、それぞれがスクリーンショットの列に示された3つの段階に編成し、各段階(各段階内の下位段階を含む)は、その前の段階が構成されると変更される可能性がある。こうしたシステムを使用して、ユーザは、マクロに関するトリガ、選択されたトリガに関する使用可能なパラメータからのマクロを動作させるためのパラメータ、および、選択されたパラメータに対応するマクロの結果を、即時に識別することができる。

一例では、ユーザは、電子メール関連イベントに基づいて電子メール機能を実行するマクロを構成することができる。他の例では、マクロは、電子メールに関連しないアプリケーション(たとえばスプレッドシート、ワードプロセッシングアプリケーションなど)内で動作を実行するように構成することができる。さらに他の例では、ユーザは、出力を有するがいかなるトリガイベントにも依存しないマクロを構成することができる。アプリケーションのタイプがトリガまたは出力のいずれであっても、単にユーザがスクリーン上で選択を実行すると、結果として、対応するマクロが自動的に構成されるものとすることができる。スクリーンの「裏で」実行しているソフトウェアアプリケーションは、たとえば図6のスクリーンショットに示されたインターフェース上でのユーザの入力および選択を処理することが可能であり、適切なマクロ構文、様々なアプリケーション特有および言語特有のAPI呼び出し、ならびにそれを実行するために必要なマクロの他の構成要素を挿入することを含むマクロを、自動的に構成することができる。これらはすべて、意味のある数個のフィールド内に数件の入力を行うだけのユーザに対して透過的である。

スクリーンショット600は、現在構成されているマクロを識別する(たとえばユーザによって初期に定義されるかまたは後に更新される)、マクロ名フィールド601を含む。前述のように、マクロに関する識別は、マクロトリガデータ領域602、マクロ処理データ領域604、およびマクロ出力データ領域606の、3つの通常領域内で行うことができる。マクロトリガデータ領域602は、マクロをトリガする際に基にする条件またはイベントを決定および識別するためにユーザが使用可能な、フィールドおよびコントロールを含むことができる。マクロ処理データ領域604は、マクロが実行された場合に行われることになる処理を定義するために使用可能である。マクロ出力データ領域606は、マクロが動作する際に基にするアプリケーションデータのタイプ、およびそのデータで行われることになるアクション(または動作)などの、マクロの出力を識別することができる。データ領域602〜606に加えて、複数のアプリケーション内のデータが同じマクロによって更新されることになる場合の複数のマクロ出力データ領域606などの、他のデータ定義領域も存在可能である。いくつかの実装形態では、コミット/ロールバック技法を使用して、すべての更新が実行されるかまたは全く実行されないことを保証することが可能であり、これはデータの整合性を保持するために役立つ可能性がある。

3つのデータ領域602、604、および606は、通常、順番に完了するように設計することができる。いくつかの実装形態では、1つの領域内でユーザによって選択された値は、その下またはその領域の右側のフィールドまたはコントロール上に表示される内容に影響を与える可能性がある。たとえば、マクロトリガデータ領域602内に入力されたデータは、他の領域(たとえばデータ領域604および606)内に表示される(およびユーザ選択可能な)、フィールドおよびデータ選択肢のタイプに影響を与える可能性がある。たとえば、ユーザが(たとえばプロパティフィールド608で「電子メール」を指定または選択することによって)マクロのトリガメカニズムとして「電子メール」を選択した場合、マクロ処理データ領域604で利用可能なオプションを電子メールプロパティに合わせることができる。

この例で示されたマクロトリガデータ領域602は、プロパティフィールド608、アクティビティフィールド610、およびパラメータフィールド611を含む。アクティビティフィールド610に表示される(およびユーザによって選択可能な)値は、プロパティフィールド608内のユーザの選択に依存することができる。たとえばプロパティフィールド608内で「電子メール」を選択することによって、アクティビティフィールド610内の値には電子メール関係オプション(たとえば着信メッセージ、受信箱サイズ、タグサイズなど)が含まれる。異なるプロパティ(たとえばオンラインオークション)の選択の結果、アクティビティフィールド610内に異なるエントリリスト(たとえばアイテムの量、アイテムのカテゴリなど)が表示されることが可能である。パラメータフィールド611を使用して、アクティビティに値を割り当てることができる。ユーザがパラメータフィールド611で入力または選択できる潜在的な値は、たとえば、特定のアプリケーションに適した、サイズ、色、金額、期間、言語、性別、あるいは単なる任意の量的または質的な値を含むことができる。いくつかの実装形態では、パラメータフィールド611上のラベルは、アクティビティボックス610の値に依存して自動的に(たとえばサイズ、色、価格などを)ラベル付けすることができる。

マクロ処理データ領域604は、条件フィールド612、サービスチェックフィールド614、およびサービス値フィールド616を含む。条件フィールド612は、マクロによってあるアクション(たとえば着信電子メールのある様式での転送など)をトリガすることになる条件を識別するためのオプションを表示する。条件フィールド612に表示される正確な値(たとえば「ユーザから」、または「グループ内のユーザから」など)は、たとえばプロパティフィールド608内でのユーザの入力(たとえば「電子メール」)に依存することができる。ユーザがプロパティフィールド608に対して異なる値(たとえば「スプレッドシート」)を選択した場合、条件フィールド612内には(たとえば「スプレッドシートに関連する」)異なる値のセットが表示される可能性がある。

サービスチェックフィールド614は、マクロの実行に関する情報を収集する際にマクロによってチェックされることになる、アプリケーションおよびマクロの外部のサービスを識別することができる。たとえばサービスチェックフィールド614で「ロケータ」を選択することによって、ユーザは、マクロがその実行中に、送信者の位置、ユーザXの位置、または電子メールのカーボンコピー欄にリスト表示された特定ユーザの位置、あるいは他の選択肢をチェックしなければならない旨を定義しているものとすることができる。サービス値フィールド616は、参照されるサービスからマクロに戻されなければならない特定の値を識別する。この場合の位置は、たとえば、リアルタイムGPS位置付近、携帯電話の三角測量によって追跡される位置、所在地住所、ZIPコード、または任意の他の適切な位置決め基準に基づくものとすることができる。

いくつかの実装形態では、マクロ処理データ領域604は、マクロ内でブール演算子を使用するための様々なメカニズムを含むことができる。これらのメカニズムは、条件フィールド612 AND サービスチェックフィールド614を有することによって示唆される暗黙的「AND」に加えるものとすることができる。たとえば条件フィールド612は、明示的AND/OR演算子および論理の指定を容易にすることが可能な、ラジオボタンとして示された、いずれか/すべて(any/all)コントロールセット617を用いて使用することが可能である。たとえばユーザは、サービスチェックフィールド614でチェックされた個々のオプションのいずれか(またはすべて)がマクロに関する考慮の対象となる点に関して指定するために、いずれか/すべてコントロール617の「Any」(または「All」)オプションを選択することができる。

いくつかの実装形態では、マクロ構成システム600上に、フィールド名、フィールド値、ブール演算子、および適切に配置された括弧の、容易なテキスト入力などの、追加のブールコントロールおよびフィールドを他のフィールドなどのために提供することができる。こうしたタイプのより高度なタイプのコントロールを、たとえば高度なブールコントロール618の選択によって到達可能なスクリーンまたは他のインターフェース上に含めることができる。いくつかの実装形態では、高度なブールコントロール618にアクセスすることで、ユーザは、マクロ全体に関する既存の論理が理解可能となり、たとえば、データ領域602から606で実行された更新済みのユーザ選択肢および入力によって表される現行論理を含むことができる。システム600は、自動構文チェックを実行すること、および、ユーザによって入力(またはリストから選択)されたフィールドがそれらのチェックの対象となる値に適合している旨を検証することが可能である。

マクロ出力データ領域606は、プロパティフィールド620、アクションフィールド622、およびパラメータフィールド624を含む。これらのフィールドは、たとえば、マクロの特定出力(たとえばこれを実行、それを送信、特定ファイル、フィールド、またはスプレッドシートセルの更新など)を指定するために使用することができる。図6に示された例では、プロパティ620に対して「電子メール」が選択され、結果として電子メールに関係するエントリがアクションフィールド622内に表示されている。したがってこのマクロに関する出力は、何らかのアドレスへ何らかの形の電子メールを送信することである。

パラメータフィールド624は、フィールドまたは選択に値を割り当てるために、必要な場合(たとえばその上の選択肢およびフィールドに基づいて)、使用することができる。いくつかの実装形態では、フィールドの値をフィールドの「裏に」定義することが可能であるため、結果として、フィールド名をダブルクリックするとフィールドに関する値を定義するためのポップアップを表示し、フィールドの上を移動することによってフィールドの現行値を表示することができる。

図6に示された例示的マクロ構成スクリーンでは、(たとえばアクティビティフィールド610内で識別された)「着信メッセージ」が電子メールアプリケーションによって(たとえばプロパティフィールド608ごとに)受信された場合、マクロをトリガするように、マクロトリガデータ領域602が定義される。マクロ処理データ領域604は、特定のユーザ、電子メールの本文に特定の語を含むこと、およびユーザXの位置に基づくことを指定する、条件612を含む。これらの条件に関する値は、たとえば他のパラメータフィールド(図6には図示せず)に定義することができる。したがってマクロは、こうした条件に合致する場合に完了を実行することになる。マクロ出力データ領域606は、「電子メール」が現行マクロの出力のタイプであること、実行されるアクションが(たとえばアクションフィールド622に定義されたように)「私宛メールを作成送信(text me)」であることを示す。データ領域602から606に入力された値の結果として、特定ユーザからの着信電子メールメッセージのトリガイベントの検出によって、件名欄に特定の語を含むことによって、およびユーザXの位置に基づいて、マクロはメッセージングアプリケーションを使用して、着信電子メールのターゲットに、こうした電子メールが受信されたことを伝えるテキストメッセージを送信する。例示的マクロ構成スクリーンの利点は、簡潔なGUIフォーマットでこの情報をユーザに提供する一方で、機能を実行する基礎となるマクロを隠しながら、ユーザは、マクロの作成方法またはそれを認識する方法を知る必要さえないことである。スクリーンを使用して完全なマクロを構成すること、またはマクロの一部を構成することが可能であり、ここでユーザは、スクリーンによって提供できない他のコードをマクロに追加することができる。

マクロを定義するためのユーザインターフェースは、たとえば入力または更新されるマクロを「保存」するため、マクロへの1つまたは複数の更新または変更を「やり直し」するため、結果として生じるマクロを「表示」するため、あるいは編集を保存せずに「取り消し」するための、ボタンまたはコントロール626を含むことができる。「コピー元」フィールド628は、スクリーンを初期の状態で事前設定し、その後ユーザが変更できるように、既存のマクロをコピーすること、または、既存のマクロに関するパラメータをコピーすることによって、ユーザが新しいマクロを作成および定義できるようにする。説明フィールド630は、ユーザがマクロの目的を記録するか、または、マクロの名前にキャプチャされていない何らかのレベルの意味をマクロに提供することができるようにするものである。

いくつかの実装形態では、マクロ定義は、マクロが最初に有効になる時点に関する発効日632、マクロがそれ以上実行されない時点に関する満了日634、および、たとえばマクロが実行されることになる曜日(たとえば平日、月曜日、週末など)を指定するために使用可能なスケジュールまたは「実行日(run on)」フィールド636などの、それらに関連付けられた時間要素を有することができる。日付フィールドは、特定の日付または日付範囲および/または時刻を含むことが可能であるか、または列挙タイプ(たとえば今、なし、平日など)を含むことが可能である。

いくつかの実装形態では、システム600によって提供されるユーザインターフェースは、スマートフォンなどのより小型のディスプレイを有するユーザデバイス上で実行するように適合することができる。たとえばデータ領域602から606および他のフィールドを順番に提供することができる。いくつかの実装形態では、スクリーン全体にスクロールバーを提供することが可能であり、それによってユーザを一度に1つの通常領域にナビゲートすることができる。

システム600を使用して構成されたマクロは、システム100および200ならびに図1および2に関して前述したセキュリティ態様で使用することができる。特に、構成された各マクロを機能ベースのセキュリティラッパー内にラップすることができる。システム600は、たとえばマクロを使用することができる他のユーザの名前、および動作(たとえば電子メールの送信、スプレッドシートの更新など)を実行可能な範囲を含む、セキュリティを容易にすることが可能なセキュリティ関係フィールド(図示せず)を含むことができる。

こうした機能ベースのセキュリティは、コードの実行を認可する場合、ユーザの意図を考慮に入れることによって、恩恵を与えることができる。こうしたシステムにおいて、また例によって、実行ユーザは、ユーザが許可を希望する各動作をカプセル化する、機能と呼ばれるオブジェクトを作成し、これらのオブジェクトを、実行されることになる信用できないコードに渡す。これらのオブジェクトは、信用できないコードがシステムによって実行された場合、ペイロードの一部(たとえばラッパーの一部)となり、信用できないコードによって修正または作成できない。信用できないコードが、基礎となる信用されるリソース(たとえば通常はファイルシステムなど)へのアクセスを試みる場合、信用されるリソースをラップするユーザが作成したオブジェクトを介してのみ、実行可能である。機能は、信用できないコードに付与されることになるアクセスを介してきめの細かい制御を実行することが可能であり、最小権限の原理に準拠する実行環境を構築するために使用可能である。これは、任意の所与のモジュールが、その機能を実行できるようにするために必要な最小のアクションセットのみを実行可能であることを意味する。

これまで、ホスト型マクロベースシステムに関する例示的システムおよびプロセスについて説明してきたが、以下の段落では、こうしたシステムおよびプロセスを採用するための一連の例について説明し、その多くは、システムが機能ベースセキュリティをどのように使用してこれらそれぞれのケースに対処するか、およびこうした例の一部とすることが可能ないくつかのリスクをどのように軽減するかについて論じる。

販売ポリシーの実施
組織の販売部門が、潜在的顧客に対する提案をスプレッドシートに作成するシナリオについて考えてみる。スプレッドシートは企業が生産するすべての製品および機能のコストを含む。販売員はシートを下げながら、機能の横の列に1または0を用いて機能のアクティブまたは非アクティブ(現在は販売不可)のマークを付けることができる。シートは、様々な値引きおよび価格の常数を含む、価格付けを計算するための公式を含むことができる。

ライン項目の間には、たとえば互いに排他的とすることが可能ないくつかの機能を含む、多くの依存性が存在する場合がある。これらの規則をマクロとして表すことができる。代替として、規則は、規則を実施するためにシートに付加されたマクロにコンパイルされる規則言語で表すことができる。追加の規則は、エラーチェックおよび他の整合性チェックを含むことができる。加えて、領域または他の要素に基づくプロモーションまたはトリガイベントに関連付けられた規則も存在可能である。

こうした規則に関して考慮することの1つは、管理する方法である。たとえば、管理者がシート内の値を容易に更新できるように、シートが参照する共有ライブラリ内でマクロおよび/または規則を有効にすることが有用な場合がある。またマクロは、システム管理者が様々な小規模な会社の経営者に提供し、それらユーザのそれぞれにマクロへのアクセスおよびその実行を許可することが可能な、1組のツールの一部とすべきである。管理者は、ホスト型システム上の中央位置からマクロを更新された状態で維持することが可能であり、ユーザはその位置からすべてのマクロを実行することができる。

したがってマクロは、マクロにアクセスする各スプレッドシートについて単一の「スロット」を備えた、共有モードで公開可能である。他のユーザは、マクロを指示するURLをそれらのスプレッドシートに含めることによって、マクロをそれらのスプレッドシートにインポートすることが可能であり、そのスプレッドシートへの書き込み権限を与えることができる。

投資ユーザインターフェース
投資会社がスプレッドシート内に価格付けモデルを有し、外部サービスから株式市況を引き出し、勧告(たとえば買い、保有など)を生成するためにそれらをスプレッドシートに導入しようとするシナリオについて考えてみる。

スクリプトは、スプレッドシートからの読み取りおよびスプレッドシートへの書き込み、ならびに外部株式市況サービスへのアクセスが必要な場合がある。作者は、スクリプトを特定の株式市況サービスのみに制限するアクセスをスクリプトに付与することができる。作者がそのスロットを空のままにしておいた場合、サービスを呼び出すユーザは、サービスに接触する権限をスクリプトに付与するかどうかのみでなく、どの特定サービスに接触するかも問われるものとする。そのようにしてユーザは、スクリプトが実行できる内容を制約することが可能であり、スクリプトはいかなる他のサービスにも接触できないことになる。

ユーザがこのマクロを(たとえば、マクロを参照するのではなくコピーするために)それら自体のスプレッドシートに含めるために他のユーザと共有したい場合、他のユーザは、外部株式市況サービスにアクセスするためのそれら自体の権限が必要である。ユーザが、中央位置で他のユーザにマクロを指示させることによって、マクロを共有する場合、ユーザは自身が外部株式市況サービスに接触するための権限を持たない場合であっても、マクロを使用できる可能性がある。ユーザは、こうした状況では、(自身のスクリプトからサービスにアクセスできない可能性があるが)スクリプト自体が有する権限を付与されることが可能である。

事故報告書
バス輸送会社がその事故報告書の自動化に関心があるシナリオについて考えてみる。事故に遭った運転手はホスト型サービスにアクセスして、バスの位置などの情報を記録するスプレッドシートの書類に記入することができる。マクロを使用して、様々な監督者の審査のために彼らに報告書をルーティングすることができる。

マクロは、監督者を(たとえば、アクセス権を有する他のスプレッドシート、データベース照会を介して)識別し、法務部門の正確な電子メールアドレスを生成し、それらの人々と文書を共有し、さらに、電子メールを送信して他のスプレッドシート(たとえば、どの事故報告書が保留されているかの記録を含むスプレッドシート)にアクセスすることが、必要な可能性がある。そうした人々は、さらにスプレッドシートを編集し、その後マクロを先へ進めるイベントをトリガすることが必要となることがある。マクロは、特定のユーザがアドレスを有するごとにマクロの段階を一時停止し、その後、次のユーザが取り上げるまで待機するように、連続モードで実行可能である。イベントによって一時停止が解除されると、誰が文書を承認したか(たとえば文書自体に記録されるか、またはマクロに送信されたイベント内の情報に記録されたように)を確かめるためにチェックし、承認を必要とするすべての人が承認を終えるまで待機することが可能であり、その時点でマクロは、事故が完全に処理された旨を(たとえば、さらに他のスプレッドシート内で)誰かに通知および記録することが可能である。いくつかの実装形態では、2つのイベントが同時に着信した場合、それらを待ち行列に入れることが可能であるため、マクロは一度に1つの継続のみを処理する。ワークフロー状態は、単にマクロのローカル可変コンテキスト内に保持し、さらに部分的にスプレッドシートに記録することができる。

関連シナリオでは、完全に処理されずに(たとえばワークフローに基づいて)打ち切られた事故報告書を照会することができる。この照会には、事故報告書に関する状態情報を含むスプレッドシートにアクセスすること(または単にスプレッドシートを開くこと)が必要な可能性がある。

バススケジュール報告
バス輸送会社があるバス路線での遅延を顧客に通知できることを望むシナリオについて考えてみる。この会社は、スプレッドシートを編集し、それらのバスの予想時間/場所を更新することが可能であり、こうした編集は、バスに関する位置データを受信し、こうした情報に基づいて(たとえば、バスが停留所Xを出発したことを識別し、時間Yを加算して停留所X+1への到着時間を算出することによって)到着予想時間を計算するマクロによるなど、自動的に行うことが可能である。スプレッドシート内のマクロは、あるバス路線が異常に遅延していることを識別することが可能であり、遅延している場合、通知に関して登録している顧客にテキストメッセージを送信することができる。たとえばユーザは、ユーザが市内で自分の通常のバス停から2ブロック以内に居て、ユーザのいずれかの運行中のバス(たとえばバス番号692、698など)がその場所に5分以上遅れて到着する可能性がある場合は必ず、テキストメッセージを受信するように加入することが可能である。ホスト型サービスにユーザの記録上のフラグを活動化させ、結果として、(たとえば、ユーザのGPS座標を最も近いバス停位置に変換することによって)、ユーザが位置を手動で入力する必要なしに、ユーザがユーザの現在位置に向けて送られた更新を受信するように、ユーザが適切な場所に居る場合にユーザのモバイルデバイス上のアプリケーションをトリガすることができる。

セキュリティの目的で、マクロの作者は、(たとえば他のスプレッドシート内に列挙され、管理者によって制御される)制限付きユーザセットにテキストメッセージを送信するための機能を付与することが可能であり、このマクロを、シートに対してのみローカルで、公的にアクセス可能ではないように公開する可能性が高い。作者は、マクロにシートへの書き込み機能を付与しない。このシナリオは、文書に定義されたグループまたは他の集合(たとえばスプレッドシートまたは何らかの他のグループ定義)を参照することによって、機能の幅を指定する可能性を提示する。

位置ベースのイベントトリガ
1人のユーザが、各コンサートの場所および日付/時刻を含む、スプレッドシート内のコンサート推薦セットを更新するシナリオについて考えてみる。他のユーザは、これらのコンサートのうちの1つの近隣に居る場合、およびコンサートの時間が近づいてきた場合は、必ず通知するよう求めることによって、このスプレッドシートからの通知に加入することができる。このケースでの通知は、たとえば、マッピングサービス、ソーシャルネットワーキングサービス(推薦を作成するユーザの友人を識別するため)、位置サービス(友人が特定の位置にいる場合に識別するため)、および通知を送信するためのテキストメッセージングサービスなどのサービスを、使用することができる。したがってこうしたシナリオでは、ホスト型マクロが特に適している。

調査
ユーザが調査または他のデータ入力書式を作成し、何人かの他のユーザに電子メール書式を送信し、各ユーザがどのように書式に記入するかを示す行をスプレッドシートに追加する、シナリオについて考えてみる。

マクロには、あるアドレスからユーザによって提供されたアドレスセットへと人々のセットに電子メールを出すための機能が付与されるはずである。マクロは、ホスト型サービスからのユーザ識別機能にアクセスすること、または応答内のユーザID(たとえば電子メールアドレス)を識別することによってなどの、各ユーザからの形のデータの受信を追跡することができる。次にマクロは、スプレッドシートにアクセスし、ユーザIDをスプレッドシートの1つの列に入力し、ユーザの回答をスプレッドシートの他の列に入力することができる。このようにして、第1のユーザは、(たとえば既存の友人リストまたは電子メールリストから決定された)グループに書式を即時送信し、そのグループからのコメントを自動的に一覧にすることができる。

注文書の承認
ユーザがある注文書(たとえば、「X千ケースのQチップを所望、製造元XYZが好ましい」)を開始するシナリオについて考えてみる。ユーザが注文書(PO)を提出した場合、マクロは品目、合計金額、部門などのデータに基づいて、そのPOについて誰の承認が必要であるかを決定することができる。たとえば合計金額が固定のしきい値を超えている場合、POはトップの承認(chair approval)が必要な可能性がある。承認者がPOを承認すると、マクロ、データベース、またはスプレッドシートに定義されたユーザのリストなどの、ワークフローに沿って移動することが可能であり、マクロは、誰がPOを承認し、誰がしていないかを記憶するためにローカル状態を維持し、すべての承認者が承認すると、POは購入のために送信される。

このマクロは、継続の点で最良の実行が可能である。マクロは、あるユーザが所与の注文書を承認または不承認するためにクリックが可能な書式またはURLを備えた文書へのリンクまたは添付と共に、それらのユーザに電子メールを送る機能を有し、部長などの情報を備えた他のスプレッドシートまたはデータベースへのアクセス権を有する。

メール統合
ユーザが、名前、住所、電子メールアドレスなどの名前スプレッドシート、および他の文書(たとえば電子メール、スプレッドシートなど)を有し、後者の文書内のフィールドをリストからのフィールドに置き換え、統合された文書を名前シートに指定された受信者に電子メールで送ることを希望する、シナリオについて考えてみる。

セキュリティのために、これは、特定の文書および名前リストとの関連において全体を実行できるマクロである。機能は、「この表の第1列に指定されたように、リストに電子メールを送ることが可能」であり、さらにテンプレート文書にアクセスすることができる。マクロ自体は、スプレッドシート欄および何らかのテンプレートから算出されたデータと共に、リスト内の人々に電子メールを送る。マクロを統合するメールに関する特定の書式は良く知られている。

医師のシフトスケジュール
何人かの医師が同じスプレッドシートにアクセスし、これを編集しているシナリオについて考えてみる。マクロは、各医師が、スプレッドシートに関するフォーマット化またはスケジューリングの規則(たとえば、ある期間内の最高または最低シフト数)に従っていたことを確認するために、スプレッドシートをチェックすることができる。各ユーザは、ボタンをクリックしてマクロを実行し、たとえばより直観的アクセスのために(たとえばスケジュールの反復を作成するために)、シートとカレンダアプリケーションとを同期させることができる。双方向同期化も行うことができる。

マクロは、多彩な他のカレンダアプリケーションと相互作用できるように拡張可能である。マクロは、医師が規則に従っていることを検証するため、自分がいくつのシフトにサインアップしているかを医師が継続して追跡できるようにするため、およびスプレッドシートをカレンダアプリケーションと同期させるための、一助となることも可能である。

電子メールのプラグイン
ユーザは、自分のアカウントへの着信電子メールの各インスタンスを識別し、その電子メールの送信者識別および件名欄を電子メールからコピーして、ユーザのアカウントに関連付けられたスプレッドシートの次の空白行にコピーするように、マクロを定義することができる。このようにして、ユーザは、自分のアカウントへの着信電子メールの最新ログを自動的に維持することができる。

ブログのプラグイン
サービスに関するブロガーであるユーザは、ブログへのユーザコメントを処理するためのマクロを開発することができる。たとえば、(たとえばユーザからのコメントに対応するIPアドレスを使用して)コメントの横にコメンタの位置を示すためなどに、コメンタに関する情報を使用することができる。加えてユーザは、すべてのコメントを、冒とく的な言葉などの引き金となる言葉のブラックリストに照らして比較することが可能であるため、結果としてユーザは、不適切な言葉を含むコメントがポストされた場合に必ず、テキストメッセージの警告を受信する。次にユーザは、ブログにログインしてこれを消去することができる。

課金請求可能時間
コンサルタントであるユーザは、カレンダアプリケーション内で自分の課金請求可能時間を追跡することができる。彼らはマクロを使用して、こうしたエントリを(たとえばx.xの形の時間エントリを認識することによって)、定期的に(たとえば毎週または毎月)解析することができる。次にマクロは、エントリに関連付けられたテキストを使用して、時間に対して課金請求すべきプロジェクト番号を識別することが可能であり(たとえばキーワードおよびクライアント名とある明白なプロジェクトとを相関させるリスト)、次に、課金請求動作を実行するためにスプレッドシート内のセルにデータを追加することができる。次にマクロは、(課金請求用の時間単位レートを適用した後の)スプレッドシートからの値を、ワードプロセッシングプログラムによって生成されたインボイスに統合し、その後、結果として生じた文書をクライアントに電子メールで送信することができる。クライアントがホスト型システムの登録ユーザである場合、マクロは支払いを直接要求する(請求額を支払う意図を示すためにクライアントが使用可能な、選択可能メカニズムを含む書式を介することを含む)ことが可能であり、その後、クライアントは、クライアントの口座からコンサルタントの口座へ送金するためのコントロールを選択することができる。

経路案内のメール統合
ホスト型システムのユーザは、何人かの自分の友人に次回のパーティに関する招待状を送信することを希望する場合がある。ユーザは、パーティへの招待のためのシェル(shell)を準備することができる。次にユーザは、マクロに(たとえばホスト型システム上の連絡先アプリケーションで)友人およびその住所のリストを指示し、実際に、招待状へのメール統合を実行することができる。しかしながらユーザは、自分自身の住所(パーティの場所)、および現在招待状が準備されている友人の住所も、リストからマッピングサービスに提供することが可能であり、これが標準APIに従って、その友人の自宅からパーティまでの経路案内が重ね合わされた地図を示す画像を戻すことができる。マクロはこの画像を招待状に組み込み、その後これを、自動的にカスタム生成された案内と共に友人に送ることができる。

図7は、本書で説明される技法で使用可能な汎用コンピュータデバイス700および汎用モバイルコンピュータデバイス750の例を示す。コンピューティングデバイス700は、ラップトップ、デスクトップ、ワークステーション、携帯情報端末、サーバ、ブレードサーバ、メインフレーム、および他の適切なコンピュータなどの、様々な形のデジタルコンピュータを表すことが意図されている。コンピューティングデバイス750は、携帯情報端末、携帯電話、スマートフォン、および他の同様のコンピューティングデバイスなどの、様々な形のモバイルデバイスを表すことが意図されている。本書に示された構成要素、それらの接続および関係、ならびにそれらの機能は、単なる例示的なものであることが意図されており、本明細書で説明および/または請求された本発明の実装形態を限定することは意図されていない。

コンピューティングデバイス700は、プロセッサ702、メモリ704、ストレージデバイス706、メモリ704と高速拡張ポート710とに接続された高速インターフェース708、および、低速バス714とストレージデバイス706とに接続された低速インターフェース712を含む。構成要素702、704、706、708、710、および712のそれぞれは、様々なバスを使用して相互接続され、一般的なマザーボード上に、または必要に応じて他の様式で、取り付けることが可能である。プロセッサ702は、高速インターフェース708に結合されたディスプレイ716などの外部入力/出力デバイス上にGUIに関するグラフィック情報を表示するために、メモリ704内またはストレージデバイス706上に格納された命令を含む、コンピューティングデバイス700内で実行するための命令を処理することが可能である。他の実装形態では、複数のプロセッサおよび/または複数のバスを、複数のメモリおよびメモリのタイプと共に、必要に応じて使用することができる。また、複数のコンピューティングデバイス700は、(たとえばサーババンク、ブレードサーバのグループ、またはマルチプロセッサシステムとして)必要な動作の一部を提供する各デバイスと接続することができる。

メモリ704は、コンピューティングデバイス700内の情報を格納する。一実装形態では、メモリ704は揮発性メモリユニットである。他の実装形態では、メモリ704は不揮発性メモリユニットである。メモリ704は、磁気または光ディスクなどの、他の形のコンピュータ読み取り可能媒体とすることもできる。

ストレージデバイス706は、コンピューティングデバイス700に大容量ストレージを提供することができる。一実装形態では、ストレージデバイス706は、フロッピー(登録商標)ディスクデバイス、ハードディスクデバイス、光ディスクデバイス、またはテープデバイスなどのコンピュータ読み取り可能媒体、フラッシュメモリまたは他の同様のソリッドステートメモリデバイス、あるいは、ストレージエリアネットワークまたは他の構成内のデバイスを含むデバイスのアレイとするか、またはこれを含むことができる。コンピュータプログラム製品は、情報担持媒体内に有形に具体化することができる。コンピュータプログラム製品は、実行された場合、前述のような1つまたは複数の方法を実行する命令を含むことも可能である。情報担持媒体は、メモリ704、ストレージデバイス706、プロセッサ702上のメモリ、または伝搬信号などの、コンピュータ読み取り可能媒体または機械読み取り可能媒体である。

高速コントローラ708は、コンピューティングデバイス700に関する帯域幅集中動作を管理し、低速コントローラ712は、より低い帯域幅集中動作を管理する。こうした機能の割り振りは、単なる例示的なものである。一実装形態では、高速コントローラ708は、メモリ704、ディスプレイ716(たとえばグラフィックプロセッサまたはアクセラレータを介して)、および、様々な拡張カード(図示せず)を受け入れることが可能な高速拡張ポート710に結合される。この実装形態では、低速コントローラ712は、ストレージデバイス706および低速拡張ポート714に結合される。様々な通信ポート(たとえばUSB、Bluetooth(登録商標)、イーサネット(登録商標)、ワイヤレスイーサネット(登録商標))を含むことが可能な、低速拡張ポートは、キーボード、ポインティングデバイス、スキャナ、あるいは、スイッチまたはルータなどのネットワークデバイスなどの、1つまたは複数の入力/出力デバイスに、たとえばネットワークアダプタを介して結合することができる。

コンピューティングデバイス700は、図に示されたようないくつかの異なる形で実装可能である。たとえば、標準サーバ720として、またはこうしたサーバのグループ内に複数回、実装可能である。ラックサーバシステム724の一部としても実装可能である。加えて、ラップトップコンピュータ722などのパーソナルコンピュータ内にも実装可能である。代替として、コンピューティングデバイス700からの構成要素は、デバイス750などのモバイルデバイス内の他の構成要素(図示せず)と組み合わせることができる。こうしたデバイスのそれぞれは、コンピューティングデバイス700、750のうちの1つまたは複数を含むことが可能であり、システム全体は、互いに通信する複数のコンピューティングデバイス700、750で構成することができる。

通信デバイス750は、他の構成要素の中でもとりわけ、プロセッサ752、メモリ764、ディスプレイ754などの入力/出力デバイス、通信インターフェース766、およびトランシーバ768を含む。デバイス750には、追加のストレージを提供するために、マイクロドライブまたは他のデバイスなどのストレージデバイスを提供することも可能である。構成要素750、752、764、754、766、および768のそれぞれは、様々なバスを使用して相互接続され、構成要素のいくつかは、一般的なマザーボード上に、または必要に応じて他の様式で取り付けることができる。

プロセッサ752は、メモリ764に格納された命令を含む、コンピューティングデバイス750内の命令を実行することができる。プロセッサは、別個で複数のアナログおよびデジタルのプロセッサを含む、チップのチップセットとして実装可能である。プロセッサは、たとえば、ユーザインターフェース、デバイス750によって実行されるアプリケーション、およびデバイス750によるワイヤレス通信の制御などの、デバイス750の他の構成要素を調整するために提供可能である。

プロセッサ752は、ディスプレイ754に結合された制御インターフェース758およびディスプレイインターフェース756を介して、ユーザと通信することができる。ディスプレイ754は、たとえば、TFT LCD(薄膜トランジスタ液晶ディスプレイ)、またはOLED(有機発光ダイオード)ディスプレイ、あるいは他の適切なディスプレイテクノロジとすることができる。ディスプレイインターフェース756は、グラフィックおよび他の情報をユーザに提示するためのディスプレイ754を駆動するための、適切な回路を備えることができる。制御インターフェース758は、ユーザからのコマンドを受信し、それらをプロセッサ752にサブミットするために変換することができる。加えて、外部インターフェース762は、デバイス750の他のデバイスとの近隣領域通信を実行可能にするように、プロセッサ752と接続された状態で設けることができる。外部インターフェース762は、たとえば、いくつかの実装形態では有線通信、または他の実装形態では無線通信を提供することが可能であり、複数のインターフェースを使用することもできる。

メモリ764は、コンピューティングデバイス750内の情報を格納する。メモリ764は、コンピュータ読み取り可能媒体、揮発性メモリユニット、または不揮発性メモリユニットのうちの、1つまたは複数として実装可能である。拡張メモリ774も、たとえばSIMM(Single In Line Memory Module)カードインターフェースを含むことが可能な拡張インターフェース772を介して、デバイス750に提供および接続可能である。こうした拡張メモリ774は、デバイス750に追加のストレージスペースを提供することが可能であるか、または、デバイス750に関するアプリケーションまたは他の情報を格納することも可能である。具体的に言えば、拡張メモリ774は、前述のプロセスを実施または補足するための命令を含むことが可能であり、セキュア情報を含むこともできる。したがって、たとえば拡張メモリ774は、デバイス750のためのセキュリティモジュールとして提供可能であり、デバイス750のセキュアな使用を許可する命令を使用してプログラミングすることができる。加えて、ハッキング不可能な様式でSIMMカード上に識別情報を配置するなどのセキュアアプリケーションが、追加情報と共に、SIMMカードを介して提供可能である。

メモリは、以下で論じるように、たとえばフラッシュメモリおよび/またはNVRAMメモリを含むことができる。一実装形態では、コンピュータプログラム製品は情報担持媒体内に有形に具体化される。コンピュータプログラム製品は、実行された場合、前述のような1つまたは複数の方法を実行する、命令を含む。情報担持媒体は、メモリ764、拡張メモリ774、プロセッサ752上のメモリ、あるいは、たとえばトランシーバ768または外部インターフェース762を介して受信可能な伝搬信号などの、コンピュータ読み取り可能媒体または機械読み取り可能媒体である。

デバイス750は、必要な場合にはデジタル信号処理回路を含むことが可能な、通信インターフェース766を介してワイヤレスに通信可能である。通信インターフェース766は、とりわけ、GSM(登録商標)音声呼び出し、SMS、EMS、またはMMSメッセージング、CDMA、TDMA、PDC、WCDMA、CDMA2000、またはGPRSなどの、様々なモードまたはプロトコルの下で通信を提供することができる。こうした通信は、たとえば無線周波数トランシーバ768を介して行うことができる。加えて、Bluetooth(登録商標)、WiFi、または他のこうしたトランシーバ(図示せず)などを使用して、短距離通信を行うことができる。加えて、GPS(全地球測位システム)受信器モジュール770は、デバイス750上で実行するアプリケーションによって必要に応じて使用可能な、追加のナビゲーション関連および位置関連のワイヤレスデータを、デバイス750に提供することが可能である。

デバイス750は、ユーザから音声情報を受信し、これを使用可能なデジタル情報に変換することが可能な、音声コーデック760を使用して、音声通信することも可能である。音声コーデック760は、同様に、デバイス750のハンドセット内で、スピーカなどを介して、ユーザに対して可聴音を生成することが可能である。こうした音は、音声電話呼び出しからの音を含むこと、録音された音(たとえば音声メッセージ、音楽ファイルなど)を含むこと、および、デバイス750上で動作するアプリケーションによって生成された音を含むことも可能である。

コンピューティングデバイス750は、図に示されるようないくつかの異なる形で実装可能である。たとえば、携帯電話780として実装可能である。また、スマートフォン782、携帯情報端末、または他の同様のモバイルデバイスの一部としても実装可能である。

デバイス750は、動き感知が可能な1つまたは複数の異なるデバイスを含むこともできる。その例には加速度計およびコンパスが含まれるが、これらに限定されるものではない。加速度計およびコンパス、あるいは動きまたは位置を検出することが可能な他のデバイスは、任意数のベンダから入手可能であり、多様な方法で動作を感知することが可能である。たとえば、加速度計は加速度の変化を検出可能であり、コンパスは磁北極または磁南極に対する向きの変化を検出可能である。これらの動きの変化はデバイス750によって検出可能であり、本明細書で説明されるプロセスおよび技法に従って、それぞれのデバイス750の表示を更新するために使用可能である。

本明細書で説明されるシステムおよび技法の様々な実装形態は、デジタル電子回路、集積回路、特別に設計されたASIC(特定用途向け集積回路)、コンピュータハードウェア、ファームウェア、ソフトウェア、および/またはそれらの組み合わせで実現可能である。これらの様々な実装形態は、ストレージシステム、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスから、データおよび命令を受信するため、ならびにそれらにデータおよび命令を送信するために結合された、特定用途向けまたは汎用とすることが可能な、少なくとも1つのプログラム可能プロセッサを含む、プログラム可能システム上で実行可能および/または解釈可能な、1つまたは複数のコンピュータプログラム内の実装形態を含むことができる。

これらの(プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとも呼ばれる)コンピュータプログラムは、プログラム可能プロセッサに関する機械命令を含み、高水準手続き型および/またはオブジェクト指向のプログラミング言語、ならびに/あるいはアセンブリ/機械言語で実装可能である。本明細書で使用されるように、「機械読み取り可能媒体」、「コンピュータ読み取り可能媒体」という用語は、機械読み取り可能信号として機械命令を受信する機械読み取り可能媒体を含む、機械命令および/またはデータをプログラム可能プロセッサに提供するために使用される、任意のコンピュータプログラム製品、装置、および/またはデバイス(たとえば、磁気ディスク、光ディスク、メモリ、プログラマブル論理デバイス(PLD))を言い表す。「機械読み取り可能信号」という用語は、機械命令および/またはデータをプログラム可能プロセッサに提供するために使用される、任意の信号を言い表す。

ユーザとの相互作用を提供するために、本書で説明されるシステムおよび技法は、ユーザに情報を表示するためのディスプレイデバイス(たとえばCRT(陰極線管)またはLCD(液晶ディスプレイ)モニタ)、およびユーザがコンピュータに入力する際に使用可能なキーボードおよびポインティングデバイス(たとえばマウスまたはトラックボール)を有する、コンピュータ上に実装可能である。他の種類のデバイスを使用して、ユーザとの相互作用を提供することも可能であり、たとえばユーザに提供されるフィードバックは、任意の形の知覚フィードバック(たとえば視覚フィードバック、聴覚フィードバック、または触覚フィードバック)とすることが可能であり、ユーザからの入力は、音響入力、音声入力、または触覚入力を含む、任意の形で受信可能である。

本書で説明されるシステムおよび技法は、バックエンド構成要素を(たとえばデータサーバとして)含む、またはミドルウェア構成要素(たとえばアプリケーションサーバ)を含む、またはフロントエンド構成要素(たとえば、ユーザが本書で説明されるシステムおよび技法の一実装形態と相互作用する際に使用可能な、グラフィカルユーザインターフェースまたはウェブブラウザを有するクライアントコンピュータ)を含む、あるいは、こうしたバックエンド、ミドルウェア、またはフロントエンドの構成要素の任意の組み合わせを含む、コンピューティングシステムで実装可能である。システムの構成要素は、任意の形または媒体のデジタルデータ通信(たとえば通信ネットワーク)によって相互接続可能である。通信ネットワークの例には、ローカルエリアネットワーク(「LAN」)、ワイドエリアネットワーク(「WAN」)、およびインターネットが含まれる。

コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントおよびサーバは、一般に互いにリモートであり、典型的には通信ネットワークを介して相互作用する。クライアントおよびサーバの関係は、それぞれのコンピュータ上で実行中であり、互いにクライアント対サーバの関係を有する、コンピュータプログラムによって生じる。

以上、いくつかの実施形態について説明してきた。それでもなお、本発明の趣旨および範囲を逸脱することなく、様々な修正が実行可能であることを理解されよう。たとえば、本書の大部分は、マクロの実行をトリガする特定のモードに関して説明されているが、他の手法も使用可能である。

加えて図面に示された論理フローは、所望の結果を達成するために、示された特定の順序、または連続した順序である必要はない。加えて、他のステップが提供可能であるか、または記載された流れからステップを消去することが可能であり、記載されたシステムに他の構成要素を追加するか、またはここから除去することが可能である。したがって、他の実施形態は以下の特許請求の範囲内にある。

100 ホスト型コンピューティングシステム
102 アプリケーション＃1
104 マクロフック
106 マクロサーバサブシステム
108 ソーシャルネットワーク
110 位置サービス
112 マクロコード

Claims (20)

1. インターネットアクセスが可能なホスト型コンピュータシステムでコンピュータマクロに関するコードを格納するステップと、
   前記格納されたコードを前記ホスト型コンピュータシステム上のユーザアカウントに関連付けるステップと、
   前記ユーザアカウントに関連付けられたユーザが現在前記ホスト型コンピュータシステム上でアクティブであるかどうかに関係なく、前記ホスト型コンピュータシステムを使用して、前記マクロを対象としているものとして定義付けられるトリガイベントを自動的に識別するステップと、
   マクロ結果を生成するために、前記ホスト型コンピュータシステム上で実行中のアプリケーションを使用して前記マクロを実行し、前記マクロ結果を前記ホスト型コンピュータシステム上に格納するステップと
   を含む、コンピュータマクロを管理するためのコンピュータ実装方法。
2. 前記マクロ結果をユーザに通知する、前記ユーザアカウントに関連付けられた通信アドレスへのメッセージを生成するステップをさらに含む、請求項1に記載の方法。
3. 前記トリガイベントは、前記ユーザアカウントに向けて送られるデジタル通信の着信を含む、請求項1に記載の方法。
4. 前記トリガイベントは、アカウントホルダに関連付けられたコンピュータデバイスユーザの位置の決定を含む、請求項1に記載の方法。
5. 前記マクロを前記ホスト型コンピュータシステムの登録ユーザに関連付けるステップと、前記登録ユーザによって識別されたアクセス制限に従って、前記ホスト型コンピュータシステムの他のユーザが前記マクロを使用できるようにするステップとをさらに含む、請求項1に記載の方法。
6. 前記マクロには、複数の異なるユーザアカウントからのトリガイベントに応答して、アクセス可能である、請求項5に記載の方法。
7. 前記ホスト型コンピュータからリモートの複数の異なるクライアントコンピュータ上で実行中の複数のアプリケーションから前記マクロを実行する旨の要求を受信するステップと、前記位置からの各前記要求に対して前記ホスト型コンピュータシステム上で前記マクロを自動的に実行するステップと、前記マクロの実行に応答して、前記複数のアプリケーションのうちのそれぞれのアプリケーションに前記マクロの実行結果を提供するステップとをさらに含む、請求項1に記載の方法。
8. 前記マクロを実行するステップは、前記ホスト型コンピュータシステムによって提供された複数の異なるホスト型サービスへの呼び出しを行うステップを含む、請求項1に記載の方法。
9. 前記マクロを実行するステップは、前記ホスト型コンピュータシステムとは無関係の第3者情報プロバイダによって提供されるウェブサービスへの呼び出しを行うステップを含む、請求項8に記載の方法。
10. 前記ホスト型コンピュータシステム上で実行中の第1のアプリケーションによって生成された情報を異なるフォーマットに変換するステップと、前記変換された情報を前記ホスト型コンピュータシステム上で実行中の第2のアプリケーションに提供するステップとをさらに含む、請求項1に記載の方法。
11. 前記ホスト型コンピュータシステムに登録された複数の異なるユーザに関する複数の異なるアカウントに、前記マクロの実行結果を自動的に提供するステップをさらに含む、請求項1に記載の方法。
12. ホスト型コンピュータシステムから動作可能な複数のホスト型アプリケーションと、
    それぞれが前記ホスト型コンピュータシステム上のユーザアカウントに割り当てられ、それぞれが前記複数のホスト型アプリケーションのうちの少なくとも1つによって実行されることになる一連のアクションを定義付ける、複数のマクロを格納するマクロデータストアと、
    システム内のトリガイベントを識別し、前記複数のマクロのうちの1つに対応する識別されたトリガイベントに応答して、前記複数のマクロのうちの1つの実行を開始する、スケジューリングモジュールを動作させるためのプロセッサと
    を備える、ホスト型コンピュータシステム上でマクロを実行するためのコンピュータ実装システム。
13. 前記マクロの結果をユーザに通知する、前記ユーザアカウントに関連付けられた通信アドレスへのメッセージを生成するようにプログラミングされたインターフェースを動作させる、プロセッサをさらに備える、請求項12に記載のシステム。
14. 前記トリガイベントは、前記ユーザアカウントに向けて送られるデジタル通信の着信を含む、請求項12に記載のシステム。
15. 前記システムに関するアカウントホルダの位置を追跡するための位置サービスをさらに備え、前記トリガイベントは、それに代わって前記マクロが実行される第1のアカウントホルダに関連付けられた第2のアカウントホルダの位置の決定を含む、請求項12に記載のシステム。
16. 前記マクロには、複数の異なるユーザアカウントからのトリガイベントに応答してアクセスすることが可能な、請求項12に記載のシステム。
17. 前記システムに関する複数のアカウントホルダに関連付けられた複数の文書をさらに含み、前記複数の文書は、前記マクロデータストアに格納されたマクロへのポインタを含む、請求項12に記載のシステム。
18. マクロからの呼び出しに応答して前記ホスト型コンピュータシステムに登録されたユーザの位置に関する情報を提供するための、位置サービスをさらに備える、請求項12に記載のシステム。
19. 前記位置サービスは、そのアカウント内でマクロが実行中のユーザが、その位置情報が提供されることになるユーザに関連付けられているものとして前記システムによって識別された場合にのみ、位置に関する情報を提供する、請求項12に記載のシステム。
20. ホスト型コンピュータシステムから動作可能な複数のホスト型アプリケーションと、
    それぞれが前記ホスト型コンピュータシステム上のユーザアカウントに割り当てられ、それぞれが前記複数のホスト型アプリケーションのうちの少なくとも1つによって実行されることになる一連のアクションを定義付ける、複数のマクロを格納するマクロデータストアと、
    特定のアカウントホルダに関連付けられたトリガイベントの識別に応答して、前記複数のマクロを実行するための手段であって、前記トリガイベントは、前記特定のアカウントホルダがシステムにログインしているかどうかに関係なく発生する、実行するための手段と
    を備える、ホスト型コンピュータシステム上でマクロを実行するためのコンピュータ実装システム。

Images