JP6921200B2 - サービス処理方法およびデバイス - Google Patents

Description

本出願は、インターネット技術の分野に関し、特にサービス処理方法およびデバイスに関する。

インターネット技術および電子デバイス技術の急速な発展とともに、VRデバイス、パーソナルコンピュータ、タブレットコンピュータ、またはスマートフォン等の電子デバイスのタイプがますます多くなる。異なるタイプの電子デバイスが、異なるオペレーティングシステムを実行することがあり、対話命令を書くために種々のプログラミング言語を使用する。そのために、ある種のサービスを提供するサービスプロバイダは、種々のタイプの電子デバイスに対して異なるアプリケーションプログラムを開発することが通常必要である。

例えば、例としてK線共有グラフ(share graph)を提供するサービスプロバイダを使用することにより、スマートフォン、パーソナルコンピュータ、およびVRデバイスは、サービスプロバイダにより提供されるK線共有グラフを見るために、サービスプロバイダにより提供されるウェブサイトにすべてアクセスすることができるか、または、サービスプロバイダにより提供されるアプリケーションプログラムをインストールすることができる。K線共有グラフを見るプロセスでは、デバイスは、左へのシフティング、右へのシフティング、ピンチングおよびストレッチング、または上へのスライディング等の対話命令をさらに始めることができ、サービスプロバイダは、対話命令に基づいてK線共有グラフ上で対応する処理を実行し、ディスプレイを表示するためにデバイスに対して処理されたデータを提供する。スマートフォン、パーソナルコンピュータ、およびバーチャルリアリティ(VR)デバイスにより始められた対話命令に関して、サービスプロバイダは、種々のデバイスに対して異なるサービス処理モジュールを開発し、種々のデバイスの対話命令を検出しそして特定する必要がある。関連技術におけるサービス処理モードでは、サービスプロバイダが比較的大量の開発リソースおよびコストを投資する必要があることを学習することができる。

関連技術における問題を軽減するために、本出願は、サービス処理方法およびデバイスを提供する。

本出願の実装形態の第1の態様によれば、サービス処理方法が提供され、ここでは各デバイスタイプに対応する命令処理ルールが上記方法にしたがって構成され、上記方法は、対話データを表示することを必要とする電子デバイスのデバイスタイプを検出するステップと、上記検出したデバイスタイプに対応する命令処理ルールを取得するステップと、上記命令処理ルールに基づいて、上記電子デバイスにより始められたデバイス対話命令を取得するステップと、上記デバイス対話命令を対応する一元化した対話命令へと変換するステップと、変換を介して取得した上記一元化した対話命令に対応するサービス処理モードを呼び出すことにより上記対話データを処理するステップと、表示のために上記電子デバイスに対して処理された対話データを提供するステップとを含む。

任意選択の実装形態では、対話データを表示することを必要とする電子デバイスのデバイスタイプを上記検出するステップが、上記電子デバイスへデバイスタイプの問合せ要求を始めるステップと、上記問合せ要求に基づいて上記電子デバイスによりフィードバックされるデバイスタイプ記述情報を受信するステップと、上記デバイスタイプ記述情報に基づいて上記デバイスタイプを決定するステップとを含む。

任意選択の実装形態では、上記命令処理ルールが、上記電子デバイスにより始められた上記デバイス対話命令を取得するために使用される命令捕捉ルールと、上記デバイス対話命令を上記対応する一元化した対話命令へと変換するために使用される命令セット変換ルールとを含む。

任意選択の実装形態では、上記命令処理ルールが、開発側デバイスにより送られる、デバイスタイプ、デバイス対話命令、および一元化した対話命令の間の対応関係を受信するステップと、上記対応関係に基づいて上記命令処理ルールを構成するステップとの方法に予め構成される。

任意選択の実装形態では、上記一元化した対話命令に関するコード化体系が、デバイス対話命令に関する種々のデバイスタイプのうちの1つのコード化体系である。

本出願の実装形態の第2の態様によれば、サービス処理デバイスが提供され、ここでは各デバイスタイプに対応する命令処理ルールが、上記デバイスにしたがって構成され、上記デバイスが、対話データを表示することを必要とする電子デバイスのデバイスタイプを検出するように構成された、タイプ検出モジュールと、上記検出したデバイスタイプに対応する命令処理ルールを取得するように構成された、ルール捕捉モジュールと、上記命令処理ルールに基づいて、上記電子デバイスにより始められたデバイス対話命令を取得し、上記デバイス対話命令を対応する一元化した対話命令へと変換するように構成された、命令変換モジュールと、変換を介して取得した上記一元化した対話命令に対応するサービス処理モードを呼び出すことにより上記対話データを処理し、表示のために上記電子デバイスに対して処理された対話データを提供するように構成された、サービス処理モジュールとを含む。

