(57)【要約】【課題】モバイル無線通信で使用されるショート・メッセージ・サービスおよび他のメッセージング・サービスを商用メッセージングに適用するための方法および装置を提供すること。【解決手段】本発明は、ソフトウェア・アプリケーションによる処理のためのＳＭＳビジネス・メッセージを生成する方法であって、データ収集インターフェースが、前記ソフトウェア・アプリケーションからの発信される指示および発信されるデータを受理するステップと、メッセージ・エンコーディング・エンジンが、前記ソフトウェア・アプリケーションからの前記発信される指示および発信されるデータを、エンコーディング・テンプレートを用いてエンコードして、前記ＳＭＳビジネス・メッセージを、データ処理システムによる処理のためにフォーマットした、分類済みＳＭＳメッセージとして生成するステップと、ディスパッチャ・ランタイム・プロセッサが、前記ＳＭＳビジネス・メッセージを、受信者にネットワークを介して送信するために処理するステップとを含む方法を提供する。
2006501561.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア・アプリケーションによる処理のためのＳＭＳビジネス・メッセージを生成する方法であって、
データ収集インターフェースが、前記ソフトウェア・アプリケーションからの発信される指示およびデータを受理するステップと、
前記ＳＭＳビジネス・メッセージを、データ処理システムによる処理のためにフォーマットした分類済みＳＭＳメッセージとして生成するために、メッセージ・エンコーディング・エンジンが、前記ソフトウェア・アプリケーションからの発信される前記指示および前記データを、エンコーディング・テンプレートを用いてエンコードするステップと、[MSOffice1]  ディスパッチャ・ランタイム・プロセッサが、前記ＳＭＳビジネス・メッセージを、受信者にネットワークを介して送信するために処理するステップと
を含む方法。
【請求項２】
前記ＳＭＳビジネス・メッセージを、ネットワークを介して受信者に送信するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記ＳＭＳビジネス・メッセージが、
受信者に商取引イベントについて注意を喚起するためのメッセージ・テキスト・エントリ・フィールドと、
暗号化文字列エントリ・フィールドと
を含む、請求項２に記載の方法。
【請求項４】
前記ＳＭＳビジネス・メッセージが、
応答インジケータ・ラベル（indicator label）と、
前記応答インジケータ・ラベルと関連付けられた受信者データ・エントリ・フィールドと、
受信者認証インジケータ・ラベルと、
前記受信者認証インジケータ・ラベルと関連付けられた受信者認証データ・エントリ・フィールドと
をさらに含む、請求項３に記載の方法。
【請求項５】
前記暗号化文字列エントリ・フィールドが、通信セッション識別データを受理するように適合されている、請求項３または４に記載の方法。
【請求項６】
前記通信セッション識別データを使用して、送ったメッセージに対する応答を関連付けることができる、請求項５に記載の方法。
【請求項７】
前記セッション識別データを使用して、送ったメッセージに対する応答を処理するソフトウェア・アプリケーションを識別することができる、請求項６に記載の方法。
【請求項８】
前記暗号化文字列エントリ・フィールドが、セキュリティ・データを受理するように適合されている、請求項３または４に記載の方法。
【請求項９】
前記受信者認証データ・エントリ・フィールドが、前記受信者からの個人識別番号（ＰＩＮ）を受理するように適合されている、請求項４に記載の方法。
【請求項１０】
ＳＭＳビジネス・メッセージが、
応答する受信者が応答を挿入できるように適合されている、前記応答インジケータ・ラベルと関連付けられた第１の受信者データ・エントリ・フィールドと、
応答する受信者が応答を挿入できるように適合されている、前記受信者認証インジケータ・ラベルと関連付けられた第２の受信者データ・エントリ・フィールドと
をさらに含む、請求項４に記載の方法。
【請求項１１】
前記エンコーディング・テンプレートが、
ＳＭＳビジネス・メッセージの分類を定義する分類メタ・データを含み、
前記分類が、特定のビジネスを意図した使用法を表し、
前記分類メタ・データが、前記分類の定義を提供し、
前記分類メタ・データは、前記データ処理システムにより、ＳＭＳビジネス・メッセージを生成するために構文解析可能である、請求項１に記載の方法。
【請求項１２】
前記エンコーディング・テンプレートが、
受信者がアクセスするためにＳＭＳメッセージの長さ全体のメッセージ・エントリを挿入するためのメッセージ・エントリ・フィールドを含み、
前記テンプレートが、分類メタ・データのために、前記ＳＭＳビジネス・メッセージ内に追加のフィールドを提供し、
前記メタ・データが、ＳＭＳビジネス・メッセージのビジネスを意図した使用法をエンコードするための指示を提供する、請求項１１に記載の方法。
【請求項１３】
前記メタ・データが、
前記ＳＭＳビジネス・メッセージを発送するための指示を含み、
前記指示が、
メッセージ優先度と、送付時間と、受信者数と、送付チャネルと、確認の必要性と、認証の必要性と、暗号化の必要性と、応答を取り扱うためのＷｅｂアプリケーションとのうちより選択される指示を含む、請求項１２に記載の方法。
【請求項１４】
前記メタ・データが、前記ＳＭＳビジネス・メッセージへの応答を取り扱うためのソフトウェア・アプリケーションを識別するための指示を含む、請求項１２に記載の方法。
【請求項１５】
サーバが、前記ＳＭＳビジネス・メッセージの送信に応答して、受信者からの応答メッセージを受け取るステップと、
前記応答メッセージが前記サーバに向けられたものであることを検証するために、前記ＳＭＳ応答メッセージ内部の暗号化文字列を適切なキーによって復号するステップと、
前記応答内の情報を処理するために、前記ＳＭＳ応答メッセージから情報を抽出するステップと、
前記サーバからの前記応答メッセージに対する対応するインバウンド・テンプレートを識別して得るステップと、
前記応答メッセージに含まれる着信するデータおよび着信する指示の抽出を、それが存在する場合には、前記データおよび指示の処理のために行うために、前記応答メッセージを前記インバウンド・テンプレートによって構文解析するステップと
をさらに含む、請求項２に記載の方法。
【請求項１６】
前記着信するデータおよび着信する指示を、処理のためにアプリケーション・サーバへと転送するステップをさらに含む、請求項１５に記載の方法。
【請求項１７】
前記ＳＭＳ応答メッセージが、暗号化キーによって暗号化された暗号化文字列と、
前記応答を処理する能力のあるソフトウェア・アプリケーションの識別と、
ユーザ認証情報と
を含む、請求項１６に記載の方法。
【請求項１８】
前記サーバが前記暗号化キーに対するアクセス権を有し、
前記サーバが前記インバウンド・テンプレートに対するアクセス権を有する、
請求項１７に記載の方法。
【請求項１９】
サーバが、前記ＳＭＳビジネス・メッセージの送信に応答して、受信者からＳＭＳ応答メッセージを受け取るステップと、
応答追跡データベースが、応答追跡データベース内の前記ＳＭＳ応答メッセージを追跡するステップと
をさらに含む、請求項２に記載の方法。
【請求項２０】
インバウンド・テンプレート・データベースが、前記ＳＭＳ応答メッセージを識別し構文解析するステップと、
前記ディスパッチャ・ランタイム・プロセッサが、前記ＳＭＳ応答メッセージを処理し、前記ＳＭＳ応答メッセージを前記ソフトウェア・アプリケーションへと転送するステップと
をさらに含む、請求項１９に記載の方法。
【請求項２１】
ソフトウェア・アプリケーションによる処理のためのＳＭＳビジネス・メッセージを生成するシステムであって、
前記ソフトウェア・アプリケーションからの発信される指示および発信されるデータを受理するデータ収集インターフェースと、
前記ＳＭＳビジネス・メッセージを、データ処理システムによる処理のためにフォーマットした、分類済みＳＭＳメッセージとして生成するために、前記ソフトウェア・アプリケーションからの前記発信される指示および発信されるデータを、エンコーディング・テンプレートを用いてエンコードするメッセージ・エンコーディング・エンジンと、
前記ＳＭＳビジネス・メッセージを、受信者にネットワークを介して送信するために処理するディスパッチャ・ランタイム・プロセッサと
を含むシステム。
【請求項２２】
デジタル・コンピュータの内蔵メモリへと直接ロード可能なコンピュータ・プログラムであって、前記コンピュータ・プログラムをコンピュータ上で稼動させると、請求項１ないし２０のいずれかに記載の方法を実行するソフトウェア・コード部分を含む、コンピュータ・プログラム。
【請求項２３】
発信されるｅ−コマースＳＭＳメッセージに応答する受信者からサーバが受け取る着信するｅ−コマースＳＭＳ応答メッセージを処理する方法であって、
前記ＳＭＳ応答メッセージを受け取るステップと、
前記応答メッセージが前記サーバに向けられたものであることを検証するために、前記ＳＭＳ応答メッセージ内部の暗号化文字列を適切なキーによって復号するステップと、
前記応答内の情報を処理するために、前記ＳＭＳ応答メッセージから情報を抽出するステップと、
前記サーバからの前記応答メッセージに対する対応するインバウンド・テンプレートを識別して得るステップと、
前記応答メッセージに含まれるデータおよび指示の抽出を、それが存在する場合には、前記データおよび指示の処理のために行うために、前記応答メッセージを前記インバウンド・テンプレートによって構文解析するステップと
を含む方法。
【請求項２４】
コマース・メッセージをネットワークを介して受信者へと送るのに使用するためのＳＭＳコマース・メッセージ・フォーマットであって、
受信者に商取引イベントについて注意を喚起するためのメッセージ・テキスト・エントリ・フィールドと、
暗号化文字列エントリ・フィールドと
応答インジケータ・ラベルと、
前記応答インジケータ・ラベルと関連付けられた受信者データ・エントリ・フィールドと、
受信者認証インジケータ・ラベルと、
前記受信者認証インジケータ・ラベルと関連付けられた受信者認証データ・エントリ・フィールドと
を含む、ＳＭＳコマース・メッセージ・フォーマット。
【請求項２５】
前記暗号化文字列エントリ・フィールドが、通信セッション識別データを受理するように適合されている、請求項２４に記載のＳＭＳメッセージ・フォーマット。
【請求項２６】
前記暗号化文字列エントリ・フィールドが、セキュリティ・データを受理するように適合されている、請求項２４に記載のＳＭＳメッセージ・フォーマット。
【請求項２７】
前記受信者認証データ・エントリ・フィールドが、前記受信者からのＰＩＮ番号を受理するように適合されている、請求項２４に記載のＳＭＳメッセージ・フォーマット。
【請求項２８】
ネットワークを介して送信を行うデータ処理システムのためにアウトバウンドＳＭＳビジネス・メッセージをエンコードするためのＳＭＳユニバーサル・エンコーディング・テンプレートであって、
アウトバウンドＳＭＳメッセージの分類を定義する分類メタ・データと、
特定のビジネスを意図した使用法を表す前記分類と、
メッセージおよび指示の定義を提供し、前記データ処理システムにより、ＳＭＳビジネス・メッセージを生成するために構文解析可能である前記分類メタ・データと
を含む、ＳＭＳユニバーサル・エンコーディング・テンプレート。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ｅ−コマース通信の分野に関し、より詳細には、モバイル無線通信で使用されるショート・メッセージ・サービスおよび他のメッセージング・サービスを商用メッセージングに適用するための方法および装置に関する。
【背景技術】
【０００２】
モバイル・コマース（mobile commerce）は、ユーザがビジネス・トランザクションをいつでも、どこでも実行できるように便宜を提供する。ＷＡＰ（WirelessApplication Protocol）は数年の間存続しているが、ＷＡＰ利用可能な携帯電話、および他のそのようなＷｅｂ利用可能な無線装置の市場への浸透度は、まだかなり低いものにとどまっている。今日、モバイル・コマースの空間で最も確立された技術は、モバイル無線装置上のショート・メッセージ・サービス（ＳＭＳ、ShortMessage Services）である。その高い浸透度と採用率により、ＳＭＳの市場はモバイル・コマース利用の主要なターゲットとなっている。
【０００３】
本発明によって企図されているコマース機能を伴うＳＭＳ通知の例は、
ユーザに対するマーケティング主導メッセージ、すなわち、たとえば、ディスカウント情報、促進、および他のコマース・キャンペーン情報、
ビジネス・イベントの通知、すなわち、たとえば、注文受け取り確認、発送確認、および
締め切りのある支払い、または他の締め切り主導型備忘通知（reminder）などの運用効率のための通知
を含む。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし今日、様々な内的な技術的ハードルおよび限界が、ＳＭＳには存在し、これにより、そのコマースＷｅｂアプリケーションにおける応用および利用が困難かつ非実用的なものとなっている。
【０００５】
従来の技術には多くの制限があり、またビジネス環境におけるＳＭＳメッセージングの使用には条件が存在する。以下は、こうした制限および条件の考察である。
【０００６】
コマース・トランザクションにおいてＳＭＳを使用する制限
ＳＭＳにセマンティクスの概念が存在しないことが、コマース・アプリケーションにおけるＳＭＳの使用を困難なものとしている。その困難は、
所与のビジネス目的を正確に実装するためにＳＭＳメッセージをエンコードすること、および、そのビジネス目的が要求するように、これに対応するＳＭＳメッセージのラン・タイムの取り扱い
にある。
【０００７】
エンコードに対する障壁
ＳＭＳメッセージは、本来、型のない、状態のない、セッションのない、またデータ処理システムにとって意味のないものである。現在、ＳＭＳメッセージングの主な目的は、モバイル装置間での個人間の通信となっている。
【０００８】
しかしながら、ＳＭＳメッセージがビジネス・トランザクションの手段として生き残るためには、ＳＭＳは単なる２者間の気軽なやり取りであることはできない。ビジネス・トランザクションの要件には、追跡能力、確認、および否認防止を含む。また、これは、どのようなＷｅｂアプリケーションまたはこれを取り扱う他のデータ・プロセッサによっても理解される必要がある。ここでは、こうした要件をまとめてＳＭＳメッセージングの「セマンティクス」と定義することにする。
【０００９】
たとえば、
所与の組のビジネス・ルールでは、ＳＭＳメッセージのサブセットを、
ｉ．確認された到着
ｉｉ．否認防止のための到着の記録済みタイムスタンプ
ｉｉｉ．ＳＭＳメッセージの受領に対する受領通知
などのトランザクションの否認防止のため、送付（delivery）時に確認することが必要となる可能性がある。
【００１０】
また、所与の組のＳＭＳメッセージを、所与のスケジュールに基づいて定期的に送付することも、ビジネス要件となる可能性がある。この例は、
ｉ．インボイスの毎月の催促状
ｉｉ．ＳＭＳメッセージによる定期的な販売促進
を含む。
【００１１】
企業では、メッセージ到着の検査または確認を必要とすることなく、複数のユーザに接触するために、ブロードキャスト型のＳＭＳメッセージが必要になることがある。この例は、
ｉ．全店での販売促進ブロードキャスト
を含む。この場合、おそらく受領通知は必要ないはずである。
【００１２】
ユーザがトランザクションを行うためにＳＭＳメッセージを送信したいとすると、ＳＭＳメッセージのテキストにエンコードされた（たとえば、所与の品物を購入するという）そのユーザの意図を、Ｗｅｂアプリケーションまたはユーザの着信するＳＭＳメッセージを取り扱う他のアプリケーションは、一義的に（unambiguously）理解しなければならない。
【００１３】
ビジネス上の意図を正確に表現するためにＳＭＳメッセージを正しくエンコードすることは、技術的に複雑で困難な作業であり、人的な誤りが非常に入りやすい。エンコードの際の人的な誤りは、デバッグおよび修正がしばしば非常に高くつき、困難である。ビジネス・ユーザは、自分たちのビジネス上の目的を達成するために、ＳＭＳを使用する際に効率および信頼性を望んでいる。ＳＭＳメッセージを自分たちのビジネス・プロセスで使うときには、そのような技術的な複雑さから逃れる必要がある。ビジネス・ユーザは、通常、
ｉ．所与のＳＭＳメッセージのビジネス上の意図を決定すること
ｉｉ．（エンコードの種々の技術的詳細で悩まずに）メッセージの適切な言い回しを作成すること
ｉｉｉ．メッセージがそのメッセージ区分の意図に見合わない場合はエラーを通知してもらうこと
に集中したいと思っている。
【００１４】
こうしたビジネス・トランザクションをはじめるビジネス・ユーザは、いまや、自分が達成しようとする種々で個別のビジネス目的に正確に対応するように、こうしたＳＭＳメッセージのすべてを手作業で正しくエンコードするというかなりの技術的困難に直面している。
【００１５】
ラン・タイムにセマンティクスを取り扱うことの困難
ＳＭＳメッセージのエンコードの際の手作業の技術的困難とは別に、ビジネス・プロセス要件を満たすためにラン・タイムにセマンティクスを取り扱うこともまた大きな問題となっている。
【００１６】
たとえば、ユーザに未処理の支払いを通知するＳＭＳメッセージでは、通常、「完全な顧客接触ポイント」（a completed customer touch point）を定義しているビジネス・プロセスが規定するように、ユーザの受領通知が必要である。
【００１７】
この場合、ＳＭＳメッセージを受け取ったときにユーザによる受領通知が来ないと、それは他のＳＭＳメッセージとは違うやり方で取り扱われる。
【００１８】
しかし、セマンティクスおよび分類（categorization）という概念は、今日のＳＭＳの空間では今のところ存在しない。
【００１９】
ＳＭＳメッセージにシンタクスがないことが、コマース・ビジネス・プロセスでのその使用を困難で非実際的なものにしている
ＳＭＳテキスト・ストリームのコマース・ビジネス・アクションへの対応付けの欠如
ＳＭＳメッセージは、どのようなエンコード方式もない簡単なテキスト・メッセージである。したがって、簡単な平文のＳＭＳメッセージは、上で触れた理由のほかに次の理由でコマース・トランザクションに適していない。すなわち、
ｉ．簡単なＳＭＳメッセージが、実行すべきコマース・トランザクションの型を示すことは現在できない。
ｉｉ．特定のトランザクションが必要とする追加パラメータは、標準的なやり方ではエンコードできず、このためバックエンドのコマース・アプリケーションで構文解析できない。
ｉｉｉ．ユーザの認証および認可（user authentication andauthorization）などの追加の詳細が標準的なやり方では取り扱えない。
ｉｖ．状態情報がないということは、コマース・トランザクションに必要な要求−応答モデルをコマースＳＭＳメッセージに適用できないということである。
ｖ．人間のユーザの応答としての１６０キャラクタの自由形式構成（free formcomposing）のために、採用は不可能かつ非実際的なものとなっている。
【００２０】
上記の問題により、Ｗｅｂアプリケーションまたは他のデータ処理アプリケーションから発信されたビジネス・メッセージに応答する必要のあるＳＭＳユーザ（人間とＷｅｂアプリケーションのどちらも）に対する深刻な有用性の問題が生じている。
【００２１】
ＳＭＳメッセージの一部としてエンコードされるパラメータのための記法の欠如
トランザクション情報を担うインバウンドのＳＭＳメッセージはすべて、データ完全性およびデータ有効性に関して妥当性検査が必要である。それだけでなく、所与のＷｅｂアプリケーションにＳＭＳメッセージを送るユーザは、正しい認証のために十分な情報をインバウンドＳＭＳメッセージ中にエンコードする必要がある。
【００２２】
たとえば、オンライン・オークションでＳＭＳを使用するには、オークションのある競り手が誰かほかの者にアウトビッド（outbid）されるたびに、競り手との通信に使うバックエンドＷｅｂアプリケーションから、登録している競り手が通知してもらうことが必要になる。競り手たちには、通知が来たときに、自分の競り値（bids）を上げるために応答する機構が与えられるべきである。
【００２３】
この例では、登録した競り手たちがオークションの無効通知（overridenotices）の受け取りを否定できないように、ＳＭＳメッセージを否認防止されるように送る必要がある。また、そのようなメッセージは、競り手たちにできるだけ速く届くように、利用可能な場合には、優先度の高いチャネルを介して送出しなければならない。さらに、オークションの競り手たちは、オークションに使用されているバックエンド・コマース・アプリケーションにコール・バックして、そのバックエンド・コマース・アプリケーションに受理可能な標準のＳＭＳメッセージ・テンプレートを用いて新しい競り値を入れる機構をもつ必要がある。バックエンドＷｅｂアプリケーションが適切なセマンティクスを実行するためには、こうしたＳＭＳメッセージを、バックエンド・コマース・アプリケーションが正しく構文解析しなければならない。
【００２４】
一例として、オークションのシナリオで必要なパラメータの１つは、競りの対象となる品目の特定のためのＳＫＵ番号になるはずである。バック・エンド・サーバと競り手のどちらの認証も、否認防止の目的のためには必要である。
【００２５】
ＳＭＳメッセージングにシンタクスがないために、次のようなビジネス・プロセスへの適用が極端に困難となっている。すなわち、
コマース・プロセス対応付け（mapping）
ユーザ認証
パラメータ受け渡し
データ妥当性検査
【００２６】
ＳＭＳをエンコードする際の技術的な複雑さにより、ビジネス・ユーザがその使用を採用するのが遅れている
ビジネスＳＭＳメッセージの発信者は、ビジネス・メッセージを送る必要のあるビジネス・ユーザたちである。こうしたユーザの一番の関心は、メッセージのビジネス上の流通（logistics）（送信のタイミング、そのメッセージを誰に送るかなど）およびメッセージそのもの（言い回しの選択など）に集中することであり、送付の媒体の技術に煩わされたいと望んでいない（また、通常その余裕もない）。たとえば、ＳＭＳメッセージをどのように送るかという技術的知識は、ビジネス・ユーザが扱いたいと望むものでなく、処理してもらうことを期待するものである。透過性（transparency）およびユーザ親和性（userfriendliness）が、ビジネス・ユーザには重要なのである。
【００２７】
商取引の利用における確認の必要性
商取引でＳＭＳを使用する重要な一要件は、ＳＭＳメッセージの受信者（recipient）からの確認の必要性である。次は、商取引でのＳＭＳ使用の際のそのような重要な要件の例のリストである。すなわち、
−  コマース・サーバからＳＭＳ通知を受け取ると、しばしば受信者はそのコマース・サーバにＳＭＳメッセージを送り返すことによって応答する必要がある。たとえば、受信者は、ＳＭＳ販売促進メッセージの広告した品物を買うためにそのコマース・サーバにＳＭＳメッセージを送るかもしれない。
−  否認防止要件を満たすこと、たとえば、顧客接触ポイントをすべて記録する必要がある。
−  また、確認には、インバウンド・メッセージ中でユーザＩＤの確認が必要になる。
【００２８】
商取引の利用におけるセキュリティの要件
商取引でＳＭＳを使用する別の重要な要件は、ビジネス・トランザクションを実行する際のセキュリティの必要性である。この要件は、
ユーザがＳＭＳメッセージを用いてトランザクションを開始するときの、ＷｅｂＳｐｈｅｒｅなどのＷｅｂアプリケーションによるユーザＩＤ認証、
正しいＷｅｂアプリケーションがユーザの要求を取り扱っていることがユーザに確実にわかるような、ユーザによるＷｅｂアプリケーションの認証、
認可されていないモバイル装置がトランザクションに使用されていないことを確認するためのユーザ認証（ユーザ確認の別のレイヤとして、好ましくはＰＩＮを使用することもできる）
を含む。
【００２９】
商取引の利用におけるセッションの要件
商取引でＳＭＳを使用する別の重要な要件は、セッションの要件である。しばしば、Ｗｅｂアプリケーションがそのユーザにアウトバウンド・メッセージを送出したときに（たとえば、「これから６時間以内にお買い上げいただければ電気製品がすべて５０％オフ」などのキャンペーン・メッセージ）、使用のＷｅｂアプリケーションは、指定した時間内にユーザが対応するアウトバウンド・メッセージにＳＭＳで応答を返すことを期待する。通常、このセッションの要件は、
アウトバウンドおよびインバウンドのＳＭＳメッセージに対応する（mapping to）要求および応答モデル、
タイム・アウト機構、および
セッション・データの共有機構
を含む。
【００３０】
コマース・アプリケーションでＳＭＳメッセージを使用することの大きな欠点の１つは、ＳＭＳメッセージにシンタクスがないことであり、コマース・ビジネス・プロセスでのこの使用は、そのために困難で非実際的なものとなっている。大きな欠点のもう１つは、ＳＭＳテキストのあらかじめ定義されたコマース・ビジネスのアクションまたはタスクへの対応付けがないことである。しばしば、ＳＭＳテキストが実行すべきコマース・トランザクションの型に対応付けられているが、普通、コマース・ビジネス・アクションには追加パラメータが必要である。人間のユーザによる１６０キャラクタの自由形式構成は非実際的である。
【００３１】
さらに、ＳＭＳがコマース・アプリケーションで採用されるためには、ユーザ認証、Ｗｅｂアプリケーション識別、ＳＭＳメッセージ受信者からの確認の受信、およびユーザの応答を、意図する商取引イベントと関連付ける能力を提供するためのセキュリティ機構に対する強い要件がある。
【課題を解決するための手段】
【００３２】
本発明は、第１の態様では、ソフトウェア・アプリケーションによる処理のためのＳＭＳビジネス・メッセージを生成する方法であって、データ収集インターフェースが、前記ソフトウェア・アプリケーションからの発信される指示およびデータを受理するステップと、前記ＳＭＳビジネス・メッセージを、データ処理システムによる処理のためにフォーマットした、分類済みＳＭＳメッセージとして生成するため、メッセージ・エンコーディング・エンジンが、前記ソフトウェア・アプリケーションからの前記発信される指示およびデータを、エンコーディング・テンプレートを用いてエンコードするステップと、ディスパッチャ・ランタイム・プロセッサ（dispatcher runtime processor）が、前記ＳＭＳビジネス・メッセージを、受信者にネットワークを介して送信するために処理するステップとを含む方法を提供する。
【００３３】
本発明は、第２の態様では、ソフトウェア・アプリケーションによる処理のためのＳＭＳビジネス・メッセージを生成するシステムであって、前記ソフトウェア・アプリケーションからの発信される指示およびデータを受理するデータ収集インターフェースと、前記ＳＭＳビジネス・メッセージを、データ処理システムによる処理のためにフォーマットした、分類済みＳＭＳメッセージとして生成するため、前記ソフトウェア・アプリケーションからの前記発信される指示および発信されるデータを、エンコーディング・テンプレートを用いてエンコードするメッセージ・エンコーディング・エンジンと、前記ＳＭＳビジネス・メッセージを、受信者にネットワークを介して送信するために処理するディスパッチャ・ランタイム・プロセッサとを含む手段を提供する。
【００３４】
本発明は、第３の態様では、デジタル・コンピュータの内蔵メモリへと直接ロード可能なコンピュータ・プログラムであって、前記コンピュータ・プログラムをコンピュータ上で稼動させると、データ収集インターフェースが、前記ソフトウェア・アプリケーションからの発信される指示およびデータを受理するステップと、前記ＳＭＳビジネス・メッセージを、データ処理システムによる処理のためにフォーマットした、分類済みＳＭＳメッセージとして生成するため、メッセージ・エンコーディング・エンジンが、前記ソフトウェア・アプリケーションからの前記発信される指示およびデータを、エンコーディング・テンプレートを用いてエンコードするステップと、ディスパッチャ・ランタイム・プロセッサが、前記ＳＭＳビジネス・メッセージを、受信者にネットワークを介して送信するために処理するステップとを含む方法を実行するソフトウェア・コード部分を含む、コンピュータ・プログラムを提供する。
【００３５】
本発明の好ましい実施形態の説明を、ここで、例として、添付の図面を参照して行う。
【発明を実施するための最良の形態】
【００３６】
図１に、ＳＭＳの使用可能なｅ−コマース・システムを、好ましい一実施形態の既存の諸システムにまさる改良を強調して示している。
【００３７】
ここまでで示したように、ＳＭＳは新しいものではない。この好ましい実施形態によるＳＭＳの使用可能なコマース通信システムを示す図１を参照すると、既存の技術は、従来技術（prior art）と表示した領域にあることがわかる。過去に、ＳＭＳメッセージをモバイル装置（たとえば、携帯電話）上で動く適切なアプリケーションに回送する問題を解決しようとする試みは存在した。
【００３８】
図１の「新しい問題領域（Problem Space）」と表示した領域は、今日存在するいくつかの基礎的なビルディング・ブロックを除き、新しいものである。基礎的なビルディング・ブロックが一部存在する可能性があるとはいえ、本明細書中の好ましい諸実施形態により、それらを適切なものとして向上させる際に、好ましい諸実施形態の提供する新しい機能を考慮に入れることができるようになる。
【００３９】
図１に示す実施形態を参照すると、ｅ−コマース・サーバ１０４はいくつかのコンポーネントからなることがわかる。すなわち、
アプリケーション・コンポーネント１０８：アプリケーション・コンポーネント１０８は、所与のコマース・サーバのビジネス・サブシステムを形成する。ビジネス・サブシステムのそれぞれは、所与のビジネス・プロセスを実装したものである。ビジネス・サブシステムの例は、とりわけ、注文管理、ユーザ管理、マーケティングおよびキャンペーンのサブシステムを含む。
【００４０】
共通メッセージ・サブシステム１０７：共通メッセージ・サブシステム１０７は、アプリケーション・コンポーネント１０８の生成するメッセージを取り扱う（そして処理する）総称的なメッセージ・ハンドリング・システムである。共通メッセージ・サブシステムは、電子メール、ファイル転送および他のメッセージの取り扱いおよび処理に関する事項を取り扱う。
【００４１】
図１に示す実装形態では、以下のものを含むいくつかの既存の機能およびプロセスを利用する。すなわち、
ＳＭＳメッセージ：１件のＳＭＳメッセージは、最大１６０キャラクタの長さの単純なテキスト・メッセージに限られる。これは、多くの無線ネットワークを通して送ることができる。ほとんどの携帯電話が、ＳＭＳメッセージを送信および受信する能力をもつ。
無線メッセージ・ゲートウェイ：無線メッセージ・ゲートウェイは、無線ネットワークとｅ−コマース・サーバ１０４の間でＳＭＳメッセージを回送できるコンピュータによって実装することができる。
ＳＭＳセンタ：ＳＭＳセンタ１０２は、通常、通信会社が、選択されたモバイル装置へのＳＭＳメッセージの送付を取り扱うために運用する。
【００４２】
データ収集インターフェース（番号１）：データ収集インターフェース１１７は、
ｉ．ＳＭＳメッセージ作成ウイザード１１２によるユーザ入力、および
ｉｉ．アプリケーション・コンポーネント１０８が生成し共通メッセージ・サブシステム１０７が転送したデータ
を収集する１組のインターフェースからなり、メッセージ・エンコーディング・エンジン１１１が使用することになるＳＭＳ入力データ・コレクションを生成する。
【００４３】
メッセージ・エンコーディング・エンジン（番号２）：メッセージ・エンコーディング・エンジン１１１は、データ収集インターフェース１１７が生成した入力データ・コレクションを入力とする。
【００４４】
次いで、メッセージ・エンコーディング・エンジン１１１は、ＳＭＳ入力データ・コレクション中のデータを使用して、ＳＭＳメッセージのエンコーディングをユーザの選択したＳＭＳの型にとって適切な属性付きで生成する。さらに、これはエラー検査のために、ユーザ入力の妥当性検査をＳＭＳユニバーサル・エンコーディング・テンプレート１１３とつき合わせて行う。
【００４５】
エンジン１１１内のこの自動生成機能により、人的な誤りによるエンコーディング・エラーがおそらくなくなる。また、これにより、メッセージの実装のための属性のエンコーディングの技術的な複雑さが、ビジネス・ユーザから隠匿される。メッセージ・エンコーディング・エンジン１１１は、出力として型付きＳＭＳメッセージのインスタンス１１４を作成する。
【００４６】
ランタイム・プロセッサ（番号３）：ＳＭＳメッセージ・ランタイム・プロセッサ１１０は、ＳＭＳ分類で定義されるビジネス・セマンティクスをラン・タイムに取り扱う。
ランタイム・プロセッサ１１０の基本的機能：
−  ＳＭＳメッセージに送付の確認、または期待される応答が要求されている場合には、ＳＭＳメッセージ・ランタイム・プロセッサ１１０が確認を常に把握する。
−  また、ＳＭＳメッセージ・ランタイム・プロセッサ１１０は、エンド・ユーザから返される応答を取り込み、インバウンド・テンプレート・データベース１１５から対応するインバウンド・メッセージ・テンプレートを探し出す役割をもつ。
−  ＳＭＳメッセージがスケジューリングされたメッセージである場合には、ＳＭＳメッセージ・ランタイム・プロセッサ１１０は送られるＳＭＳメッセージのスケジューリングを取り扱う。
−  ユーザの確認が来ない場合に、セマンティックスのアクションをさらに取ることができる。
−  また、ランタイム・プロセッサはラン・タイムのエラー検査およびエラー処理も行う。
【００４７】
ＳＭＳメッセージ作成ウイザード（番号４）：本発明の一実施形態によるＳＭＳコマース・インフラストラクチャ・システムの構造的対応付け（structural mapping）を示す図２を参照すると、ＳＭＳメッセージ作成ウイザード１１２は、ユーザがそのメッセージの意図した使用法を明確に形にする（articulate）際に誘導を行う。ＳＭＳメッセージ・エンコーディング・エンジン１１１は、ユーザ入力を使用して、ＳＭＳメッセージの生成を、ユーザ入力をＳＭＳ分類テンプレート１１３内の選択された、あらかじめ定義された型へと、以下のように対応付けることによって行う。すなわち、
ｉ．ＳＭＳメッセージ作成ウイザード１１２は、ユーザ入力を取り込み、データ収集インターフェース１１７を呼び出すと、後者は今度は適切なＳＭＳ入力データ・コレクションを作成する。
ｉｉ．ユーザがＳＭＳメッセージ作成ウイザード１１２によって新しいＳＭＳ分類を定義した場合、ＳＭＳメッセージ作成ウイザード１１２はＳＭＳユニバーサル・エンコーディング・テンプレート１１３の更新も行う。
ｉｉｉ．ビジネス・ユーザがエンド・ユーザからの関連付けられた要求される応答のあるＳＭＳメッセージを定義した場合には、ビジネス・ユーザは、その要求される応答をアプリケーション・コンポーネント１０８が要求し理解するように、ＳＭＳメッセージ作成ウイザード１１２によってテンプレートの形で定義する。ＳＭＳメッセージ作成ウイザード１１２は、この入力を取り込み、インバウンド・テンプレート・データベース（部分番号９）１１５を更新する（図１を参照されたい）。
【００４８】
ＳＭＳユニバーサル・エンコーディング・テンプレート（番号５）：ＳＭＳユニバーサル・エンコーディング・テンプレート１１３は、アウトバウンドおよびインバウンドのＳＭＳメッセージ分類（または「型」）を定義するメタ・データを含む。ＳＭＳ分類のそれぞれは、所与のビジネスを意図した使用法（business intended usage）を表す。これは、エンコーディングに対しておよびラン・タイムに対してセマンティクスの定義を提供する。
【００４９】
この矛盾なく定義された（well-defined）ＳＭＳメッセージ分類を使うと、いまや意図された使用を反映する正しいエンコーディングによる自動的なＳＭＳ生成が可能になる。追加のＳＭＳメッセージ分類を、さらに既存の型から導出することができる。
【００５０】
このエンティティにより、セマンティックスの定義および取り扱いのための機構が提供され、それにより、いまやＳＭＳにおける正しいセマンティックスの取り扱いができるようになるため、これによって本発明の重要な一様態が提供される。
【００５１】
ＳＭＳユニバーサル・エンコーディング・テンプレート１１３を使うと、ビジネス・ユーザは、メッセージ・エンコーディング・エンジン１１１およびランタイム・プロセッサ１１０でのどのようなコード変更もなしに、新しいＳＭＳメッセージ型を定義することができ、それにより、どちらのコンポーネントも総称的（generic）なものとなる。
【００５２】
型付きＳＭＳメッセージ・インスタンス（番号６）：型付きＳＭＳメッセージ・インスタンス１１４は、メッセージ・エンコーディング・エンジン１１１が生成して、ランタイム・プロセッサ１１０が使用することになる。
【００５３】
以下は型付きＳＭＳメッセージ・インスタンスの一例である。
<GenericSMSMessage>
<short_message_text>Something</short_message_text>
<ReceiverProfile>
<userid>steve</userid>
<cellphonenumber>4161234567@cellphone.com</cellphonenumber>
<deliverychannel>SMTP</deliverychannel>
</ReceiverProfile>
</GenericSMSMessage>
【００５４】
ＳＭＳ応答追跡ＤＢ（番号７）：ＳＭＳ応答追跡データベース１１６では、そのエンコードされた型の要求する応答要求メッセージがすべて捉えられている。これにより、ランタイム・プロセッサ１１０は、要求された応答メッセージが期待した応答を受け取り正しいラン・タイム処理を実行することを保証できるようになる。また、これにより、システムの期待する、ユーザの開始するインバウンド・メッセージを取り扱う基本機構が可能になる。
【００５５】
インバウンド・テンプレート・データベース（番号８）：インバウンド・テンプレート・データベース１１５には、ビジネス・ユーザの指定するインバウンド・メッセージ・テンプレートがすべて保存されている。
【００５６】
図１からのフローの注記：ここに示す本発明の実施形態によるＳＭＳメッセージの形成、処理、および通信を、図１中に示す英数字でラベル付けした矢印によって示している。図２には、図１によるＳＭＳコマース・システム構造的対応付けを提示している。本実施形態の理解は、図１および２を参照する際に以下の説明を読むことによって達成することができよう。
Ａ１：共通ユーザ・インターフェース１０６を利用するビジネス・ユーザ１０５が、メッセージを準備するために、ＳＭＳメッセージ作成ウイザード（番号４）１１２呼び出す。
Ｂ１：ビジネス・ユーザが、ＳＭＳメッセージ作成ウイザード１１２を使用して、ＳＭＳユニバーサル・エンコーディング・テンプレート（番号５）１１３に定義された既存の型に基づいてＳＭＳメッセージを送る。
Ａ２：ウイザード１１２が、ユーザ入力をすべて捉え、データ収集インターフェース（番号１）１１７を呼び出す。
Ｂ２：ビジネス・ユーザが、ＳＭＳメッセージ作成ウイザード１１２を使用して、新しいＳＭＳメッセージ型を定義する。
Ａ３：ビジネス・ユーザが、ウイザード１１２を使用して、あらかじめ設定しておくユーザ応答の定義を新しいインバウンド・テンプレートを作成することによって行う。ウイザード１１２が、インバウンド・テンプレートＤＢ（番号８）１１５を更新する。
Ｃ１：メッセージ・エンコーディング・エンジン（番号２）１１１が
−  ＳＭＳユニバーサル・エンコーディング・テンプレート（番号５）１１３を取り出す。
−  データ収集インターフェース（番号１）１１７が捉えたデータをＳＭＳユニバーサル・エンコーディング・テンプレート１１３とつき合わせて妥当性検査し、エラー検査を実行する。
Ｃ２：メッセージ・エンコーディング・エンジン１１１が、出力として型付きＳＭＳメッセージ・インスタンス（番号６）１１４を生成する。図２を参照すると、このメッセージは、ＸＭＬでエンコードしたメッセージ２０１とすることができる。
Ｄ２：メッセージ・エンコーディング・エンジン１１１が、ランタイム・プロセッサ（番号３）１１０を呼び出し、これが、Ｃ２で生成された、生成済み型付きＳＭＳメッセージ・インスタンス１１４を取り出す。
Ｄ３：このＳＭＳメッセージ型でユーザ応答が要求される場合、ランタイム・プロセッサ１１０は、ＳＭＳ応答追跡ＤＢ（番号７）１１６を更新することにより、このメッセージをユーザ応答を必要とするものとして登録する。
Ｄ４：ランタイム・プロセッサ１１０は、この型付きＳＭＳメッセージ・インスタンス１１４を、図２でEveryplace Wireless Gateway２０３と呼ばれている、無線メッセージ・ゲートウェイ１０３へと送信する。
Ｄ５：着信ＳＭＳメッセージが無線メッセージ・ゲートウェイ１０３へと送られると、これはその着信メッセージをランタイム・プロセッサ１１０へと回送し、今度はこれが、インバウンド・テンプレートＩＤをその着信ＳＭＳメッセージから抽出する。
Ｄ１：ランタイム・プロセッサ１１０が、ＳＭＳユニバーサル・エンコーディング・テンプレート１１３を読み込んで、アウトバウンドのラン・タイム処理のために、型に適切なセマンティクスを取り扱い、そのインスタンスが正しくなるようにする。
Ｄ６：次いで、ランタイム・プロセッサ１１０は、インバウンド・テンプレートＤＢ（番号８）から対応するインバウンド・テンプレートを抽出し、そのインバウンド・テンプレートを用いてインバウンドＳＭＳメッセージを構文解析する。ランタイム・プロセッサ１１０は、インバウンドＳＭＳメッセージをデコードして、取り扱いのため、これを対応するアプリケーション・コンポーネント１０８へと回送する。携帯電話１０１（図１）などのユーザのＳＭＳ装置１２０（図２）どうしのＳＭＳの通信は、電話会社の携帯電話インターフェース１０２が取り扱い、無線ゲートウェイ１０３はこれと、メッセージを送りまたは受け取るのに必要な通信を行う。
Ｄｘ  ランタイム・プロセッサ１１０は、アプリケーション・コンポーネント１０８にラン・タイム・エラーを報告して返す。
【００５７】
１．ＳＭＳメッセージ分類（型）
ＳＭＳメッセージ分類を定義するための方法および装置
ＳＭＳユニバーサル・エンコーディング・テンプレート１１３により、ＳＭＳメッセージ分類を定義する機構が提供される。これは、好ましくは、ＳＭＳメッセージ分類を構成する、ＳＭＳメッセージのメタ・データ（たとえば、所与のメッセージの属性および特徴）を指定するＸＭＬスキーマ（XML schema）として実装する。
【００５８】
コマースＳＭＳメッセージ・テンプレートの設計は、好ましくは、ＳＭＳメッセージの商取引上の型付け（分類）を提供するように行う。ＳＭＳユニバーサル・エンコーディング・テンプレート１１３により、ユーザが、新しいＳＭＳメッセージ型の拡張および定義を、あらかじめ存在する定義済みの型からの継承によって行う機構が提供される。ユーザはこれにより、オリジナルのＳＭＳ分類テンプレートにあるＳＭＳメッセージ型を拡張して、新しいＳＭＳの型を定義することができる。
【００５９】
ビジネス・ユーザは、既存のＳＭＳの型を使用でき、またこれを拡張して新しいメッセージ型を作成することができる。ビジネス・ユーザは、拡張した型の中で新しい属性を指定するだけでよい。（この新しいメッセージ型が拡張される）基本メッセージ型の属性は、すべて設定されることになり、ビジネス・ユーザはこれを再指定する必要はない。
【００６０】
所与のＳＭＳ分類に関連付けられたセマンティクスを定義する機構
本発明の好ましい一実装形態では、ＳＭＳメッセージのエンコードが必要になると、メッセージ・エンコーディング・エンジン（番号２）１１１がＸＭＬパーサを呼び出して、ＳＭＳユニバーサル・エンコーディング・テンプレート１１３をＪａｖａ（Ｒ）ラン・タイム・オブジェクトに翻訳する。ＸＭＬパーサは、このメッセージ・エンコーディング・エンジンの一部でもよく、または当業者の了解可能なように、これに利用可能であってもよい。こうしたラン・タイム・オブジェクトにより、メッセージ・エンコーディング・エンジン１１１がＳＭＳメッセージを生成するのに必要なセマンティクスの情報が提供される。
【００６１】
こうした状況で、メッセージ・エンコーディング・エンジン１１１は、いまやＸＭＬパーサを使用して、所与のメッセージのインスタンスをＳＭＳユニバーサル・エンコーディング・テンプレート１１３とつき合わせて構文解析することができる。これにより、エラー検査の自動的な機構が提供される。ＳＭＳメッセージの型定義に照らして不適切な、所与のＳＭＳメッセージ内の不足するまたは予期しないどのような情報も、メッセージの構文解析中にエラーとなる。
【００６２】
また、ラン・タイム時には、ＳＭＳランタイム・プロセッサ（番号３）１１０も、ＳＭＳメッセージ型に基づいて種々のラン・タイム・セマンティクスおよびエラー検査を取り扱うために、ＳＭＳユニバーサル・エンコーディング・テンプレート１１３の提供する分類情報を読み込む。
【００６３】
ＳＭＳメッセージのラン・タイム処理は、次の諸態様を包含する。
１．アウトバウンドＳＭＳメッセージの構文解析
２、アウトバウンド・メッセージのエラー検査
３．メッセージ追跡およびスケジューリング機能
４．アウトバウンドＳＭＳメッセージ・テンプレート・メッセージの生成
５．インバウンド・メッセージのエラー検査
６．インバウンド・テンプレートのＸＭＬ  ＳＭＳメッセージへの翻訳
７．アウトバウンド型の対応するインバウンドＳＭＳメッセージへの対応付け
【００６４】
アウトバウンドＳＭＳメッセージは、いまやここで導入したテンプレートに従ってエンコードされているため、ラン・タイムで構文解析することが可能である。この構文解析の段階の間に、メッセージ型に関する情報、伝送媒体、送出の優先度などを構文解析して取り出す。
【００６５】
エラー検査は、このアウトバウンド・メッセージのラン・タイム構文解析の付加的な利点である。いまやアウトバウンドＳＭＳメッセージは厳密に型でエンコードされているので、不足するパラメータなど様々なエラーをこの段階で検出し取り扱うことができる。これにより、最終的なアウトバウンド・メッセージが正しいことが保証される。
【００６６】
以下は、本発明の一実施形態に従ってＳＭＳユニバーサル・エンコーディング・テンプレートを実装するのに使用できるサンプル・ソース・コード・リストである。
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:cep=
"http://www.ibm.com/WebsphereCommerceEnabledPortal/SMSCommerceDefinitionSchema">
<annotation>
<documentationxml:lang="en">
Schema for Websphere Commerce EnabledPortal SMS Commerce Type Definition
Copyright 2002 IBM Corporation
<documentation>
</annotation>
<!-Dynamic Context Group Instance-->
<xsd:elementname="ScheduledGenericSMSMessage"
type="ScheduledGenericSMSMessageType",
minOccurs="0"/>
<xsd:elementname="ResponseRequiredGenericSMSMessage"
type=" ResponseRequiredGenericSMSMessageType",
minOccurs="0"/>
<xsd:element name="HighPriorityGenericSMSMessage"
type="HighPriorityGenericSMSMessageType",
minOccurs="0"/>
<xsd:elementname="GenericSMSMessage"
type="GenericSMSMessageType",
minOccurs="0"/>
<xsd:elementname="BroadcastSMSMessage"
type="BroadcastSMSMessageType",
minOccurs="0"/>
<xsd:complexTypename="ScheduledGenericSMSMessageType">
<xsd:sequence>
<xsd:elementname="GenericSMSMessage"
type="GenericSMSMessageType"/>
<xsd:attributename="DateToBeSentOn" type="xs:date"/>
<xsd:attributename="TimeToBeSentOn" type="xs:time"/>
</xsd:sequence>
</xsd:complexType>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<xsd:complexTypename="ResponseRequiredGenericSMSMessageType">
<xsd:sequence>
<xsd:elementname="GenericSMSMessage"
type="GenericSMSMessageType"/>
<xsd:attributename="InboundTemplateId" type="xs:string"/>
</xsd:sequence>
</xsd:complexType>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<xsd:complexTypename="HighPriorityGenericSMSMessageType">
<xsd:sequence>
<xsd:elementname="GenericSMSMessage" type="GenericSMSMessageType"/>
<xsd:attributename="DeliveryPriority"
type="DeliveryPriorityType"fixed="HIGH"/>
</xsd:sequence>
</xsd:complexType>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<xsd:complexTypename="GenericSMSMessageType">
<xsd:sequence>
<xsd:elementname="short_message_text" type="xsd:string"
maxLength="160"/>
<xsd:attributename="ReceiverProfile" type="ReceiverProfileType"
minOccurs="1"maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<xsd:complexTypename="BroadcastSMSMessageType">
<xsd:sequence>
<xsd:elementname="short_message_text" type="xsd:string"
maxLength="160"/>
<xsd:attributename="ReceiverProfile" type="ReceiverProfileType"
minOccurs="1"maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<xsd:simpleTypename="DeliverPriorityType">
<xsd:restrictionbase="xsd:string">
<xsd:enumerationvalue="HIGH"/>
<xsd:enumerationvalue="MEDIUM"/>
<xsd:enumerationvalue="LOW"/>
</xsd:restriction>
</xsd:simpleType>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<xsd:complexTypename="ReceiverTransmissionProfileType">
<xsd:sequence>
<xsd:elementname="userid" type="xsd:string"/>
<xsd:elementname="cellphonenumber" type="xsd:string"/ >
<xsd:element name="deliverychannel"type="DeliveryChannelType"/>
</xsd:sequence>
</xsd:complexType>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<xsd:simpleTypename="DeliveryChannelType">
<xsd:restrictionbase="xsd:string">
<xsd:enumerationvalue="SMTP"/>
<xsd:enumerationvalue="GSM"/>
<xsd:enumerationvalue="SNPP"/>
<xsd:enumerationvalue="Mobitex"/>
<xsd:enumerationvalue="DataTAC"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
【００６７】
以下のソース・コード・リストは型付き（分類済み）ＳＭＳメッセージ・インスタンスの例を提供する。
XSD Schema Definition of Commerce PaymentException SMS Message
<xsd:complexTypename="PaymentExceptionSMSMessage">
<xsd:sequence>
<xsd:elementname="ResponseRequiredSMSMessage"
type="ResponseRequiredSMSMessageType"/>
</xsd:sequence>
</xsd:complexType >
Message Instance of a Payment ExceptionSMS Message
<PaymentExceptionSMSMessage>
<ResponseRequiredSMSMessage>
<HighPriorityGenericSMSMessage>
<GenericSMSMessage>
<short_message_text>
Your cheque bounced!
</short_message_text>
<ReceiverProfile>
<userid>steve</userid>
<cellphonenumber>
4161234567@cellphone.com
</cellphonenumber>
<deliverychannel>SMTP</deliverychannel>
</ReceiverProfile>
</GenericSMSMessage>
<DeliveryPriority>HIGH</DeliveryPriority>
</HighPriorityGenericSMSMessage>
<ConfirmationOfDelivery>CONFIRMED</ConfirmationOfDelivery>
</ResponseRequiredSMSMessage>
</PaymentExceptionSMSMessage>
XSD Schema Definition of Campaign StartedBroadcast SMS Message
<xsd:complexTypename="CampaignStartedSMSMessage">
<xsd:sequence>
<xsd:elementname="BroadcastSMSMessage"
type="BroadcastSMSMessageType"/>
</xsd:sequence>
</xsd:complexType >
Message Instance of a Campaign Started SMSMessage
<CampaignStartedSMSMessage>
<BroadcastSMSMessage>
<short_message_text>
New campaign has been started,visit our website
</short_message_text>
<ReceiverProfile>
<userid>steve</userid>
<cellphonenumber>
4161234567@cellphone.com
</cellphonenumber>
<deliverychannel>SMTP</deliverychannel>
</ReceiverProfile>
...
...
<ReceiverProfile>
<userid>joe</userid>
<cellphonenumber>
4161234568@cellphone.com
</cellphonenumber>
<deliverychannel>SMTP</deliverychannel>
</ReceiverProfile>
</BroadcastSMSMessage>
</CampaignStartedSMSMessage>
【００６８】
ＳＭＳエンコーディング・エンジン１１１は、選択したＳＭＳメッセージ型に基づいて、ＳＭＳメッセージ・インスタンスを自動的に生成することができる。ＳＭＳメッセージ・ランタイム・プロセッサ１１０は、所与のあらかじめ定義された型のセマンティクスを取り扱うように適合されている。ラン・タイム時に、送ったＳＭＳメッセージがResponseRequiredSMSMessageTypeである場合には、ＳＭＳメッセージ・ランタイム・プロセッサ１１０は、あらかじめ設定された待ち時間のあいだユーザ確認を待つ。あらかじめ設定された待ち時間後に確認を受信しなかった場合、ランタイム・プロセッサ１１０は対応するアプリケーション・コンポーネント１０８にエラーを送って、そのアプリケーション・コンポーネントが表すビジネス・プロセスの規定するところに従って、アクションを実行することができる。たとえば、アプリケーション・コンポーネント１０８は、トランザクションの再送またはロールバックすること、およびこのトランザクションを完了に失敗したものとしてマークすることを提供することができる（図１のＤｘでランタイム・プロセッサ１１０は取り扱いのためアプリケーション・コンポーネントにラン・タイム・エラーを報告する）。
【００６９】
ユーザが既存の型から拡張してどのように新しいＳＭＳの型を作成するか
ＳＭＳメッセージ作成ウイザードを使用して新しいＳＭＳの型を作成するプロセスを示す図３および新しいＳＭＳの型を作成するためのＳＭＳメッセージ作成ＧＵＩを示す図１を参照すると、本発明の一実施形態を用いてどのように新しいＳＭＳの型を作成できるかが容易に了解されよう。
【００７０】
プロセスを開始するために（３００）、ビジネス・ユーザはメッセージ作成ウイザード１１２（図１、２を参照されたい）上に提供されているボタンをクリックして本実施形態のシステムに新しいメッセージ型の作成を指示する（３０１）。次いで、メッセージ作成ウイザードは、ＳＭＳユニバーサル・エンコーディング・テンプレート１１３（図１、２）を読み込んで、ユーザがステップ３０２で新しい型を作成するために、選択可能な親のＳＭＳの型４０５を提示する。ステップ３０３で、ユーザは、新しいメッセージ型名を入力し（４０４を参照）、提供されている説明、４０６、４０７、４０８、４０９、４１０、４１１、４１４、４１５、４１６の示す新しい属性すべて、および基本（親）の型４０５を指定して、新しいＳＭＳの型を生成する。「Add」（追加）ボタンおよび「Delete」（削除）ボタン、それぞれ４１２および４１３によって、返信セクションでの項目の挿入および削除ができるようになっており、これに対して、ボタン４０２および４０３は、新しいメッセージ型の保存またはキャンセルに使用されることが理解されよう。
【００７１】
新しいメッセージ型に新しい応答テンプレートが要求された場合（３０４）、ビジネス・ユーザは応答テンプレート・マネージャを呼び出して、要求されたインバウンド・テンプレートを作成し（３０５）、インバウンド・テンプレート・データベース１１５が更新される（３０６）。新しい応答テンプレートが必要ない場合には、新しいメッセージ型がＳＭＳユニバーサル・エンコーディング・テンプレート１１３に保存され（３０７）、図３に示すプロセスの終わり３０８に達する。
【００７２】
２．エンコーディングのエンド・ツー・エンドのフロー
ＳＭＳメッセージのエンコーディングのフローを示す図５を参照すると、以下が了解されよう。すなわち、
Ａ：ビジネス・ユーザが、新規メッセージ型作成部を呼び出して、新しいメッセージ型を作成する。
Ｂ：ビジネス・ユーザが、インバウンド・テンプレート・マネージャを呼び出して、新しいメッセージ型のための新しいインバウンド・テンプレートを（インバウンド・テンプレート・マネージャによって）作成する。
Ｃ：インバウンド・テンプレート・マネージャが、インバウンド・テンプレートＤＢからあらかじめ定義されたコマンドのリストを取り出す。コマンド・リストは、アプリケーション・コンポーネントの所有者（owner）が定義する。
Ｄ：インバウンド・テンプレート・マネージャが、ビジネス・ユーザがＧＵＩから選択した応答アクションおよびコマンドとともに、インバウンド・テンプレートＤＢに新しい行を挿入する。
Ｅ：インバウンド・テンプレート・マネージャが、（インバウンド・テンプレートＤＢの生成した）新たに作成したインバウンド・テンプレートＩＤを新規メッセージ型作成部に返す。
Ｆ：次いで、新規メッセージ型作成部が、（インバウンド・テンプレートＩＤとともに埋め込まれた）新たに作成したメッセージ型をＳＭＳユニバーサル・エンコーディング・テンプレート（部分番号５）へと保存する。
【００７３】
２．１  アウトバウンド・メッセージ専用メッセージのエンコード
ＳＭＳ作成ウイザードにより、ビジネス・ユーザは、ｅ−コマース・システム内のどの登録ユーザにもメッセージを送ることができるようになる。ビジネス・ユーザは、メッセージの型を選択し、メッセージ・テキストを入力し、「Submit」（提出）ボタンをクリックすればよいだけである。
【００７４】
マイクロ・フロー（Micro Flow）：データ収集インターフェース、ＳＭＳ入力データ・コレクションおよびメッセージ・エンコーディング・エンジン
エンコーディング・エンジンによるメッセージ処理を、次に論じるように、図６の英数字でラベル付けした矢印で示している。
Ａ：共通メッセージ・サブシステム１０７またはＳＭＳメッセージＧＵＩウイザード（部分番号４）１１２がデータ収集インターフェース１１７のＡＰＩ（部分番号１）５１０〜５１６を呼び出して、メッセージ発信者から収集したデータを渡す。
Ｂ：データ収集インターフェースのＡＰＩ５１０〜５１６が、データをデータ収集オブジェクト５１８に渡す。たとえば、メッセージ・テキストをパラメータとしてsetTextMessage ＡＰＩ５１４を呼び出すと、ＡＰＩ５１４はそのテキストをデータ収集オブジェクト５１８に保存する。
Ｃ：sendMessage ＡＰＩ５１６が、型付きＳＭＳメッセージ・エンコーダ７０１を呼び出す。これは、メッセージ型名をデータ収集オブジェクト５１８から取り出す。メッセージ型名は、messageInstanceCreationＡＰＩ５１０によって捉えられる。このステップでは、また、型付きＳＭＳメッセージ・エンコーダ７０１は、データ収集オブジェクト５１８から、送信時間、送信の優先度、ResponseTemplateId,テキスト・メッセージ、受信者（receiver）情報などの他の情報の収集も行う。
Ｄ：型付きＳＭＳメッセージ・エンコーダ７０１は、このメッセージ型に対するＳＭＳユニバーサル・エンコーディング・テンプレート１１３をメッセージ型名を用いて取り出す。
Ｅ：型付きＳＭＳメッセージ・エンコーダ７０１は、テンポラリ型付きＳＭＳメッセージ・インスタンス７０２の作成を、ＳＭＳユニバーサル・エンコーディング・テンプレート１１３を（ＸＭＬのための内部構造である）ドキュメント・オブジェクト・モデルで表現されたテンポラリ型付きＳＭＳメッセージ・インスタンス７０２へと変換し、Ｃのデータ収集オブジェクト５１８から収集した情報で満たすことによって行う。
Ｆ：次いで、テンポラリ型付きＳＭＳメッセージ・インスタンス７０２は、妥当性検査を実行するため、ＳＭＳメッセージ妥当性検査部７０３に渡す。妥当性検査プロセスは、義務的データ、データ・セマンティクス、データ・シンタクス、データ・レンジの検査を含む。
Ｇ：妥当性検査が成功した場合、ＳＭＳメッセージ妥当性検査部はテンポラリ型付きＳＭＳメッセージ・インスタンス７０２をコピーして最終的な型付きＳＭＳメッセージ・インスタンス（番号６）１１４とする。
【００７５】
図７のステップ８０１ないし８０８で、上記のプロセスを流れ図で示している。
【００７６】
２．２  応答の要求されるメッセージのエンコーディング
応答を要求するＳＭＳメッセージについては、受信者へのオリジナルのアウトバウンドＳＭＳメッセージにインバウンド・テンプレートを含めるべきである。インバウンド・テンプレートにより、受信者に対するフォーム・ベースの入力機構が提供される。すなわち、これは、ＳＭＳメッセージの受信者の期待される応答をエンコードするように適合されている。インバウンド・テンプレートにより、受信者にアウトバウンドＳＭＳメッセージを発信したアプリケーション・コンポーネント１０８に返される応答を定式通り作成する（formulate）受信者ユーザの負担が取り除かれる。応答テンプレートは、ユーザの要求される応答のフォーマットを示すことによって、ユーザの応答を制約するのに役立つ。結果的に、ユーザの応答は、返信されたときにＷｅｂアプリケーション・サーバが自動的に処理できる形をとることになる。
【００７７】
インバウンド・テンプレート：インバウンド・テンプレートの構造を次に示す。
<Short Message Text>
--
<Encrypted String>
--
<responseaction 1>
<responseaction 2>
<response action n>
PIN:<mobile user personalidentification>
【００７８】
上に示したインバウンド・テンプレートの構造により、複数の応答アクションがサポートされている。トランザクションの型に応じて、おそらくモバイル・ユーザである受信者は、応答アクションの１つを選ぶことになる。
【００７９】
図８に、受信者ユーザに対する要求される応答の表示を伴うアウトバウンドＳＭＳメッセージの様子を、ユーザのデジタル携帯電話の画面９０１上に現れる形で示している。
【００８０】
これを達成するＳＭＳメッセージの文字列は次のものに似ていたはずである。Yourcheque bounced!-kis2-CONFIRMED:_ PIN:_
（小切手が不渡りです！-kis2-確認済み:_個人識別番号:_）
【００８１】
２．２．１  ＳＭＳ応答メッセージ・エンコーディング・テンプレート要素
図９から見てわかるように、インバウンド・テンプレートに対するＳＭＳ応答メッセージ・エンコーディング・テンプレート要素は、次のものを含む。すなわち、
・短いメッセージ・テキスト、９０２
・暗号化文字列、９０３
・＜応答アクション、９０４＞：＜応答データ、９０６＞
・ＰＩＮ、９０５
【００８２】
図９に、送信前にユーザ応答を入力した状態のＳＭＳインバウンド・メッセージを示している。
【００８３】
２．２．１．１  短いメッセージ・テキスト９０２
これは、メッセージ発信者が受信者（receiver）に送ることを意図したメッセージである。
【００８４】
２．２．１．２  暗号化文字列９０３
暗号化文字列は、‘−’の対で区切られた４キャラクタのハッシュされた（hashed）文字列である。
【００８５】
暗号化文字列は、次の情報の混合（amalgamation）に基づいて作成する。すなわち、
−  ＷｅｂアプリケーションＩＤ（Ｗｅｂアプリケーション管理者があらかじめ定義する。たとえば、店舗ＩＤ）
−  ユーザＩＤ（この店舗の受信者（receiver）のログインＩＤ）
−  データベース・エントリごとの（コマンドおよび期待されるパラメータを含む）インバウンド・テンプレートＩＤ。これは、インバウンド・テンプレートＤＢ（部品番号８）から得られる。
−  アクションＩＤ（このメッセージで許される応答アクションを表すＩＤ）
−  ハッシュ・キー−ユーザは、このキーをいつでも変更して期限切れにすることができる。これは機密性のある（restricted）ディレクトリにあるファイルに保存することができる。
【００８６】
上の情報を入力としてこの暗号化文字列を生成するのは、ランタイム・プロセッサ１１０の役割である。また、ＳＭＳメッセージを無線メッセージ・ゲートウェイ１０３へと転送する前にインバウンド・テンプレートを生成するのも、ランタイム・プロセッサの役割である。
【００８７】
暗号化文字列を使用することの利点は次のものである。
−  暗号化文字列は、１６０キャラクタの制限からのスペースを節約するために４バイトに限ることができる。
−  暗号化文字列は理解不能である。
−  ハッシュ・キーは、ビジネス・ユーザがいつでも変更して任意にタイム・アウトを課することができる。
−  ランタイム・プロセッサ１１０は、望まない着信メッセージをフィルタして取り除くことができる。暗号化文字列が無効またはない場合は、そのメッセージが望まないものであることを示す。
−  ユーザは、インバウンド・テンプレートをそのモバイル装置に保存して、指定するＷｅｂアプリケーションとのトランザクションをいつでも自らの意思で開始することができる。この利点は、セクション２．３で詳細に論じることとする。
【００８８】
２．２．１．３  ＜応答アクション＞：＜応答データ＞
応答アクション９０４は、正当な（allowable）応答アクションおよび対応するパラメータを識別するためのキーワードである。この例では、正当な応答９０４はCONFIRMED（確認済み）である。この例、すなわち図１０では、ユーザはＹという応答９０６を入力している。異なるトランザクションに対して２つ以上の正当な応答がありうる。この応答では、３つの下位要素がある。すなわち、
１．応答アクション−アクションを表すキーワード。たとえば、CONFIRMED
２．コマンド−ランタイム・プロセッサが呼び出すＷｅｂアプリケーション・プログラムまたはコマンド
【００８９】
こうした応答アクションおよびコマンドは、一意のインバウンド・テンプレートＩＤでインデクスの付けられたインバウンド・テンプレートＤＢ（部分番号８）に保存することができる。ビジネス・ユーザはＳＭＳメッセージ作成ウイザード（部品番号４）を使用してこうした応答アクションを管理することができる。セクション２．２．３「ＳＭＳメッセージ作成ウイザードを用いてインバウンド・テンプレートをどのように管理するか」を参照されたい。
【００９０】
ランタイム・プロセッサは、応答を行うＳＭＳメッセージを受け取ると、コマンドを＜応答データ  ９０６＞とともに呼び出すことになる。
【００９１】
２．２．１．４  ＰＩＮ
ＰＩＮ要素９０５は、ユーザが、ユーザ登録の際に指定したＰＩＮ番号９０４を入力するためのものである（この例ではユーザは１２３４を入力している）。ＰＩＮおよびユーザＩＤ（暗号化文字列に暗号化されている）によって、ランタイム・プロセッサ１１０はインバウンド・メッセージの原本性（originality）を認証することができる。
【００９２】
２．２．２  ユーザが応答に何を入力したかを示すＳＭＳ応答
図９に、デジタル携帯電話の画面１００１をユーザ応答とともに示している。
【００９３】
モバイル携帯電話のユーザが、ＳＭＳメッセージに応答したときには、Ｗｅｂアプリケーション用の指定された電話番号への「forward message」（メッセージを転送する）を選択しさえすればよかったはずである。すなわち、応答アクションの１つに対する応答データを入力し、ＰＩＮ番号を入力し、「send」（送信）ボタンを押すことである。
【００９４】
この例では、モバイル携帯電話のユーザはCONFIRMED:９０４の隣りにＹ９０６を入力して、自分がそのメッセージの受領を認めることを示している。
【００９５】
Ｗｅｂアプリケーションが受信したはずのＳＭＳメッセージは、次のものに似ていたはずである。Your cheque bounced!-kis2-CONFIRMED:Y PIN:1234
（小切手が不渡りです！-kis2-確認済み:Y個人識別番号:1234）
【００９６】
インバウンドＳＭＳメッセージの処理については、セクション３．２「応答が要求されるメッセージおよびインバウンド・メッセージのエンド・ツー・エンド・フロー」を参照されたい。
【００９７】
２．２．３  ＳＭＳメッセージ作成ウイザードを用いてインバウンド・テンプレートをどのように管理するか
インバウンド・テンプレート・マネージャ５０２（図５を参照）、すなわちＳＭＳメッセージ作成ウイザード（部分番号４）（図４を参照）の下位コンポーネントは、インバウンド・テンプレートを管理する役割を担う。これは、応答アクションとＷｅｂアプリケーションのコマンドの間の対応付けの作成および削除を含んでいる。
【００９８】
２．２．３．１  ＧＵＩ
図１０に、Ｗｅｂアプリケーション・サーバがモバイル・ユーザに送るようなＳＭＳメッセージを作成するのに使用することもできる、ＧＵＩ１１０１を示している。このインスタンスでは、図１０は図８のメッセージを出力するのに使用できたはずの支払い例外メッセージ（payment exception message）用のＧＵＩを示している。
【００９９】
ビジネス・ユーザが、このＧＵＩ１１０１から導出された新しいＳＭＳメッセージ型を作成したい場合は、「New」（新規）ボタン１１０２を押すと、図４に示す「Create a new SMS Message Type」（新しいＳＭＳメッセージ型の作成）パネル４００が呼び出される。すると、このパネルを使用して新しいメッセージ型を作成することができる。
【０１００】
「Add」（追加）ボタン４１２をクリックすると、図１１に示す「Add SMS(Reply) Inbound Template」（ＳＭＳ（返信）インバウンド・テンプレートの追加）パネルが呼び出される。
【０１０１】
２．２．３．２  インバウンド・テンプレート・マネージャの構造図（structurediagram）
図１２に、インバウンド・テンプレート・マネージャ２０２の構造を示している。
【０１０２】
以下はインバウンド・テンプレート・マネージャに関するフローの注記である。
Ａ：ビジネス・ユーザ９００が、新規メッセージ型作成部２０１を呼び出して、新しいメッセージ型を作成する。
Ｂ：ビジネス・ユーザ９００が、インバウンド・テンプレート・マネージャ２００を呼び出して、新しいメッセージ型のための新しいインバウンド・テンプレートを作成する。
Ｃ：インバウンド・テンプレート・マネージャが、インバウンド・テンプレートＤＢ１１５からあらかじめ定義されたコマンドのリストを取り出す。コマンド・リストは、アプリケーション・コンポーネント１０８（図１）が定義する。
Ｄ：インバウンド・テンプレート・マネージャ２０２が、ＧＵＩから情報を収集し、インバウンド・テンプレートＤＢ１１５を更新する。
Ｅ：インバウンド・テンプレート・マネージャ２０２が、（インバウンド・テンプレートＤＢ１１５の生成した）新たに作成したインバウンド・テンプレートＩＤを新規メッセージ型作成部２０１に返す。
Ｆ：次いで、新規メッセージ型作成部２０１が、（インバウンド・テンプレートＩＤとともに埋め込まれた）新たに作成したメッセージ型をＳＭＳユニバーサル・エンコーディング・テンプレート（部分番号５）１１３へと保存する。
【０１０３】
２．２．３．３  インバウンド・テンプレートの管理の流れ図
図１３に、どのようにＳＭＳメッセージ作成ウイザードを使用して上で述べた応答アクションを管理するかのステップ１５０ないし１５８を示す流れ図が示されている。
【０１０４】
２．３  インバウンド・メッセージをユーザの利用向けにエンコードする
インバウンド・テンプレートのもう１つの有用な適用例は、モバイル・ユーザが要求をＷｅｂアプリケーションに提出できるようにすることである。たとえば、ユーザはＷｅｂアプリケーションに口座残高に関する要求を送ることができる。モバイル装置中の口座残高要求に対する保存されたインバウンド・テンプレートを使用して、ユーザはこのインバウンド・テンプレートをインバウンドＳＭＳメッセージとして送ることができる。この要求に応答して、Ｗｅｂアプリケーションは、着信メッセージが妥当性検査および認証をパスしたと仮定して、口座残高をアウトバウンドＳＭＳメッセージとして送る。
【０１０５】
２．３．１  この機能を実装する諸ステップ
ステップ１：ビジネス・ユーザが、インバウンド・テンプレートのリストを定義する。これは、新しいメッセージ型を作成する際の類似の手順を用いて行うことができる。「InboundRequestGenericMsg」と呼ばれる新しいメッセージ型を最初に定義しなければならない。すると、ビジネス・ユーザは、別のインバウンド要求メッセージ型を、インバウンド・テンプレートを付加した状態で導出することができる。
ステップ２：「顧客サービス」と呼ばれるアプリケーション・コンポーネントが、その店舗Ｗｅｂサイト内で定義済みインバウンド・テンプレートのリストを公開する。
ステップ３：ユーザが店舗Ｗｅｂサイトにログオンし、ダウンロードを希望するインバウンド・テンプレートを選択する。
ステップ４：顧客サービス・アプリケーション・コンポーネントが、選択されたインバウンド・テンプレートをモバイル装置に送る。送信は、データ収集インターフェースのＡＰＩ（部分番号１）を呼び出す共通メッセージ・サブシステムによって完了させることができる。
【０１０６】
２．３．１  構造図
図１４に、ビジネス・ユーザがＳＭＳメッセージを送るプロセスを示す、本発明の好ましい一実施形態によるＳＭＳシステムの構造図を示している。
【０１０７】
以下はフローの注記である。
Ａ：ビジネス・ユーザ９００が、新しいメッセージ型および対応するインバウンド・テンプレートを定義する。これは、ＳＭＳメッセージ作成ウイザード１１２（図１）によって行うことができる。
Ｂ：ＳＭＳメッセージ作成ウイザード１１２が、これらの新しいメッセージ型およびインバウンド・テンプレートを、ＳＭＳユニバーサル・エンコーディング・テンプレート（部分番号５）１１３およびインバウンド・テンプレートＤＢ（部分番号８）１１５にそれぞれ保存する。
Ｃ：モバイル・ユーザ９０１が、このシステム用のＷｅｂサイトにログオンし、インバウンド・テンプレートのリストを要求する。
Ｄ：顧客サービス・アプリケーション・コンポーネント１６１が、インバウンド・テンプレートＩＤをＳＭＳユニバーサル・エンコーディング・テンプレート１１３から得る。このＩＤを用いて、顧客サービス・アプリケーション・コンポーネント１６１は、このＩＤを使用するインバウンド・テンプレートＤＢ１１５から利用可能なインバウンド・テンプレートを取り出す。
Ｅ：顧客サービス・アプリケーション・コンポーネント１６１が、インバウンド・テンプレートのリストをモバイル・ユーザ９０１に表示する。
Ｆ：モバイル・ユーザ９０１が、所望のインバウンド・テンプレートを選択し、それを自分のモバイル装置へと送ることを要求する。
Ｇ：顧客サービス・アプリケーション・コンポーネント１６１が、選択したインバウンド・テンプレートを総称的なＳＭＳメッセージとして送るために、共通メッセージ・サブシステム１０７に要求を送る。
Ｈ：共通メッセージ・サブシステム１０７が、インバウンド・テンプレートを総称的なＳＭＳメッセージとして送信するために、データ収集インターフェースのＡＰＩ（部分番号１）１１７を呼び出す。
Ｉ：ＳＭＳメッセージ・エンコーディング・エンジン（部分番号２）１１１が、インバウンド・テンプレートを含むＳＭＳメッセージをエンコードし、それらをランタイム・プロセッサ（部分番号３）１１０へと送る。
Ｊ：ランタイム・プロセッサ１１０が、暗号化文字列をＳＭＳメッセージに挿入する。テンプレートは入力要求のために使われるので、この暗号化文字列は、好ましくは、有効期限を持たせるべきではない。ＳＭＳメッセージは無線メッセージ・ゲートウェイ１６２へと送られる。
Ｋ：無線メッセージ・ゲートウェイ１６２が、これらのメッセージをモバイル・ユーザ９０１に送付する。
Ｌ：モバイル・ユーザ９０１が、これらのインバウンド・テンプレートを自分のモバイル装置の保存領域（storage）に保存する。モバイル・ユーザ９０１は、いまやこれらのインバウンド・テンプレートを使用して、アプリケーション・コンポーネント１０８に要求または要求群を提出することができる。
Ｍ：無線ゲートウェイ１６２が、インバウンドＳＭＳメッセージをモバイル・ユーザからランタイム・プロセッサ１１０へと転送する。
Ｎ：ランタイム・プロセッサ１１０が、インバウンドＳＭＳメッセージ内の暗号化文字列を検査して、これがインバウンド要求であるかどうかを判断する。メッセージが認証された場合、ランタイム・プロセッサ１１０がＳＭＳ可能コマース・システムの関連するアプリケーション・コンポーネント１０８が所有者である対応するコマンドを呼び出すことになる。
【０１０８】
２．３．２  流れ図
図１５に、ビジネス・ユーザが本発明の好ましい一実施形態に従って選択したインバウンド・テンプレートを得る、図１３に示したものと類似の流れ図を示している。
【０１０９】
３．ラン・タイムのエンド・ツー・エンド・フロー
このセクションでは、本発明の一実施形態のラン・タイム処理を略述し、アウトバウンド・メッセージの生成およびインバウンド応答メッセージの処理を扱う。
【０１１０】
３．１  アウトバウンド・メッセージ・エンド・ツー・エンド・メッセージ処理フロー
図５は、本発明のある実施形態のＳＭＳ  ｅ−コマース・システムのアウトバウンド・メッセージ取り扱いフローを示す、アウトバウンドの流れ図である。
【０１１１】
図１７に、本発明の環境のアウトバウンドの流れ図を示す。図１７を参照すると、次のことがわかる。すなわち、
・メッセージ・エンコーディング・エンジン１１１の生成する型付きＳＭＳメッセージ・インスタンス１１４を、スケジューリングされたメッセージかどうかを検査する。
・それがスケジューリングされたメッセージであった場合、そのメッセージをＳＭＳメッセージ追跡ＤＢ１９５に保存する。スケジューラ１８２が、定期的にＳＭＳメッセージ追跡ＤＢ１９５を読み込んで、送る予定になっているメッセージを取り出す。
・メッセージが送る予定になっている場合、そのメッセージの型エラー（typeerror）に関する検査を、ユニバーサル・エンコーディング・テンプレート１１３内に保存されている型と比較することによって行う。
・型エラーがある場合、エラーを生成して返す。
・型エラーがない場合、そのメッセージの構文解析を、ユニバーサル・エンコーティング・テンプレート１１３の入力とともにＸＭＬパーサ１９１８を用いて行う。
・ＸＭＬパーサ１９１８が、ＤＯＭツリー（DOM tree）フォーマット１９１２になっている型付きＳＭＳメッセージ・インスタンスを構文解析する。
・そのメッセージが応答を要求しているかどうかを検査する。
・応答が要求されていない場合、そのメッセージを無線ゲートウェイ１０３を用いて発送し、そして停止する。
・応答が要求されている場合、構文解析したメッセージからメッセージ・テンプレートＩＤを抽出する。
・インバウンド・テンプレート１９１６を、インバウンド・テンプレートＤＢ１１５からメッセージ・テンプレートを用いて見つける。
・型付きＳＭＳメッセージ・インスタンス１１４およびインバウンド・テンプレート１９１６を用いて、最終的なＳＭＳメッセージを生成する。
・セッション・オブジェクト１９２７を作成する。
・そのセッション・オブジェクト、ＷｅｂＡｐｐ  ＩＤ１９２８、ユーザＩＤ１９２９、テンプレートＩＤ１９３０および暗号化キー１９３１を用いて、暗号化文字列１９２４を生成する。
・暗号化文字列１９２４を最終的なＳＭＳメッセージに挿入する。
・最終的なＳＭＳメッセージを無線ゲートウェイ１０３を用いて発送し、そして停止する。
【０１１２】
３．２  ResponseRequiredMessageおよびインバウンド・メッセージ・エンド・ツー・エンド・メッセージの処理フロー
図１８に、インバウンドの流れ図を示す。これから、次のことがわかる。すなわち、
・無線ゲートウェイ１０３がインバウンドＳＭＳメッセージ２００３を受け取る。
・ランタイム・プロセッサ１１０がインバウンドＳＭＳメッセージ２００３から４キャラクタの暗号化文字列２００５を抽出する。
・暗号化キー１９３１によって、暗号化文字列２００５を復号する。
・復号が成功しない場合、停止する。
・復号が成功した場合、ＷｅｂＡｐｐ  ＩＤを暗号化文字列２００５から抽出する。
・ＷｅｂＡｐｐ  ＩＤが現在の（current）ＷｅｂＡｐｐ  ＩＤと一致しなかった場合、停止する。
・ＷｅｂＡｐｐ  ＩＤが現在の（current）ＷｅｂＡｐｐ  ＩＤと一致する場合、テンプレートＩＤを暗号化文字列２００５から抽出する。
・上で抽出したテンプレートＩＤを用いて、インバウンド・テンプレート２０１４をインバウンド・テンプレートＤＢ１１５から得る。
・パラメータ名、コマンドおよび値２０１７をインバウンドＳＭＳメッセージ２００３から抽出する。
・ユーザＩＤを暗号化文字列２００５から抽出する。
・コマース・サーバ（コマンド・コンテキスト・オブジェクト２０２０）に対するメッセージの作成を、上で抽出したコマンド名、パラメータおよびユーザＩＤを用いて行う。
・前記メッセージをコマース・サーバ１０８に発送する。
・すべてが完了する。
【０１１３】
図１６に、確認応答ラン・タイム処理フローの説明に十分な詳細を示す、本発明の一実施形態のランタイム・プロセッサ１１０の詳細な例を示している。以下は、ランタイム・プロセッサ１１０の諸要素およびそのやり取りの説明である。
【０１１４】
型付きメッセージ・インスタンス：型付きメッセージ・インスタンス１１４は、エンコーディング・エンジン（またはスケジューリングされたメッセージの場合はスケジューラ）から、ラン・タイム時までに受け取った実際のアウトバウンドＳＭＳメッセージである。現在の実装方式では、このメッセージは、ユニバーサル・エンコーディング・テンプレート・スキーマにより、ＸＭＬでエンコードされている。
【０１１５】
型付きメッセージ構文解析サブシステム：型付きメッセージ構文解析サブシステム１８１は、型付きＸＭＬメッセージ用パーサからなる。その仕事は、着信メッセージがスキーマに従って正しくエンコードされているかどうかを検査すること、そしてまた（現在の実装では）このメッセージを構文解析してＤＯＭツリーにすることである。
【０１１６】
このサブシステムの出力は、アウトバウンドＳＭＳメッセージの内容全体を含む、コンピュータ可読のメモリ・オブジェクト・フォーマットの構文解析されたオブジェクトである。
【０１１７】
メッセージ追跡サブシステム：メッセージ追跡サブシステム１８３は、メッセージ送信時間、メッセージ受信時間などに関する統計情報でＳＭＳ追跡ＤＢを更新する。
【０１１８】
スケジューラ：スケジューラ・サブシステム１８２は、ＳＭＳメッセージの時間指定（timed）中継の役割を担う。ＳＭＳメッセージをあるスケジューリングされた時間に送る必要がある場合は、このサブシステムがメッセージ追跡ＤＢにそのメッセージをキャッシュする役割を担う。
【０１１９】
また、このサブシステムは、ビジネス・マネージャが決めた間隔でメッセージ追跡ＤＢをポーリングし、発送の準備のできたメッセージを選び、送付のための型付きメッセージ構文解析サブシステムに転送する役割も担っている。
【０１２０】
アプリケーション・キー生成部サブシステム：アプリケーション・キー生成部サブシステム１８４は、ユーザ応答を要求するＳＭＳメッセージと一緒に送られる暗号化文字列を生成する役割を担う。このサブシステムでは、このセッション文字列の暗号化に、システム共通（system-wide）で時間に依存する暗号化／復号キー（encoding/decoding key）が使用されている。
【０１２１】
暗号化文字列自体は次のものからなる。
１．ＷｅｂＡｐｐ  ＩＤ
２．ユーザＩＤ
３．インバウンド・テンプレートＩＤ
４．セッション・オブジェクトＩＤ
【０１２２】
この暗号化文字列は時間に依存する暗号化／復号キーに基づいているため、以前達成することのできなかった、ＳＭＳでのセッションの効果を達成することが可能である。
【０１２３】
いまやＳＭＳに導入されたセッションの概念を用いて、ＳＭＳベースのセッション・データ・ストレージに使用できるセッション・オブジェクトをいまでは作成することができる。
【０１２４】
暗号化文字列を時間に依存する復号キーによって復号した後で、各要素（ＷｅｂＡｐｐ  ＩＤ、ユーザＩＤ、インバウンド・テンプレートＩＤ、およびセッションＩＤ）を、第２段階でそれ自体の復号キー（WebAppIDKey, UseridKey, inboundTemplateKey, sessionIDKey）で復号することができる。
【０１２５】
したがって、最終的な暗号化は、システム共通の暗号化キーとＷｅｂＡｐｐ  ＩＤのどちらもが正しい場合にだけ首尾よく復号できる、２段階の暗号化方式である。これにより、アウトバウンド・セッション文字列に対するさらなるセキュリティがもたらされる。
【０１２６】
アウトバウンド・メッセージ生成部：アウトバウンド・メッセージ生成部サブシステム１８５は、型付きメッセージ構文解析サブシステムの生成した構文解析済みアウトバウンドＳＭＳメッセージおよびアプリケーション・キー生成サブシステムの生成したセッション文字列を使用することによって最終的な１６０キャラクタのアウトバウンド・メッセージをエンコードする。このＳＭＳメッセージの作成後、このサブシステムは、無線ゲートウェイ１０３にエンド・ユーザへの最終的な送付のためにこれを転送する。
【０１２７】
インバウンド・メッセージ構文解析サブシステム：インバウンド・メッセージ構文解析サブシステム１８６には、まず、着信メッセージのそれぞれを暗号化文字列ならびにシステム共通の暗号化キーおよびＷｅｂＡｐｐ  ＩＤを用いて復号する作業がある。このメッセージが正しく復号できることを検査した後、このサブシステムはインバウンド・テンプレートＩＤを抽出し、インバウンド・テンプレートＤＢからインバウンド・テンプレートを調べて着信メッセージの構文解析を行う。
【０１２８】
インバウンド・メッセージの構文解析が成功すると、着信したコマンドおよびパラメータの抽出が行われる。次いで、このサブシステムは、ユーザＩＤを暗号化文字列から抽出し、この着信した要求のためのコマンド・コンテキスト・オブジェクトを作成する。また、コマンド・コンテキスト・オブジェクトの作成前に、このコンポーネントは、着信した認証用のＰＩＮ番号の検査をアプリケーション・コンポーネント１０８の認証機構を用いて行う。
【０１２９】
次のステップは、このメッセージを関連するアプリケーション・コンポーネントへと実際に発送することである。
【０１３０】
このサブシステムは、メッセージ追跡サブシステムと協力して、受信時間および他の統計情報に関して着信したＳＭＳメッセージの追跡を行う。
【０１３１】
本明細書に記載の諸実施形態は、以前のＳＭＳメッセージング・システムにまさるいくつかの利点および特質を提供する。すなわち、
１．確認
−  インバウンド・テンプレートがアウトバウンドＳＭＳメッセージのテキスト本体の一部であることにより、Ｗｅｂアプリケーションが容易に処理できるような確認のためのシステムが提供される。
−  ＳＭＳ応答データベースにより、メッセージ型が要求するラン・タイム確認の可能性が提供される。
−  これまでのＳＭＳシステムに確認がない点は、ＳＭＳの商取引での適用を阻害している。ユーザの確認を可能にするユーザＩＤやＰＩＮなどの暗号化文字列により、この制限に対する解決策を開示している。
【０１３２】
２．セキュリティ
−  インバウンドＳＭＳメッセージは、好ましくは、２レベルの暗号化を伴う暗号化文字列を含むことができる。これにより、関連するＷｅｂアプリケーションが、そのＷｅｂアプリケーションに向けられた着信ＳＭＳメッセージだけを取り扱うことが保証される。
−  ユーザＩＤは第２のレベルのユーザＩＤキーによって、ユーザの指定するＰＩＮ番号とともに得られ、これにより、セキュリティ保護の層がさらに提供される。
−  ４バイトのセキュリティ機構により、商取引におけるＳＭＳの適用が可能になる。
−  ここで使用する２レベルの暗号化は、２レベルのキーにより復号する４要素（ＷｅｂＡｐｐ  ＩＤ、ユーザＩＤ、インバウンド・テンプレートＩＤ、およびセッション・オブジェクトＩＤ）の４バイトへの混合（amalgamation）と同様、新しいものである。
【０１３３】
３．セッション制御
−  セッションＩＤをＳＭＳ文字列の中で暗号化する（encode）場合、これにより、典型的なｈｔｔｐセッションのためのタイム・アウト制御が提供される。
−  暗号化文字列をアウトバウンド・メッセージとマッチングすることにより、要求および応答モデルが提供され、セッションの形成が可能になる。
−  このセッションにより、ユーザとＷｅｂアプリケーションの間の密接な（cohesive）要求および応答がいまや可能となり、ＳＭＳでの商取引の適用が実際的なものになる。
−  メッセージ内の４バイトの暗号化文字列は新しいものである。
−  暗号化文字列に追加したタイムスタンプおよびシステム・キーは新しいものである。
−  ラン・タイム時の要求／応答ＳＭＳメッセージのセッション効果を管理するためのラン・タイム・プロセスを伴うＳＭＳ応答ＤＢは、ＳＭＳメッセージングにとって新しいものである。
【０１３４】
４．拡張可能なシンタクス：ＳＭＳメッセージをエンコードおよびデコードするための規則
−  エンコードされたインバウンド・メッセージ・テンプレートにより、インバウンドＳＭＳメッセージの一義的な解釈が可能になり、これは、メッセージング・システムのＷｅｂアプリケーションを選択したビジネス・アクションに一義的に対応付けることにつながる。
−  このシンタクスは、新しいインバウンド・メッセージ・テンプレートを作成するために拡張可能である。
−  ユーザが自分のインバウンド・メッセージを定式通り作成しなくてすむようにインバウンド・メッセージ・テンプレートをアウトバウンド・メッセージに含めることは、ＳＭＳにとって新しいものである。いまや、ユーザは要求される特定のパラメータを満たすだけでよくなっている。
−  新しいメッセージ型の中で他のシンタクスを作成するためのシンタクスの拡張性は、新しいものである。
【０１３５】
５．１  拡張可能なセマンティクス：一義的なビジネス・アクションに対応付けられるエンコーディングの解釈
−  本発明の諸実施形態のあらかじめ定義された分類は、ユーザとビジネス・プロセスのＷｅｂアプリケーションとの間の契約として働き、その結果、所与のＳＭＳメッセージの解釈は一義的となり、あらかじめ定義されたビジネス・プロセスの一定のビジネス・アクションに対応付けられ、これにより、ＳＭＳの商取引の適用が可能になる。
−  基本の分類は、ビジネス・アクションの新しい対応付けのために新しい分類を定義するように拡張可能である。
−  （分類および新しい分類を導出することを含む固有の特徴を伴う）ＸＭＬスキーマをＳＭＳユニバーサル・エンコーディング・テンプレートとしてＳＭＳの空間内で適用することは、新しいものである。
【０１３６】
５．２  拡張可能なセマンティクス：対応するメッセージ型におけるエンコーディング特徴によるラン・タイム時におけるＳＭＳメッセージの取り扱い
−  ＳＭＳユニバーサル・エンコーディング・テンプレートにより、Ｗｅｂアプリケーションとメッセージ・ランタイム・プロセッサの間で共有されることになるＳＭＳメッセージについての付加情報が可能になる。ランタイム・プロセッサは、いまや（ＳＭＳの型で定義する付加的なセマンティクス特徴に基づいて）Ｗｅｂアプリケーションの理解する送り手（ビジネス・ユーザ）の意図と矛盾のない、型の点で適切なラン・タイム・タスクを実行することができる。
【０１３７】
６．向上した使用可能性
−  ビジネス・ユーザは、いまやそのビジネスの意図に合わせる（match）ためにＳＭＳメッセージをエンコードすることの技術的な複雑さを味わうことはない。ビジネス・ユーザは、いまやＳＭＳメッセージのエンコーディングで悩むことなく、メッセージの内容に集中することができる。
−  この発明のＳＭＳコマースの解決策により、エンコーディング・エラーの可能性が減少する（ＳＭＳのエンコーディング・エラーはラン・タイム時に解決するのが困難であり、高く付くため）。エンコーディングの機構により、エラー検査が確実なものとなり、エンコーディング・エラーの早期の特定が提供される。
【図面の簡単な説明】
【０１３８】
【図１】本発明の一実施形態における、ＳＭＳを用いてｅ−コマースを実行するシステムを示す構成図である。
【図２】ＳＭＳコマース・インフラストラクチャ・コンポーネントの構造的対応付け（structuralmapping）を示す図である。
【図３】ＳＭＳメッセージ作成ウイザードを使用して新しいＳＭＳの型をＳＭＳユニバーサル・エンコーディング・テンプレートに作成することを示す図である。
【図４】ＳＭＳメッセージ作成ＧＵＩを使用して新しいＳＭＳの型を作成することを示す図である。
【図５】ＳＭＳエンコーディングの流れ図である。
【図６】ＳＭＳメッセージ・エンコーディング・エンジンのＤＣＩ構造図（structurediagram）である。
【図７】ＳＭＳメッセージ・エンコーディング・エンジンの流れ図である。
【図８】受信者ユーザに見える実際のアウトバウンドＳＭＳメッセージの例を示す図である。
【図９】ユーザの応答で満たしたＳＭＳのインバウンド・メッセージを示す図である。
【図１０】ＳＭＳメッセージを作成するためのＧＵＩを示す図である。
【図１１】ＳＭＳインバウンド・テンプレートのメッセージ型への追加を示す図である。
【図１２】インバウンド・テンプレート・マネージャの構造図である。
【図１３】インバウンド・テンプレート管理に関する流れ図である。
【図１４】ＳＭＳメッセージを送るビジネス・ユーザに関する構造図である。
【図１５】図１６に関する流れ図である。
【図１６】確認応答のラン・タイムのフローを示す図である。
【図１７】アウトバウンドの流れ図１である。
【図１８】アウトバウンドの流れ図２である。
【図１９】アウトバウンドの流れ図３である。
【図２０】インバウンドの流れ図１である。
【図２１】インバウンドの流れ図２である。
【図２２】インバウンドの流れ図３である。[MSOffice1]このエレメントの骨格は、「メッセージ・エンコーディング・エンジンがエンコードするステップ」です。to generateのtoを原稿のように「結果のto」として訳すと、まるで原文がencoding and generatingであるかのような日本語となってしまいます。これでは、generatingステップが明らかに発明の必須要素になり、権利行使上不利になります。
【図１】
2006501561.tif 000003
【図２】
2006501561.tif 000004
【図３】
2006501561.tif 000005
【図４】
2006501561.tif 000006
【図５】
2006501561.tif 000007
【図６】
2006501561.tif 000008
【図７】
2006501561.tif 000009
【図８】
2006501561.tif 000010
【図９】
2006501561.tif 000011
【図１０】
2006501561.tif 000012
【図１１】
2006501561.tif 000013
【図１２】
2006501561.tif 000014
【図１３】
2006501561.tif 000015
【図１４】
2006501561.tif 000016
【図１５】
2006501561.tif 000017
【図１６】
2006501561.tif 000018
【図１７】
2006501561.tif 000019
【図１８】
2006501561.tif 000020
【図１９】
2006501561.tif 000021
【図２０】
2006501561.tif 000022
【図２１】
2006501561.tif 000023
【図２２】
2006501561.tif 000024
【国際調査報告】
2006501561.tif 000025
2006501561.tif 000026
2006501561.tif 000027
2006501561.tif 000028
2006501561.tif 000029
2006501561.tif 000030