任意選択の実装形態では、上記タイプ検出モジュールが、上記電子デバイスへのデバイスタイプの問合せ要求を始め、上記問合せ要求に基づいて上記電子デバイスによりフィードバックされるデバイスタイプ記述情報を受信し、上記デバイスタイプ記述情報に基づいて上記デバイスタイプを決定するようにさらに構成される。

任意選択の実装形態では、上記命令処理ルールが、上記電子デバイスにより始められた上記デバイス対話命令を取得するために使用される命令捕捉ルールと、上記デバイス対話命令を上記対応する一元化した対話命令へと変換するために使用される命令セット変換ルールとを含む。

任意選択の実装形態では、上記命令処理ルールが、開発側デバイスにより送られる、デバイスタイプ、デバイス対話命令、および一元化した対話命令の間の対応関係を受信するステップと、上記対応関係に基づいて上記命令処理ルールを構成するステップとの方法に予め構成される。

任意選択の実装形態では、上記一元化した対話命令に関するコード化体系が、デバイス対話命令に関する種々のデバイスタイプのうちの1つのコード化体系である。

本出願の実装形態の第3の態様によれば、サービス処理デバイスが提供され、プロセッサと、プロセッサ実行可能な命令を記憶するように構成されたメモリとを含み、ここでは上記プロセッサが、対話データを表示することを必要とする電子デバイスのデバイスタイプを検出し、上記検出したデバイスタイプに対応する命令処理ルールを取得し、上記命令処理ルールに基づいて、上記電子デバイスにより始められたデバイス対話命令を取得し、上記デバイス対話命令を対応する一元化した対話命令へと変換し、変換を介して取得した上記一元化した対話命令に対応するサービス処理モードを呼び出すことにより上記対話データを処理し、表示のために上記電子デバイスに対して処理された対話データを提供するように構成される。

本出願の実装形態において提供する技術的解決法は、下記の有益な効果を含むことができる。

本出願の実装形態では、各デバイスタイプに対応する命令処理ルールが構成される。そのために、種々のタイプの電子デバイスのデバイス対話命令は、一元化した対話命令へと変換されることがある。一元化した対話命令に対応するサービス処理モードが予め構成されるという理由で、対話データが処理されることがあり、処理された対話データが、表示のために電子デバイスに対して提供されることがある。本出願の実装形態では、同じ対話効果が、種々のエンドユーザデバイスおよびサポート能力に基づいて達成されることがあり、開発者は、種々のデバイスに対して異なる対話モジュールを開発する必要がない。そのために、開発リソースおよびコストが、著しく削減されることが可能であり、開発効率が向上されることが可能である。

これまでに説明した一般的な説明および下記の詳細な説明が、説明のための単なる例にすぎず、本出願を限定しないことを理解すべきである。

ここに添付している図面は、明細書に組み込まれ、明細書の一部になり、本出願にしたがった実装形態を示し、そして本出願の原理を説明するために明細書とともに使用される。

本出願の例の実装形態による、サービス処理シナリオを図説する模式図である。 本出願の例の実装形態による、サービス処理方法を図説するフローチャートである。 本出願の例の実装形態による、電子デバイスにより表示される対話ページを図説する模式図である。 本出願の例の実装形態による、デバイス対話命令および一元化した対話命令の処理を図説する模式図である。 例の実装形態による、サービス処理方法のアプリケーションシナリオを図説する図である。 本出願の例の実装形態による、模式的構成図である。 例の実装形態による、3つの電子デバイスのサービス処理を図説する模式図である。 例の実装形態による、もう1つのサービス処理方法を図示するフローチャートである。 本出願の例の実装形態による、サービス処理デバイスが設置される電子デバイスのハードウェア構造を図説する図である。 本出願の例の実装形態による、サービス処理デバイスを図説するブロック図である。

例の実装形態がここで詳細に説明され、例の実装形態の実施例が添付の図面に提示されている。下記の説明が添付の図面に関係するときには、特に規定しない限り、異なる添付の図面における同じ番号は、同じまたは類似の要素を表している。下記の例の実装形態において説明する実装形態は、本出願と整合するすべての実装形態を表してはいない。対照的に、実装形態は、別記の特許請求の範囲において詳細に記述され、本出願のいくつかの態様と整合するデバイスおよび方法の単なる例にすぎない。

本出願において使用する用語は、単に特定の実装形態を説明する目的のためであり、本出願を限定するものではない。本出願および別記の特許請求の範囲において使用される単数形での「1つ(a)」、「前記(said)」および「その(the)」という用語は、明確に文脈において特に規定しない限り、複数形も含むものとする。明細書において使用される「および/または(and/or)」という用語は、1つまたは複数の関係する列挙した項目のうちのいずれかまたはすべての可能な組み合わせを示しそして含むことがさらに理解されるはずである。

「第1の」、「第2の」、「第3の」等の用語が様々な情報を説明するために本出願において使用されることがあるとはいえ、情報は、上記の用語により限定されないことが理解されるはずである。これらの用語は、同じタイプの情報同士の間を区別するために単に使用されるにすぎない。例えば、本出願の範囲から逸脱せずに、第1の情報が、第2の情報としても呼ばれることがあり、そして同様に第2の情報が、第1の情報としても呼ばれることがあり、このことは、文脈に依存する。例えば、ここで使用される「の場合に(if)」という用語は、「の一方で(while)」、「のときに(when)」、または「決定することに応じて(in response to determining)」として説明されることがある。

インターネット技術および電子デバイス技術の急速な発展とともに、VRデバイス、パーソナルコンピュータ、タブレットコンピュータ、またはスマートフォン等の電子デバイスのタイプがますます多くなる。異なるタイプの電子デバイスが、異なるオペレーティングシステムを実行することがあり、対話命令を書くために種々のプログラミング言語を使用することができる。そのために、いくつかのサービスを提供するサービスプロバイダは、異なるタイプの電子デバイスに対して異なるアプリケーションプログラムを開発することが通常必要である。

関係する技術では、多くのサービスが、サービス処理に関係する。例では、財務グラフにおけるサービスプロバイダは、K線共有グラフを見るサービスをユーザに提供することができる。電子デバイスがK線共有グラフを表示すると、ユーザは、表示されたグラフ上で上へのスライディング、下へのスライディング、またはピンチングとストレッチング等の対話操作を実行する必要があり得る。電子デバイスは、ユーザによって実行された対話操作に基づくサービス処理の後で取得されるグラフデータを取得することができ、そして新しいグラフを表示することができる。もう1つの例では、マップサービスを提供するサービスプロバイダは、マップを見るサービスを提供することができる。電子デバイスがマップを表示すると、ユーザは、表示されたマップ上で上へのスライディング、下へのスライディング、またはピンチングとストレッチング等の対話操作を実行する必要があり得る。電子デバイスは、ユーザによって実行された対話操作に基づくサービス処理の後で得られるマップデータを取得することができ、そして新しいマップを表示することができる。

サービスプロバイダは、通常、種々のタイプの電子デバイスに対して種々のアプリケーションプログラムを開発する必要があり、そのために、サービスプロバイダが比較的大量の開発リソースおよびコストを投資する必要がある。本出願の実装形態は、サービスプロバイダの開発コストおよび開発リソースを削減し、そして対話システムの開発効率を改善するために、サービス処理解決法を提供する。下記は、本出願の実装形態を詳細に説明する。

図1Aは、本出願の例の実装形態による、サービス処理シナリオを図説する模式図である。サービスプロバイダおよび異なるタイプの3つの電子デバイスが図1Aに含まれ、ユーザは、電子デバイス上にサービスプロバイダにより提供されるアプリケーションプログラムをインストールすることができる。

図1Bは、本出願の例の実装形態による、サービス処理方法を図説するフローチャートである。各デバイスタイプに対応する命令処理ルールは、上記方法にしたがって構成され、上記方法は、下記のステップ101から104を含むことができる。

ステップ101：対話データを表示することを必要とする電子デバイスのデバイスタイプを検出する。

ステップ102：検出したデバイスタイプに対応する命令処理ルールを取得する。

ステップ103：命令処理ルールに基づき、電子デバイスにより始められたデバイス対話命令を取得し、デバイス対話命令を対応する一元化した対話命令へと変換する。

ステップ104：変換を介して取得した一元化した対話命令に対応するサービス処理モードを呼び出すことにより対話データを処理し、表示のために電子デバイスに対して処理された対話データを提供する。

この実装形態では、サービス処理プロセスが異なるデバイスに対してであるとはいえ、ユーザが種々のデバイスに対して達成することが必要である対話操作対象は、一貫性がある。例えば、図1Cは、電子デバイスにより表示された対話ページを図説する模式図である。対話ページに比較的大量のデータがあるという理由で、電子デバイスは、データの一部だけしか表示せず、図の右にあるデータは、デバイス画面には表示されない。ユーザが図の右にあるデータを見る必要があると仮定すると、電子デバイスがタッチ機能をサポートするデバイスである場合には、ユーザは、タッチスクリーン上で左へスライドさせることができ、電子デバイスは、左へのスライディングのイベントを検出し、図の右にあるデータが表示される必要があることを判断する。電子デバイスがパーソナルコンピュータである場合には、ユーザは、マウスを使用することによりページ上で左へとドラッグすること、マウスを使用することによりページ上に表示されたスライディング制御部の操作を実行すること、キーボード上の方向キーを使用することにより左へとシフトすることなどができる。パーソナルコンピュータは、これまでに説明したイベントのうちの1つを検出し、図の右にあるデータが表示される必要があることを判断する。電子デバイスがVRデバイスである場合には、ユーザは頭を右へ回してもよい。VRデバイスは、イベントを検出し、図の右にあるデータが表示される必要があることを判断する。

これまでに説明した解析に基づいて、種々の電子デバイスが同じ1つの対話データに対して使用されるとはいえ、ユーザが達成する必要がある対話操作対象には、一貫性があると判断することができる。そのために、この実装形態では、一元化した対話命令が同じ対話データ処理対象に対して予め構成され、種々のデバイスタイプについての命令処理ルールが、一元化した対話命令に対して予め決定され、そして対応するサービス処理モードが構成される。

例えば、図1Dは、デバイス対話命令および一元化した対話命令の処理を図説する模式図である。図1Dは、4つの電子デバイスにより始められる左へのスライディングの対話命令を示している。各タイプに対応する命令処理ルールに応じて、対応する命令処理ルールは、同じ一元化した対話命令が続くことがあり、対応するサービス処理モードが一元化した対話命令に対して予め構成される。そのために、サービス処理モードが、対話データを処理するために呼び出されることがある。

デバイスタイプが、異なる対話トリガモードをサポートするデバイス同士の間を区別するために使用され、デバイスタイプは、重力検知機能をサポートする電子デバイス、VRデバイス、パーソナルコンピュータ、ジェスチャ認識機能をサポートする電子デバイス等を含むことができる。実際には、デバイスタイプは、必要に応じて柔軟に構成されることがある。このことは、この実装形態では限定されない。デバイスタイプ同士の間を区別することの目的は、異なるタイプの電子デバイスが異なるオペレーティングシステムを動作させることができ、対話命令をコード化するために異なるプログラミング言語を使用することができるという理由で、対応する命令処理ルールが、電子デバイスにより始められた対話命令を処理するため対応する命令処理ルールを呼び出すために種々のデバイスタイプに対して予め構成されるということである。

アプリケーションプログラムが電子デバイスにインストールされそして開始された後で、デバイスタイプが先ず検出されることがある。例えば、デバイスが、VRデバイス、重力検知機能をサポートするデバイス、ジェスチャ認識機能をサポートするデバイス、マウスにアクセスするデバイス等であるかどうかが、引き続いて検出されることがある。いくつかの例では、いくつかのアプリケーションプログラムは、電子デバイスのデバイスタイプを決定するために、電子デバイスの関連するデバイス情報、例えば、MACアドレス、デバイス名、またはデバイスモデルを直接読み取るための許可を有することがある。いくつかの他の例では、電子デバイスのオペレーティングシステムは、デバイス情報読み取りインターフェースを有する。そのために、対話データを表示することを必要とする電子デバイスのデバイスタイプを検出することはデバイスタイプの問合せ要求を電子デバイスに対して始めるステップ、問合せ要求に基づいて電子デバイスによりフィードバックされるデバイスタイプ記述情報を受信し、デバイスタイプ記述情報に基づいてデバイスタイプを決定するステップをさらに含む。

この実装形態では、デバイスタイプの問合せ要求は、電子デバイスが有するインターフェースを使用することにより電子デバイスに対して始められることがある。電子デバイスは、アプリケーションプログラムにより要求されたとしてアプリケーションプログラムへデバイスタイプ記述情報を送る。アプリケーションプログラムは、デバイスタイプ記述情報を受信し、デバイスタイプ記述情報に基づいてデバイスタイプを決定する。デバイスタイプ記述情報は、デバイスタイプ情報、MACアドレス、デバイス名、デバイスモデル等であってもよい。

電子デバイスのデバイスタイプが決定された後で、デバイスタイプに対応する命令処理ルールが、電子デバイスにより始められたデバイス対話命令を取得するため、およびデバイス対話命令を一元化した対話命令へと変換するために呼び出されることがある。電子デバイスのデバイス対話命令をどのように取得するかに関して、いくつかの例では、電子デバイスのオペレーティングシステムは、ユーザにより始められた対話操作を捕えることができる。オペレーティングシステムは、対話命令の関連インターフェースを有し、電子デバイスのアプリケーションプログラムは、インターフェースを使用することによりデバイス対話命令を取得することができる。インターフェースを使用することによりデバイス対話命令をどのように取得するかは、種々のオペレーティングシステム必要性に基づいて柔軟に構成されてもよい。

一元化した対話命令は、必要な実際の対話に基づいて1つまたは複数の命令および命令の組み合わせに予め決められる。例えば、一元化した対話命令は、タッピング、タッチングとホールディング、左へのスライディング、右へのスライディング、上へスライディング、下へスライディング、ピンチングとストレッチング、および回転のうちの1つまたは組み合わせを含むことができる。一元化した対話命令に関するコード化体系は、実際には柔軟に構成されてもよく、例えば、一元化した対話命令は、数字、文字、または文字列を使用することによって識別されてもよい。例えば、「タッピング」を表す一元化した対話命令は、「abc」として表され、「タッチングとホールディング」を表す一元化した対話命令は、「xyz」として表される、などである。このことは、この実装形態では限定されない。

開発コストを削減し、開発効率を向上させるために、任意選択の実装形態では、一元化した対話命令に関するコード化体系は、デバイス対話命令に関する種々のデバイスタイプのうちの1つのコード化体系である。この実装形態では、すべてのデバイスタイプの対応するコード化体系がデバイス対話命令に対して構成されてきているという理由で、コード化体系のうちの1つが、一元化した対話命令に関するコード化体系として選択されることがある。例えば、4つのデバイスタイプがあると仮定して、デバイス対話命令に関して4つのデバイスタイプのコード化体系が取得されることがあり、上記コード化体系のうちの1つが一元化した対話命令に関するコード化体系として選択されることがあり、言い換えると、複数のデバイスタイプのうちの1つのデバイス対話命令が一元化した対話命令として使用される。そのために、開発コストが削減されることがあり、サービス処理効率を著しく改善するために、命令変換が選択したデバイスタイプのデバイス対話命令に実行される必要がない。

種々のオペレーティングシステムのデバイス対話命令が異なる方法で取得され得ることがこれまでに説明した解析から学習されることが可能であり、命令処理ルールが、デバイス対話命令を取得し、デバイス対話命令を一元化した対話命令へと変換するために使用されることがある。いくつかの例では、デバイスタイプが異なることがあるが、電子デバイスは、すべて同じオペレーティングシステムで動作する。同じオペレーティングシステムに対して、デバイス対話命令を取得するためのインターフェースが同じであってもよい。しかしながら、デバイスタイプが異なるという理由で、種々のトリガモードがサポートされることがある。例えば、重力センサをサポートするデバイスとジェスチャイベントをサポートするデバイスとの両方は、これらが2つの異なるタイプのデバイスであるとはいえ、Android（登録商標）オペレーティングシステムで動作することができる。このケースでは、命令処理ルールは、電子デバイスにより始められたデバイス対話命令を取得するために使用される命令捕捉ルールおよびデバイス対話命令を対応する一元化した対話命令へと変換するために使用される命令セット変換ルールを含む。

この実装形態では、開発者は、必要に応じて命令セット変換ルールを柔軟に構成することができる。任意選択の実装形態では、命令セット変換ルールは、開発側デバイスにより送られる、デバイスタイプ、デバイス対話命令、および一元化した対話命令の間の対応関係を受信するステップと、上記対応関係に基づいて命令処理ルールを構成するステップとの方法に予め構成される。

この実装形態では、開発者は、命令拡張機能をさらに提供されてもよく、そして開発者は、必要に応じて一元化した対話命令を拡張することができる。具体的に、開発者は、対応関係に基づいて命令処理ルールを予め構成するために、必要に応じてデバイスタイプ、デバイス対話命令、および一元化した対話命令の間の対応関係を構成することができる。

一元化した対話命令を構成するという理由で、開発者は、サービス処理開発を実行するときに異なるデバイス同士の間の適応性を考慮する必要がない。そのために、開発コストが、著しく削減されることがあり、作業量が高められることがある。実際に、一元化した対話命令SDKは、図1Bに示したステップ101から103にわたって開発されることがあり、SDK(独立したモジュールと理解されてもよい)が、(ステップ104に対応する)サービス処理を実行する開発者に提供されることがある。加えて、複数の種々のデバイスに組み込まれることがあるウェブビューコンポーネント等の対話コンポーネントが使用されるときには、開発効率がさらに著しく改善されることがある。例えば、一元化した対話命令の処理が、独立したSDKとして使用されることがあり、SDKは、ウェブビュー(ブラウザカーネル)技術に基づくことがある。そのために、これまでに説明した処理によれば、開発者は、サービス処理プロセスにおける一元化した対話命令に基づいて一元化したモジュールだけを開発することができ、一元化したモジュールが、種々の電子デバイスのサービス処理プロセスに適用されることがある。ウェブビューコンポーネントは、パーソナルコンピュータ、インテリジェントエンドユーザデバイス(AndroidまたはiOS（登録商標）等)、およびVRデバイスのすべての対応するシステムに組み込まれる。そのために、ウェブビュー(ウェブビューカーネルが組み込まれているネイティブアプリケーションまたはブラウザに直接基づくウェブアプリケーションを含む)に基づいて実行された開発は、すべてのエンドユーザデバイスにほとんど適用される。そのために、ウェブ開発技術(javascript（登録商標）、html、css等)を使用することによりウェブビューに基づくこの実装形態において提供されるSDKを導入することによって、開発者は、様々なエンドユーザデバイス上への展開を実行することができ、アプリケーションプログラムの1つのセットだけを展開することによって一元化したサービス処理効果を達成することができる。この実装形態における解決法を使用することによって、1セットのコードを介した多端末展開が実施されることがあり、自動アダプテーションが同じ対話効果を達成するために複数のデバイス対話モードをサポートし、開発コストが削減されることがあり、そして再使用性が比較的高い。

下記は、ある実装形態を使用することによって詳細に、本出願の実装形態におけるサービス処理解決法を説明する。この実装形態では、サービスプロバイダは、グラフサービスプロバイダであってもよく、ユーザに対してビジュアルおよび対話グラフデータを提供できる。グラフデータにユーザにより実行される操作は、左や右へのスライディング、上や下へのスライディング、ピンチングとストレッチング等を通常含む。この実装形態では、一元化したグラフ対話が、ユーザが達成することを必要とする操作効果を達成するために、パーソナルコンピュータ、スマートフォン、タブレットコンピュータ、またはウェブ技術(ウェブビューまたはwebVR API等)に基づくVRデバイス等のエンドユーザデバイスの種々の対話操作のために実施されることがある。

図2Aは、例の実装形態による、サービス処理方法のアプリケーションシナリオを図説する図である。サービスプロバイダとして働いている開発者の2つのグループが図2Aには含まれており、開発者グループAは、対話命令開発を担当し、開発者グループBは、サービス処理開発を担当する。

開発者グループAは、デバイスタイプを予め決定することができ、電子デバイスにより始められるデバイス対話命令を取得するために使用される命令捕捉ルールを構成することができ、そして種々のデバイスタイプに対して、デバイス対話命令を対応する一元化した対話命令へと変換するために使用される命令セット変換ルールを構成することができる。

一元化した対話命令は、基本的なタッピング、タッチングとホールディング、左へのスライディング、右へのスライディング、上へのスライディング、下へのスライディング、ピンチングとストレッチング、および回転のうちの1つまたは組み合わせを含む。開発者グループBがより多くの必要性を有する場合には、開発者グループBは、開発者グループAへ命令必要性を提出することができ、これがデバイスタイプ、デバイス対話命令、および一元化した対話命令の間の対応関係であってもよい。開発者グループAは、開発者グループBによる必要に応じて、命令処理ルールをさらに構成する。

開発者グループAは、開発者グループB用の一元化した対話命令SDKを提供し、アプリケーション開発者は、SDKを使用することにより開発を直接実行することができる、またはSDKの拡張モジュールを使用することによりカスタム化した命令セットを拡張することができる。SDKは、(javascriptファイルを使用することにより送られる)オンラインリソースを直接導入することによりウェブビューにアクセスされることがある、またはアプリケーションパッケージングにリリースするためおよびフェーズをリリースするためオフラインリソースとしてアプリケーションに直接パッケージされることがある。そのために、SDKによりサポートされるアプリケーションの範囲は、特定のオペレーティングシステムに基づいているネイティブアプリケーションをカバーし、そしてブラウザベースのオンラインウェブアプリケーション等もまたサポートすることができる。SDKのアプリケーション範囲は、比較的広いことがある。

開発者グループBは、種々のデバイス同士の間のアダプテーションを考慮する必要がないだけでなく、一元化した対話命令により必要とされるサービス処理モードを構成する必要があるだけである。開発者グループAおよび開発者グループBの開発実績は、アプリケーションプログラムのサブモジュールとして別々に使用される。実際に、サービスプロバイダは、必要に応じて他の機能を有するより多くのサブモジュールを開発することができる。最後に、サービスプロバイダのアプリケーションプログラムが、種々のユーザに対して提供されることがあり、種々の電子デバイスにインストールされることがある。アプリケーションプログラムは、開発者グループAおよび開発者グループBによって開発されたモジュールを含む。図2Bは、本出願の例の実装形態による、アプリケーションプログラムを図説する模式的構成図である。図2Cは、例の実装形態による、3つの電子デバイスのサービス処理を図説する模式図である。パーソナルコンピュータ、VRデバイス、およびスマートフォンが、図2Cに含まれている。種々の電子デバイスは、図1または図2Dに示した実装形態における方法を実行することができる。そのために、1セットのコードを介した多端末展開が、実施されることがあり、自動アダプテーションが、同じ対話効果を達成するために複数のデバイス対話モードをサポートし、開発コストが削減されることがあり、そして再利用性が比較的高い。

具体的に、図2Bおよび図2Dを参照して、電子デバイスが始動した後では、サービス処理プロセスは、次の通りである。

エンドユーザデバイス検出：電子デバイスがVRデバイス、重力センサをサポートするエンドユーザデバイス、ジェスチャイベントをサポートするエンドユーザデバイス、またはマウスデバイスであるかどうかが検出される。

命令受信モジュール：VR命令受信モジュール、重力検知命令受信モジュール、ジェスチャイベント命令受信モジュール、マウス操作命令受信モジュールが、種々のデバイスタイプに基づいて事前に用意され、対応する命令受信モジュールがエンドユーザデバイスのタイプに基づいてロードされる。

一元化した命令セット：一元化した対話命令セットが、種々のデバイスタイプに基づいて事前に用意される。

命令変換モジュール：受信した命令が、これまでに説明しロードされた命令受信モジュールに基づいて一元化した対話命令へと変換される。

グラフシステム：一元化した対話命令が受信され、アイコンコンポーネントが、ユーザチェックのために電子デバイスへアイコンコンポーネントを出力するために一元化した対話命令に基づいて描かれる。

サービス処理方法のこれまでに説明した実装形態に対応して、本出願は、サービス処理デバイスおよびサービス処理デバイスが適用される電子デバイスの実装形態をさらに提供する。

本出願におけるサービス処理デバイスの実装形態が、電子デバイスに適用されることがある。デバイス実装形態が、ソフトウェアを使用することにより実装されることがある、またはハードウェアもしくはハードウェアとソフトウェアの組み合わせを使用することにより実装されることがある。例としてソフトウェア実装形態を使用して、論理的な感覚でデバイスは、サービス処理を実行するプロセッサが不揮発性メモリ内の対応するコンピュータプログラム命令を実行するためにメモリに読み込んだ後で得られる。ハードウェアの観点から、図3は、本出願による、サービス処理デバイスが設置される電子デバイスのハードウェア構造を図説する図である。プロセッサ310に加えて、メモリ330、ネットワークインターフェース320、および不揮発性メモリ340が図3に示され、この実装形態におけるデバイス331が設置されている電子デバイスは、電子デバイスの実際の機能に基づいて他のハードウェアを通常さらに含むことができる。詳細は、簡単化のためにここでは省略される。

図4は、本出願の例の実装形態による、サービス処理デバイスを図説するブロック図である。各デバイスタイプに対応する命令処理ルールがデバイスにしたがって構成され、このデバイスは、下記を含む。すなわち、対話データを表示することを必要とする電子デバイスのデバイスタイプを検出するように構成された、タイプ検出モジュール41、検出したデバイスタイプに対応する命令処理ルールを取得するように構成された、ルール捕捉モジュール42、命令処理ルールに基づいて、電子デバイスにより始められたデバイス対話命令を取得し、このデバイス対話命令を対応する一元化した対話命令へと変換するように構成された、命令変換モジュール43、および変換を介して得られた一元化した対話命令に対応するサービス処理モードを呼び出すことにより対話データを処理し、表示のために電子デバイスに対して処理された対話データを提供するように構成された、サービス処理モジュール44を含む。

任意選択の実装形態では、タイプ検出モジュール41は、電子デバイスへデバイスタイプの問合せ要求を始め、問合せ要求に基づいて電子デバイスによりフィードバックされるデバイスタイプ記述情報を受信し、そしてデバイスタイプ記述情報に基づいてデバイスタイプを決定するようにさらに構成される。

任意選択の実装形態では、命令処理ルールは、電子デバイスにより始められたデバイス対話命令を取得するために使用される命令捕捉ルール、およびデバイス対話命令を対応する一元化した対話命令へと変換するために使用される命令セット変換ルールを含む。

任意選択の実装形態では、命令処理ルールが、開発側デバイスにより送られる、デバイスタイプ、デバイス対話命令、および一元化した対話命令の間の対応関係を受信するステップと、上記対応関係に基づいて命令処理ルールを構成するステップとの方法に予め構成される。

任意選択の実装形態では、一元化した対話命令に関するコード化体系は、デバイス対話命令に関する種々のデバイスタイプのうちの1つのコード化体系である。

相応して、本出願は、プロセッサおよびプロセッサ実行可能な命令を記憶するように構成されたメモリを含んでいるサービス処理デバイスをさらに提供し、ここでプロセッサは、対話データを表示することを必要とする電子デバイスのデバイスタイプを検出し、検出したデバイスタイプに対応する命令処理ルールを取得し、命令処理ルールに基づいて、電子デバイスにより始められたデバイス対話命令を取得し、デバイス対話命令を対応する一元化した対話命令へと変換し、そして変換を介して取得した一元化した対話命令に対応するサービス処理モードを呼び出すことにより対話データを処理し、表示のために電子デバイスに対して処理された対話データを提供するように構成される。

サービス処理デバイス内のモジュールの機能および役割の具体的な実施プロセスに関して、サービス処理方法における対応するステップの実施プロセスを参照する。詳細は、簡略化のためにここでは省略される。

デバイス実装形態が方法実装形態に基本的に対応するという理由で、関連部品に関して、方法実装形態の部分的な説明を参照することができる。説明されたデバイス実装形態は、単に例にすぎない。別々の部品として説明されたモジュールは、物理的に別々であってもなくてもよく、モジュールとして表示された部品は、物理モジュールであってもなくてもよい、言い換えると、1つの場所に設置されてもよい、または複数のネットワークモジュールに分散されてもよい。複数のモジュールのうちのいくつかまたはすべてが、本出願の解決法の目的を達成するために、実際の必要性に基づいて選択されることがある。当業者は、創造的な努力なしに本明細書の実装形態を理解し実施することができる。

当業者は、明細書を検討し、ここに開示した本出願を実行した後で、本出願の他の実施解決法を容易に理解することができる。本出願は、本出願の任意の変形形態、機能、または適応的な変更をカバーするものとする。これらの変形形態、機能、または適応的な変更は、本出願の一般的な原理にしたがい、本出願には開示されていない技術分野における一般常識または一般に使用される技術的な意味を含む。明細書および実装形態は、例として単に考えられるにすぎず、本出願の実際の範囲および思想は、別記の特許請求の範囲により示される。

本出願が上に説明されそして添付の図面に示されている正確な構造には限定されず、修正および変更が本出願の範囲から逸脱せずに行い得ることが、理解されるはずである。本出願の範囲は、別記の特許請求の範囲によってのみ限定される。

これまでに説明した説明は、本出願の実装形態の単に例にすぎないだけでなく、本出願を限定するものではない。本出願の思想および原理から逸脱せずに行われる任意の修正、等価な置換、または改善は、本出願の保護範囲内になるべきである。

41 タイプ検出モジュール
42 ルール捕捉モジュール
43 命令変換モジュール
44 サービス処理モジュール
310 プロセッサ
320 ネットワークインターフェース
330 メモリ
331 デバイス
340 不揮発性メモリ

Claims (7)

1. サービス処理のための方法であって、
   対話データを表示するための電子デバイスのデバイスタイプを検出するステップと、
   前記デバイスタイプに対応する命令処理ルールを取得するステップと、
   前記命令処理ルールに基づいて、前記電子デバイスにより始められたデバイス対話命令を取得するステップであり、前記命令処理ルールが前記デバイスタイプに対応する、取得するステップと、
   前記デバイス対話命令を一元化した対話命令へと変換するステップと、
   変換を介して取得した前記一元化した対話命令に対応するサービス処理モードを呼び出すことにより前記対話データを処理するステップと、
   表示のために前記電子デバイスに対して前記対話データを提供するステップと
   を含む、方法。
2. 対話データを表示する前記電子デバイスの前記デバイスタイプを検出するステップが、
   前記電子デバイスに関する前記デバイスタイプに対応する問合せ要求を始めるステップと、
   前記問合せ要求に基づいて前記電子デバイスによりフィードバックされるデバイスタイプ記述情報を受信するステップと、
   前記デバイスタイプ記述情報に基づいて前記デバイスタイプを決定するステップと
   を含む、請求項1に記載の方法。
3. 前記命令処理ルールが、前記電子デバイスにより始められた前記デバイス対話命令を取得するために使用される命令捕捉ルールと、前記デバイス対話命令を前記一元化した対話命令へと変換するために使用される命令セット変換ルールとを含む、請求項1に記載の方法。
4. 前記命令処理ルールが、
   開発側デバイスにより送られる、デバイスタイプ、デバイス対話命令、および前記一元化した対話命令の間の対応関係を受信するステップと、前記対応関係に基づいて前記命令処理ルールを構成するステップと
   を含む、請求項1に記載の方法。
5. 前記一元化した対話命令が、複数の異なるデバイスタイプのうちの第1のデバイスタイプに対応するコード化体系を含む、請求項1に記載の方法。
6. 前記電子デバイスが、パーソナルコンピュータ、インテリジェントエンドユーザデバイスまたはバーチャルリアリティデバイスを備える、請求項1に記載の方法。
7. 請求項1から6のいずれか一項に記載の方法を実行するように構成されたコンピュータプログラム。

Images