(57)【特許請求の範囲】
【請求項１】
あるユーザと、前記あるユーザ以外の他のユーザとを含む複数ユーザに対して提供される立替払い額の徴収サービスについてのサービスデータをコンピュータが処理するための方法であって、前記サービスデータはターゲットデータ及びターゲットオブジェクトを含み、前記方法は、
1つまたは複数のプロセッサによって、処理対象となっているサービスアイテムについての前記ターゲットデータと、前記ターゲットオブジェクトの識別子とを含むユーザ入力を受信するステップであって、前記徴収サービスは、前記他のユーザによる支出について前記あるユーザによって行われた立替払い額を徴収するサービスであり、前記ターゲットデータは、前記他のユーザ各々が前記あるユーザに対して支払うべき立替払い額に相当し、前記他のユーザによる支出額に基づいて決定され、現金を含み、前記ターゲットオブジェクトは前記他のユーザを含み、前記処理対象となっているサービスアイテムは前記立替払い額の徴収であるステップと、
前記1つまたは複数のプロセッサによって、前記ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせるステップと、
前記1つまたは複数のプロセッサによって、前記ターゲットデータに関連付けられた前記受信データが前記所定の期間内に存在していると決定したことに応答して、前記ターゲットデータに関連付けられた前記受信データに対して、前記他のユーザのいずれかによる前記あるユーザに対する前記立替払い額の送金に対応する第1の確認対象ラベルを設定するステップと、
前記1つまたは複数のプロセッサによって、第1のメッセージ確認インターフェースを表示するステップであって、前記第1のメッセージ確認インターフェースは、前記第1の確認対象ラベルを有する前記受信データを前記処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、ステップとを含み、
前記ターゲットデータに関連付けられた前記受信データは、前記他のユーザのいずれかからの前記あるユーザに対する前記立替払い額に対応する送金に関する情報を含む
方法。
【請求項２】
前記1つまたは複数のプロセッサによって、前記第1の確認対象ラベルを有する前記受信データを前記処理対象となっているサービスアイテムに結び付けると決定したことに応答して、前記第1の確認対象ラベルを有する前記受信データを前記処理対象となっているサービスアイテムに結び付けるステップをさらに含む、請求項1に記載の方法。
【請求項３】
前記1つまたは複数のプロセッサによって、前記第1の確認対象ラベルを有する前記受信データを前記処理対象となっているサービスアイテムに結び付けないと決定したことに応答して、前記第1の確認対象ラベルを有する前記受信データから前記第1の確認対象ラベルを除去するステップをさらに含む、請求項1に記載の方法。
【請求項４】
前記第1のメッセージ確認インターフェースを表示するステップの前に、前記方法は、
前記1つまたは複数のプロセッサによって、前記処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令が存在しているかどうかを監視するステップと、
前記1つまたは複数のプロセッサによって、前記処理対象となっているサービスアイテムの前記処理インターフェースに入力するための前記操作命令を検出したことに応答して、前記第1のメッセージ確認インターフェースを表示するステップであって、前記第1のメッセージ確認インターフェースは、前記第1の確認対象ラベルを有する前記受信データを前記処理対象となっているサービスアイテムに結び付けるかどうかに関する前記確認メッセージを含む、ステップと
をさらに含む、請求項1に記載の方法。
【請求項５】
前記所定の期間は、
前記処理対象となっているサービスアイテムを生成した時の前又は後の期間を含む、請求項1に記載の方法。
【請求項６】
前記他のユーザ各々が前記あるユーザに対して支払うべき立替払い額は第1の値を含み、
前記ターゲットデータに関連付けられた前記受信データは第2の値を含み、
前記ターゲットデータに関連付けられた前記受信データは、前記第1の値と前記第2の値との差が所定の閾値以下である第1の受信データを含む、請求項1に記載の方法。
【請求項７】
前記1つまたは複数のプロセッサによって、前記サービスアイテムを処理する要求を含むユーザ入力を受信するステップをさらに含む、請求項1に記載の方法。
【請求項８】
前記ユーザ入力は、前記サービスアイテムに関連付けられたオブジェクトデータを含み、前記オブジェクトデータは、前記ターゲットオブジェクトおよびオブジェクトの数を含む、請求項7に記載の方法。
【請求項９】
前記1つまたは複数のプロセッサによって、サービス処理結果を前記ターゲットオブジェクトに送信するステップをさらに含む、請求項1に記載の方法。
【請求項１０】
あるユーザと、前記あるユーザ以外の他のユーザとを含む複数ユーザに対して提供される立替払い額の徴収サービスについてのサービスデータを処理するための装置であって、前記装置は、請求項1から9のいずれか一項に記載の方法を行うように構成された複数のモジュールを含む、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、コンピュータおよびインターネット技術の分野に関し、詳細には、サービスデータを処理するための方法、装置、およびクライアントデバイスに関する。
【背景技術】
【０００２】
電子技術およびインターネット技術の進歩にともない、電子デバイスの機能(特にインテリジェントモバイルデバイス)はより高性能となっており、ユーザが電子デバイス上に様々なアプリケーションプログラムをインストールしているのであれば、電子デバイスはユーザの要求に基づいて様々なトランザクションを完遂し得る。
【０００３】
インテリジェントモバイルデバイスの急速な進歩にともない、より多くのユーザが彼らの日常生活においてモバイル支払いを選択している。現時点、モバイル支払の主なモードは、送金モード、集金モードなどを含む。集金モードは、ユーザが1人または複数のユーザからお金を集金するモードを含む。特に、例えば、ユーザA(受領人)が、ユーザB(支払人)およびユーザC(支払人)からお金を集金する必要があると、ユーザAは、対応する支払人であるユーザBおよびユーザCに対する集金サービスの要求メッセージを開始し得る。その後、ユーザBおよびユーザCは、要求メッセージに基づいて集金サービスに対応する支払インターフェースに入力して、支払いを行い集金サービスを完遂する。上記で説明した集金モードにおいては、支払人が受領人によって送信された集金サービスの要求メッセージに基づいて対応する支払インターフェースに入力して集金サービスを完遂する必要があることが理解できよう。
【０００４】
しかしながら、既存の技術においては、支払人は、集金サービスの要求メッセージをタイミング良く受信しなかった場合には送金モードで支払いを直接行う場合がある。この場合には、支払人は、対応する集金サービスの支払ページに入力して支払いを行わない。結果として、集金サービスは、処理対象となっている継続中のサービスアイテムとなる。その結果、サーバリソースが浪費され、サーバ処理速度に影響を及ぼし、ユーザエクスペリエンスを低減している。
【発明の概要】
【課題を解決するための手段】
【０００５】
本出願の実施形態の目的は、サービスデータを処理するための方法、装置、およびクライアントデバイスを提供して、ユーザが処理対象となっているサービスアイテムを完遂することを支援し、さらに、サーバリソースを解放し、サーバ処理速度を高速化し、ユーザエクスペリエンスを改善することである。
【０００６】
上記で説明した技術的問題を軽減するために、本出願の実施形態を以下の通り実施する。
【０００７】
サービスデータを処理するための方法を提供しており、方法は、処理対象となっているサービスアイテムのターゲットデータを決定するステップと、ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせるステップと、決定の結果がyesであった場合には、ターゲットデータに関連付けられた受信データに対して第1の確認対象ラベルを設定するステップと、第1のメッセージ確認インターフェースを表示するステップであって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、ステップとを含む。
【０００８】
サービスデータを処理するための方法を提供しており、方法は、処理対象となっているサービスアイテムのターゲットオブジェクトを決定するステップと、ターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかを問い合わせるステップと、決定の結果がyesであった場合には、ターゲットオブジェクトによって送信された受信データに対して第2の確認対象ラベルを設定するステップと、第2のメッセージ確認インターフェースを表示するステップであって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、ステップとを含む。
【０００９】
サービスデータを処理するための装置を提供しており、装置は、処理対象となっているサービスアイテムのターゲットデータを決定するように構成される、ターゲットデータ決定モジュールと、ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせるように構成される、第1の問合せモジュールと、第1の問合せモジュールによって決定された結果がyesであった場合には、ターゲットデータに関連付けられた受信データに対して第1の確認対象ラベルを設定するように構成される、第1のラベル設定モジュールと、第1のメッセージ確認インターフェースを表示するように構成される、第1の確認メッセージ表示モジュールであって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、第1の確認メッセージ表示モジュールとを含む。
【００１０】
サービスデータを処理するための装置を提供しており、装置は、処理対象となっているサービスアイテムのターゲットオブジェクトを決定するように構成される、ターゲットオブジェクト決定モジュールと、ターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかを問い合わせるように構成される、第2の問合せモジュールと、第2の問合せモジュールによって決定された結果がyesであった場合には、ターゲットオブジェクトによって送信された受信データに対して第2の確認対象ラベルを設定するように構成される、第2のラベル設定モジュールと、第2のメッセージ確認インターフェースを表示するように構成される、第2の確認メッセージ表示モジュールであって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、第2の確認メッセージ表示モジュールとを含む。
【００１１】
クライアントは、少なくとも1つのプロセッサと、プログラム命令を記憶しているメモリであって、プログラム命令は、少なくとも1つのプロセッサによって実行されると、少なくとも1つのプロセッサに、処理対象となっているサービスアイテムのターゲットデータを決定することと、ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせることと、決定の結果がyesであった場合には、ターゲットデータに関連付けられた受信データに対して第1の確認対象ラベルを設定することと、第1のメッセージ確認インターフェースを表示するための命令を送信することであって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、こととを命令する、メモリと、少なくとも1つのプロセッサに結合されるとともに、第1のメッセージ確認インターフェースを表示するように構成される、表示ユニットであって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、表示ユニットとを含む。
【００１２】
クライアントは、少なくとも1つのプロセッサと、プログラム命令を記憶しているメモリであって、プログラム命令は、少なくとも1つのプロセッサによって実行されると、少なくとも1つのプロセッサに、処理対象となっているサービスアイテムのターゲットオブジェクトを決定することと、ターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかを問い合わせることと、決定の結果がyesであった場合には、ターゲットオブジェクトによって送信された受信データに対して第2の確認対象ラベルを設定することと、第2のメッセージ確認インターフェースを表示するための命令を送信することであって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、こととを命令する、メモリと、少なくとも1つのプロセッサに結合されるとともに、第2のメッセージ確認インターフェースを表示するように構成される、表示ユニットであって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、表示ユニットとを含む。
【００１３】
本出願の実施形態においては、処理対象となっているサービスアイテムの取得したターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかが決定され、対応する処理対象となっているサービスアイテムと一対一の対応関係にあり確認対象となっているラベルがターゲットデータに関連付けられた受信データに対して設定され、その後、確認対象となっているラベルを有する受信データを対応する処理対象となっているサービスアイテムに結びつけるかどうかに関する確認メッセージが表示され、ユーザが処理対象となっているサービスアイテムを完遂することを支援していることが、本出願の実施形態において提供した技術的ソリューションから、理解できるであろう。さらに、サービスデータ支払処理インターフェースに入力する代わりに別の方法でユーザがサービス処理を行うケースを効率的に軽減することができる。既存の技術と比較して、本出願の実施形態において提供した技術的ソリューションは、ユーザが処理対象となっているサービスアイテムを完遂することを支援することができ、さらに、サーバリソースを解放し、サーバ処理速度を高速化し、ユーザエクスペリエンスを改善することができる。
【００１４】
本出願の実施形態におけるまたは既存の技術における技術的ソリューションをより明確に説明するために、実施形態または既存の技術を説明するために必要とされる添付の図面を以下に簡単に説明する。以下の説明内の添付の図面はいくつかの実施形態を示しているに過ぎず、当業者が創造的努力無しでこれらの添付の図面から他の図面をさらに導出し得ることは明らかであろう。
【図面の簡単な説明】
【００１５】
【図１】本出願による、サービスデータを処理するための方法の実施形態を図示している概略フローチャートである。
【図２】本出願による、スマートフォンが集金機能を有するアプリケーションプログラムにアクセスして集金サービスを行う実施形態の開始ページを図示している概略図である。
【図３】本出願による、集金サービスの要求メッセージが送信された後の実施形態のページを図示している概略図である。
【図４】本出願による、集金サービスの要求メッセージが送信された後の実施形態のシナリオを図示している概略図である。
【図５】本出願による、集金サービスの処理ページの実施形態を図示している概略図である。
【図６】本出願による、集金サービスの処理ページに第1のメッセージ確認インターフェースを表示する実施形態を図示している概略図である。
【図７】本出願による、サービスデータを処理するための方法の別の実施形態を図示している概略フローチャートである。
【図８】本出願による、集金サービスを開始した後の実施形態のページを図示している概略図である。
【図９】本出願による、サービスデータを処理するための装置の実施形態を図示している概略構造図である。
【図１０】本出願による、サービスデータを処理するための装置の別の実施形態を図示している概略構造図である。
【図１１】本出願による、サービスデータを処理するための装置の別の実施形態を図示している概略構造図である。
【図１２】本出願による、サービスデータを処理するための装置の別の実施形態を図示している概略構造図である。
【図１３】本出願による、クライアントの例示的な実施形態を図示している概略構造図である。
【発明を実施するための形態】
【００１６】
本出願の実施形態は、サービスデータを処理するための方法、装置、およびクライアントデバイスを提供している。
【００１７】
本出願の実施形態における支払いに関連している技術的なキャリアは、例えば、Near Field Communication(NFC)、Wireless Fidelity(WiFi)、3G/4G/5G、店舗販売時点情報管理(POS)マシンを使用してカードを通す技術、クイックレスポンスコードスキャニング技術、バーコードスキャニング技術、Bluetooth(登録商標)、赤外線、ショートメッセージサービス(SMS)、およびマルチメディアメッセージングサービス(MMS)を含み得る。
【００１８】
当業者に本出願における技術的ソリューションをより良く理解してもらうべく、本出願の実施形態における添付の図面を参照して本出願の実施形態における技術的ソリューションを以下に明確かつ包括的に説明している。説明した実施形態が本出願の実施形態のすべてではなく一部に過ぎないことは明白であろう。創造的努力無しで本出願の実施形態に基づいて当業者によって得られるすべての他の実施形態は、本出願の保護範囲に含まれるものとする。
【００１９】
本出願の実施形態のうちの特定の実施形態をいくつかの特定の例を使用して以下に詳細に説明している。
【００２０】
本出願に従ってサービスデータを処理するための方法の実施形態をまず以下に説明している。図1は、本出願による、サービスデータを処理するための方法の実施形態を図示している概略フローチャートである。本出願は、実施形態またはフローチャートにおいて説明した方法の動作ステップを提供しているが、方法は、従来または非創造的努力に基づいたより多くのまたはより少ない動作ステップを含み得る。実施形態において記載した一連のステップは、多くのステップの実行シーケンスのうちの1つに過ぎず、唯一の実行シーケンスを表しているわけではない。装置またはクライアント製品の実際の実行においては、実行は、実施形態または添付の図面に示した方法のシーケンスに基づいて行われ得る、または、並行して(例えば、パラレルプロセッサまたはマルチスレッド処理環境において)行われ得る。特に、図1に示しているように、方法は、以下のステップを含み得る。
【００２１】
S110: 処理対象となっているサービスアイテムのターゲットデータを決定する。
【００２２】
本出願の本実施形態においては、処理対象となっているサービスアイテムのターゲットデータは、現金を含み得る、または、ボーナスポイントなどの他の仮想オブジェクトを含み得る。一般的に、ターゲットデータは、データの1つまたは複数の要素を含み得る。特定の実施形態においては、例えば、処理対象となっているサービスアイテムは、継続中の集金サービスである。ユーザA、ユーザB、ユーザC、およびユーザDがAAの夕食会で総額107元を使って、支払いがひとまずユーザAによってなされたと仮定する。その後、ユーザAは、集金サービスを開始し得る。それに対応するように、集金サービスのターゲットデータは、ここでは現金であり、26.75元といった1つのデータを含む。別の特定の実施形態においては、ユーザEがユーザX、ユーザY、およびユーザZのために物品を購入し、ユーザXの物品の値段とユーザYの物品の値段とが各々200元であり、ユーザZの物品が300元の値段であったと仮定する。それに対応するように、ユーザEは、集金サービスを開始する際に200元および300元といった2つのターゲットデータを設定し得る。それに対応するように、ユーザX、ユーザY、およびユーザZは、対応する金額を選択して支払いを完遂し得る。
【００２３】
本実施形態においては、例えば、集金機能を有するアプリケーションプログラムがスマートフォンにインストールされている。ユーザA、ユーザB、ユーザC、およびユーザDがAAの夕食会で総額107元を使った上記の実施形態に関連して、図2は、本出願による、スマートフォンが集金機能を有するアプリケーションプログラムにアクセスして集金サービスを行う実施形態の開始ページを図示している概略図である。対応するアプリケーションプログラムにおいてAAの集金機能を有するトリガボタンをタップした後に、ユーザAは、図2に示した集金サービスの開始ページに入力し、総額に107をおよび総人数に4を入力し、集金サービスを開始するためにOKをタップし得る。それに対応するように、サーバは、入力された総額および総人数を使用して対応するターゲットデータを決定し得る。その後、ユーザAは、ユーザB、ユーザC、およびユーザDといった対応する支払人に集金サービスの要求メッセージを送信し得る。
【００２４】
加えて、本出願の実施形態における開始ページが図2中の形式に限定されず、実際の適用状況に関連して別の形式、例えば、ターゲットデータおよび総人数を直接入力する形式をさらに含み得ることを留意されたい。実施形態は本出願の実施形態に限定されない。
【００２５】
図3は、本出願による、集金サービスの要求メッセージが送信された後の実施形態のページを図示している概略図である。ユーザAがグループ内で要求メッセージを送信しグループが通常少なくとも1人の支払人を含み得ることが図3から理解できよう。加えて、本出願の実施形態における要求メッセージが、支払いを支払人に通知するために支払人を含むグループ内で送信され得る、または、対応する支払人に直接送信され得る。実施形態は本出願の実施形態に限定されない。
【００２６】
S120: ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせる。
【００２７】
本出願の本実施形態においては、処理対象となっているサービスアイテムのターゲットデータを決定した後に、ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせ得る。特に、所定の期間は、処理対象となっているサービスアイテムの生成時間に基づいて事前に決定される期間を含み得る。所定の期間は、処理対象となっているサービスアイテムの生成時間を含んでいてもよいし、または処理対象となっているサービスアイテムの生成時間を含まなくてもよい。特に、所定の期間は、処理対象となっているサービスアイテムの生成時間の前の第1の期間、処理対象となっているサービスアイテムの生成時間の後の第2の期間、処理対象となっているサービスアイテムの生成時間の前の第3の期間、または、処理対象となっているサービスアイテムの生成時間の後の第4の期間といった設定方法のうちの少なくとも1つを含む。
【００２８】
特に、特定の値が、実際の適用状況に関連して、第1の期間、第2の期間、第3の期間、および第4の期間の間に設定され得る。第3の期間は、第4の期間と同一であり得る、または、第4の期間とは異なり得る。
【００２９】
特定の実施形態においては、受信データは、受信した送金情報などを含み得る例えば、ユーザXが、あなたに200元を送金する。特に、ターゲットデータに関連付けられた受信データは、ターゲットデータからの差が所定の閾値以下である受信データ、または、ターゲットデータと複数の関係がある受信データのうちの少なくとも1つを含み得る。
【００３０】
いくつかの実施形態においては、集金サービスを例として使用する。ターゲットデータが25.88元であると仮定すると、支払人は、送金の利便性を考慮して26元を直接送金し得る。それに対応するように、送金は、ここで所定の閾値を設定することによってターゲットデータに関連付けられた受信データに含まれ得る。特に、所定の閾値は、ターゲットデータのタイプおよび実際の適用状況に基づいて事前に決定され得る。例えば、ターゲットデータが現金である場合には、所定の閾値は1元に設定され得る。ターゲットデータがボーナスポイントである場合には、所定の閾値は10ボーナスポイントに設定され得る。実施形態は本出願の実施形態に限定されない。
【００３１】
実際には、図4は、AAの夕食会の上記で説明した実施形態に関連して、本出願による、集金サービスの要求メッセージが送信された後の実施形態のシナリオを図示している概略図である。ユーザAが集金サービスの要求メッセージを送信したグループにユーザBおよびユーザDが属し、ユーザBおよびユーザDがユーザAによって送信された要求メッセージを使用して支払いのために対応する支払インターフェースに入力したが、ユーザAが最初に集金サービスの要求メッセージを送信したグループにユーザCが属していないことが見て取れよう。結果として、ユーザCは、ユーザAによって開始された集金サービスの要求メッセージをタイミング良く受信していない。ユーザCがユーザAに対応する金額を直接送金することを選択し、送金の利便性を考慮してユーザAに27元を直接送金したと仮定する。この場合には、ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせることによって、ユーザCがユーザAに27元を送金してきた情報がターゲットデータ26.75元に関連付けられた受信データであることが判明し得る。
【００３２】
別の実施形態においては、集金サービスを例として使用する。1人の支払人は、複数の支払人のための支払いを行い得る。それに対応するように、ターゲットデータに関連付けられた受信データは、ターゲットデータと複数の関係にある受信データを含み得る。加えて、本出願の実施形態におけるターゲットデータに関連付けられた受信データは上記で説明したケースに限定されないことを留意されたい。実際には、データの別の要素をさらに含み得るし、実施形態は本出願の実施形態に限定されない。
【００３３】
S130: 決定の結果がyesであった場合には、ターゲットデータに関連付けられた受信データに対して第1の確認対象ラベルを設定する。
【００３４】
本出願の本実施形態においては、ステップS120における決定の結果がyesであった場合には、第1の確認対象ラベルは、ターゲットデータに関連付けられた受信データに対して設定され得る。特に、第1の確認対象ラベルは、対応する処理対象となっているサービスアイテムと一対一の対応関係にある所定のラベルを含み得る。
【００３５】
特定の実施形態においては、AAの夕食会の上記で説明した実施形態に関連して、上記で説明したAAの夕食会についてユーザAによって開始され得る集金サービスに対応する第1の確認対象ラベルが、ユーザCがユーザAに27元を送金してきた情報に対して設定され得る。
【００３６】
S140: 第1のメッセージ確認インターフェースを表示する、ここで、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む。
【００３７】
本出願の本実施形態においては、第1の確認対象ラベルがターゲットデータに関連付けられた受信データに対して設定された後に、第1のメッセージ確認インターフェースが表示され得る。第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む。特に、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージに基づいて事前に決定されるインターフェースを含み得る。
【００３８】
いくつかの実施形態においては、第1のメッセージ確認インターフェースを表示するステップの前に、方法は、次のこと、すなわち、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令が存在しているかどうかを監視するステップと、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令を検出したことに応答して、第1のメッセージ確認インターフェースを表示するステップであって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、ステップをさらに含み得る。
【００３９】
図5は、本出願による、集金サービスの処理ページの実施形態を図示している概略図である。ユーザが集金サービスの現在の進捗のデータを取得し得ることが図5から理解できよう。
【００４０】
特定の実施形態においては、AAの夕食会の上記で説明した実施形態に関連して、ユーザAが集金サービスの処理インターフェースに入力したことが検出されると、あなたに27元を送金してきたことと送金に関する情報を集金サービスに結びつけるかどうかとを示す確認メッセージが表示される。それに対応するように、ユーザは、確認メッセージおよび集金サービスの現在の進捗に基づいて、データを集金サービスに結び付けるかどうかを決定し得るし、ユーザAが処理対象となっているサービスアイテムを完遂することをさらに支援し得る。図6は、本出願による、集金サービスの処理ページに第1のメッセージ確認インターフェースを表示する実施形態を図示している概略図である。
【００４１】
加えて、本出願の実施形態において第1のメッセージ確認インターフェースを表示するページは図6中の集金サービスの処理ページの形式に限定されず、実際の適用状況に関連して別の形式をさらに含み得ることを留意されたい。実施形態は本出願の実施形態に限定されない。
【００４２】
いくつかの実施形態においては、方法は、次のこと、すなわち、確認メッセージの実行結果がyesであった場合には、第1の確認対象ラベルを有する受信データを処理対象となっているサービスアイテムに結び付けるステップをさらに含み得る。
【００４３】
それに対応するように、いくつかの実施形態においては、方法は、次のこと、すなわち、確認メッセージの実行結果がnoであった場合には、第1の確認対象ラベルを有する受信データからラベルを除去するステップをさらに含み得る。
【００４４】
特に、ラベル除去処理は、第1の確認対象ラベルを除去することを含み得る。
【００４５】
本出願においては、処理対象となっているサービスアイテムの取得したターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかが決定され、対応する処理対象となっているサービスアイテムと一対一の対応関係にある第1の確認対象ラベルがターゲットデータに関連付けられた受信データに対して設定され、その後、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む第1のメッセージ確認インターフェースが表示され、ユーザが処理対象となっているサービスアイテムを完遂することを支援していることが、本出願におけるサービスデータを処理するための方法の実施形態から、理解できるであろう。さらに、サービスデータ支払処理インターフェースに入力する代わりに別の方法でユーザがサービス処理を行うケースを効率的に軽減することができる。既存の技術と比較して、本出願の実施形態において提供した技術的ソリューションは、ユーザが処理対象となっているサービスアイテムを完遂することを支援することができ、さらに、サーバリソースを解放し、サーバ処理速度を高速化し、ユーザエクスペリエンスを改善することができる。
【００４６】
本出願に従ってサービスデータを処理するための方法の別の実施形態を以下に説明している。図7は、本出願による、サービスデータを処理するための方法の別の実施形態を図示している概略フローチャートである。本出願は、実施形態またはフローチャートにおいて説明した方法の動作ステップを提供しているが、方法は、従来または非創造的努力に基づいたより多くのまたはより少ない動作ステップを含み得る。実施形態において記載した一連のステップは、多くのステップの実行シーケンスのうちの1つに過ぎず、唯一の実行シーケンスを表しているわけではない。装置またはクライアント製品の実際の実行においては、実行は、実施形態または添付の図面に示した方法のシーケンスに基づいて行われ得る、または、並行して(例えば、パラレルプロセッサまたはマルチスレッド処理環境において)行われ得る。特に、図7に示しているように、方法は、以下のステップを含み得る。
【００４７】
S710: 処理対象となっているサービスアイテムのターゲットオブジェクトを決定する。
【００４８】
本出願の本実施形態においては、例えば、処理対象となっているサービスアイテムは、継続中の集金サービスであり、処理対象となっているサービスアイテムのターゲットオブジェクトは、対応する支払人を含み得る。AAの夕食会の上記で説明した実施形態に関連して、総額および総人数を入力して図2中のOKボタンをタップした後に、ユーザは、集金サービスの要求メッセージを対応する支払人に送信する必要がある。それに対応するように、支払人のアカウント情報は、処理対象となっているサービスアイテムのターゲットオブジェクトとして取得され得る。図8は、本出願による、集金サービスを開始した後の実施形態のページを図示している概略図である。ユーザが支払人を選択」のボタンをタップして集金サービスの要求メッセージを対応する支払人に送信し得ることが図8から理解できよう。
【００４９】
S720: ターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかを問い合わせる。
【００５０】
本出願の本実施形態においては、処理対象となっているサービスアイテムのターゲットオブジェクトを決定した後に、ターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかが問い合わされ得る。特に、所定の期間は、処理対象となっているサービスアイテムのトリガ時間に基づいて事前に決定される期間を含み得る。好ましくは、所定の期間は、処理対象となっているサービスアイテムの生成時間の前の第1の期間、処理対象となっているサービスアイテムの生成時間の後の第2の期間、処理対象となっているサービスアイテムの生成時間の前の第3の期間、または、処理対象となっているサービスアイテムの生成時間の後の第4の期間といった期間のうちの少なくとも1つを含む。
【００５１】
特定の実施形態においては、受信データは、受信した送金情報などを含み得る例えば、ユーザXが、あなたに200元を送金する。
【００５２】
S730: 決定の結果がyesであった場合には、ターゲットオブジェクトによって送信された受信データに対して第2の確認対象ラベルを設定する。
【００５３】
本出願の本実施形態においては、ステップS720における決定の結果がyesであった場合には、第2の確認対象ラベルは、ターゲットオブジェクトによって送信された受信データに対して設定され得る。特に、第2の確認対象ラベルは、対応する処理対象となっているサービスアイテムと一対一の対応関係にある所定のラベルを含み得る。
【００５４】
S740: 第2のメッセージ確認インターフェースを表示する、ここで、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む。
【００５５】
本出願の本実施形態においては、第2のメッセージ確認インターフェースが表示され得る。第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む。特に、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージに基づいて事前に決定されるインターフェースを含み得る。
【００５６】
いくつかの実施形態においては、第2のメッセージ確認インターフェースを表示するステップの前に、方法は、次のこと、すなわち、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令が存在しているかどうかを監視するステップと、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令を検出したことに応答して、第2のメッセージ確認インターフェースを表示するステップであって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、ステップをさらに含み得る。
【００５７】
いくつかの実施形態においては、方法は、次のこと、すなわち、確認メッセージの実行結果がyesであった場合には、第2の確認対象ラベルを有する受信データを処理対象となっているサービスアイテムに結び付けるステップをさらに含み得る。
【００５８】
いくつかの実施形態においては、方法は、次のこと、すなわち、確認メッセージの実行結果がnoであった場合には、第2の確認対象ラベルを有する受信データからラベルを除去するステップをさらに含み得る。
【００５９】
本出願においては、処理対象となっているサービスアイテムのターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかが決定され、対応する処理対象となっているサービスアイテムと一対一の対応関係にある第2の確認対象ラベルがターゲットオブジェクトによって送信された受信データに対して設定され、その後、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む第2のメッセージ確認インターフェースが表示され、ユーザが処理対象となっているサービスアイテムを完遂することを支援していることが、本出願におけるサービスデータを処理するための方法の実施形態から、理解できるであろう。さらに、サービスデータ支払処理インターフェースに入力する代わりに別の方法でユーザがサービス処理を行うケースを効率的に軽減することができる。既存の技術と比較して、本出願の実施形態において提供した技術的ソリューションは、ユーザが処理対象となっているサービスアイテムを完遂することを支援することができ、さらに、サーバリソースを解放し、サーバ処理速度を高速化し、ユーザエクスペリエンスを改善することができる。
【００６０】
本出願の別の態様は、サービスデータを処理するための装置をさらに提供する。図9は、本出願による、サービスデータを処理するための装置の実施形態を図示している概略構造図である。図9に示しているように、装置900は、処理対象となっているサービスアイテムのターゲットデータを決定するように構成される、ターゲットデータ決定モジュール910と、ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせるように構成される、第1の問合せモジュール920と、第1の問合せモジュール920によって決定された結果がyesであった場合には、ターゲットデータに関連付けられた受信データに対して第1の確認対象ラベルを設定するように構成される、第1のラベル設定モジュール930と、第1のメッセージ確認インターフェースを表示するように構成される、第1の確認メッセージ表示モジュール940であって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、第1の確認メッセージ表示モジュール940とを含み得る。
【００６１】
図10は、本出願による、サービスデータを処理するための装置の別の実施形態を図示している概略構造図である。図10に示しているように、装置900は、確認メッセージの実行結果がyesであった場合には、第1の確認対象ラベルを有する受信データを処理対象となっているサービスアイテムに結び付けるように構成される、第1のデータ結合モジュール950をさらに含み得る。
【００６２】
別の実施形態においては、装置900は、確認メッセージの実行結果がnoであった場合には、第1の確認対象ラベルを有する受信データからラベルを除去するように構成される、第1のラベル除去モジュールをさらに含み得る。
【００６３】
別の実施形態においては、装置は、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令が存在しているかどうかを監視するように構成される、第1の監視モジュールをさらに含み得るし、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令を検出したことに応答して、第1のメッセージ確認インターフェースが表示され、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む。
【００６４】
別の実施形態においては、所定の期間は、処理対象となっているサービスアイテムの生成時間の前の第1の期間、処理対象となっているサービスアイテムの生成時間の後の第2の期間、処理対象となっているサービスアイテムの生成時間の前の第3の期間、または、処理対象となっているサービスアイテムの生成時間の後の第4の期間といった期間のうちの少なくとも1つを含み得る。
【００６５】
別の実施形態においては、ターゲットデータに関連付けられた受信データは、ターゲットデータからの差が所定の閾値以下である受信データ、または、ターゲットデータと複数の関係がある受信データのうちの少なくとも1つを含み得る。
【００６６】
本出願は、サービスデータを処理するための装置の別の実施形態をさらに提供する。図11は、本出願による、サービスデータを処理するための装置の別の実施形態を図示している概略構造図である。図11に示しているように、装置1100は、処理対象となっているサービスアイテムのターゲットオブジェクトを決定するように構成される、ターゲットオブジェクト決定モジュール1110と、ターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかを問い合わせるように構成される、第2の問合せモジュール1120と、第2の問合せモジュール1120によって決定された結果がyesであった場合には、ターゲットオブジェクトによって送信された受信データに対して第2の確認対象ラベルを設定するように構成される、第2のラベル設定モジュール1130と、第2のメッセージ確認インターフェースを表示するように構成される、第2の確認メッセージ表示モジュール1140であって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、第2の確認メッセージ表示モジュール1140とを含み得る。
【００６７】
図12は、本出願による、サービスデータを処理するための装置の別の実施形態を図示している概略構造図である。図12に示しているように、装置1100は、確認メッセージの実行結果がyesであった場合には、第2の確認対象ラベルを有する受信データを処理対象となっているサービスアイテムに結び付けるように構成される、第2のデータ結合モジュール1150をさらに含み得る。
【００６８】
別の実施形態においては、装置1100は、確認メッセージの実行結果がnoであった場合には、第2の確認対象ラベルを有する受信データからラベルを除去するように構成される、第2のラベル除去モジュールをさらに含み得る。
【００６９】
別の実施形態においては、装置は、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令が存在しているかどうかを監視するように構成される、第2の監視モジュールをさらに含み得るし、処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令を検出したことに応答して、第2のメッセージ確認インターフェースが表示され、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む。
【００７０】
別の実施形態においては、所定の期間は、処理対象となっているサービスアイテムの生成時間の前の第1の期間、処理対象となっているサービスアイテムの生成時間の後の第2の期間、処理対象となっているサービスアイテムの生成時間の前の第3の期間、または、処理対象となっているサービスアイテムの生成時間の後の第4の期間といった期間のうちの少なくとも1つを含み得る。
【００７１】
本出願の別の態様は、クライアントの実施形態をさらに提供しており、クライアントは、少なくとも1つのプロセッサと、プログラム命令を記憶しているメモリであって、プログラム命令は、少なくとも1つのプロセッサによって実行されると、少なくとも1つのプロセッサに、処理対象となっているサービスアイテムのターゲットデータを決定することと、ターゲットデータに関連付けられた受信データが所定の期間内に存在しているかどうかを問い合わせることと、決定の結果がyesであった場合には、ターゲットデータに関連付けられた受信データに対して第1の確認対象ラベルを設定することと、第1のメッセージ確認インターフェースを表示するための命令を送信することであって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、こととを命令する、メモリと、少なくとも1つのプロセッサに結合されるとともに、プロセッサが処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令を検出すると、第1のメッセージ確認インターフェースを表示するように構成される、表示ユニットであって、第1のメッセージ確認インターフェースは、第1の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、表示ユニットとを含み得る。
【００７２】
図13は、本出願による、クライアントの例示的な実施形態を図示している概略構造図である。
【００７３】
別の実施形態においては、クライアントのプログラム命令は、次のこと、すなわち、確認メッセージの実行結果がyesであった場合には、第1の確認対象ラベルを有する受信データを処理対象となっているサービスアイテムに結び付けることをさらに含み得る。
【００７４】
別の実施形態においては、クライアントのプログラム命令は、次のこと、すなわち、確認メッセージの実行結果がnoであった場合には、第1の確認対象ラベルを有する受信データからラベルを除去することをさらに含み得る。
【００７５】
本出願は、クライアントの別の実施形態をさらに提供しており、クライアントは、少なくとも1つのプロセッサと、プログラム命令を記憶しているメモリであって、プログラム命令は、少なくとも1つのプロセッサによって実行されると、少なくとも1つのプロセッサに、処理対象となっているサービスアイテムのターゲットオブジェクトを決定することと、ターゲットオブジェクトによって送信された受信データが所定の期間内に存在しているかどうかを問い合わせることと、決定の結果がyesであった場合には、ターゲットオブジェクトによって送信された受信データに対して第2の確認対象ラベルを設定することと、第2のメッセージ確認インターフェースを表示するための命令を送信することであって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、こととを命令する、メモリと、少なくとも1つのプロセッサに結合されるとともに、プロセッサが処理対象となっているサービスアイテムの処理インターフェースに入力するための操作命令を検出すると、第2のメッセージ確認インターフェースを表示するように構成される、表示ユニットであって、第2のメッセージ確認インターフェースは、第2の確認対象ラベルを有する受信データを対応する処理対象となっているサービスアイテムに結び付けるかどうかに関する確認メッセージを含む、表示ユニットとを含み得る。
【００７６】
別の実施形態においては、クライアントのプログラム命令は、次のこと、すなわち、確認メッセージの実行結果がyesであった場合には、第2の確認対象ラベルを有する受信データを処理対象となっているサービスアイテムに結び付けることをさらに含み得る。
【００７７】
別の実施形態においては、クライアントのプログラム命令は、次のこと、すなわち、確認メッセージの実行結果がnoであった場合には、第2の確認対象ラベルを有する受信データからラベルを除去することをさらに含み得る。
【００７８】
特に、本出願の本実施形態においては、プロセッサは、中央処理ユニット(CPU)を含み得るし、当然のことながら、ロジック処理能力を有するシングルチップマイクロコンピュータ、ロジックゲート回路、集積回路など、またはそれらの適切な組合せをさらに含み得る。表示ユニットは、プロジェクションデバイスなどのモバイルデバイス表示画面を含み得る。
【００７９】
本出願においては、処理対象となっているサービスアイテムに関連している受信データが決定され、対応する処理対象となっているサービスアイテムと一対一の対応関係にあり確認対象となっているラベルが関連している受信データに対して設定され、その後、確認対象となっているラベルを有する受信データを対応する処理対象となっているサービスアイテムに結びつけるかどうかに関する確認メッセージを含むメッセージ確認インターフェースが表示され、ユーザが処理対象となっているサービスアイテムを完遂することを支援していることが、本出願におけるサービスデータを処理するための方法、装置、およびクライアントデバイスの実施形態から、理解できるであろう。さらに、サービスデータ支払処理インターフェースに入力する代わりに別の方法でユーザがサービス処理を行うケースを効率的に軽減することができる。既存の技術と比較して、本出願の実施形態において提供した技術的ソリューションは、ユーザが処理対象となっているサービスアイテムを完遂することを支援することができ、さらに、サーバリソースを解放し、サーバ処理速度を高速化し、ユーザエクスペリエンスを改善することができる。
【００８０】
1990年代においては、技術改善がハードウェア改善(例えば、ダイオード、トランジスタ、またはスイッチなどの回路構造の改善)であるかソフトウェア改善(方法の手順の改善)であるかは明確に区別し得た。しかしながら、技術が進歩するにつれて、多くの方法の手順に対する今日の改善をハードウェア回路構造の直接的な改善として扱うことができるようになった。設計者は、通常、改善した方法の手順をハードウェア回路にプログラムして、対応するハードウェア回路構造を得る。したがって、方法の手順をハードウェアエンティティモジュールを使用して改善し得る。例えば、プログラマブルロジックデバイス(PLD)(例えば、フィールドプログラマブルゲートアレイ(FPGA))がそのような集積回路であり、プログラマブルロジックデバイスの論理機能がデバイスプログラミングによりユーザによって決定される。設計者は、チップ製造業者に特定用途向け集積回路チップを設計および製造するように要求することなく、プログラミングを行い、デジタルシステムをPLDに「統合」する。加えて、プログラミングは、集積回路チップを手動で製造する代わりに、「ロジックコンパイラ」というソフトウェアを変更することによってほとんどが実施される。このことはプログラムを開発およびコンパイル処理ために使用されるソフトウェアコンパイラと同様である。しかしながら、コンパイル処理の前に元のコードはまた、特定のプログラミング言語で書かれており、この言語は、ハードウェア記述言語(HDL)と称する。Advanced Boolean Expression Language(ABEL)、Altera Hardware Description Language(AHDL)、Confluence、Cornell University Programming Language(CUPL)、HDCal、Java(登録商標) Hardware Description Language(JHDL)、Lava、Lola、MyHDL、PALASM、およびRuby Hardware Description Language(RHDL)などの多くのHDLが存在する。現時点、Very-High-Speed Integrated Circuit Hardware Description Language(
VHDL)およびVerilogが最も一般的に使用されている。ひとたび方法の手順がいくつかの説明したハードウェア記述言語を使用して論理的にプログラムされ集積回路にプログラムされると論理的な方法の手順を実施するハードウェア回路を容易に得ることができることも当業者は理解すべきである。
【００８１】
コントローラは、任意の適切な方法で実装され得る。例えば、コントローラは、マイクロプロセッサ、プロセッサ、または、プロセッサによって実行することができるコンピュータ可読プログラムコード(例えば、ソフトウェアまたはファームウェア)を記憶している、コンピュータ可読媒体、ロジックゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブルロジックコントローラ、および組み込みマイクロコントローラであり得る。コントローラの例としては、ARC625D、Atmel AT91SAM、Microchip PIC18F26K20、またはSilicone Labs C8051F320といったマイクロコントローラを含むがこれらに限定されない。メモリコントローラはまた、メモリの制御ロジックの一部として実装され得る。当業者も知っての通り、コントローラを純粋なコンピュータ可読プログラムコード方法を使用して実装することが可能であり、コントローラがロジックゲート、スイッチ、特定用途向け集積回路、プログラマブルロジックコントローラ、組み込みマイクロコントローラなどの形式で同一の機能を実装することができるように方法のステップを論理的にすることが可能である。したがって、コントローラは、ハードウェアコンポーネントとみなされ得るし、コントローラに含まれコントローラ内の様々な機能を実施するように構成された装置もハードウェアコンポーネント内の構造としてみなされ得る。あるいは、様々な機能を実施するように構成された装置は、方法を実施し得るソフトウェアモジュールまたはハードウェアコンポーネントにおける構造とみなされ得る。
【００８２】
上記の実施形態において示した装置およびモジュールは、コンピュータチップまたはエンティティを使用して実装され得る、または、ある機能を有する製品を使用して実装され得る。典型的な実施デバイスがコンピュータである。特に、コンピュータは、例えば、パーソナルコンピュータ、ラップトップコンピュータ、セルラ電話、カメラ電話、スマートフォン、携帯情報端末、メディアプレーヤ、ナビゲーションデバイス、電子メールデバイス、ゲームコンソール、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスの任意の組合せであり得る。
【００８３】
説明を簡潔にするために、上記の装置は、機能を様々なモジュールに分割することによって説明している。当然のことながら、本出願を実施する際には、各モジュールの機能は、ソフトウェアおよび/またはハードウェアの1つまたは複数の要素において実施され得る。
【００８４】
本開示の実施形態が方法、システム、またはコンピュータプログラム製品として提供され得ることを当業者は理解されたい。したがって、本開示は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアとの組合せを用いた実施形態の形式を使用し得る。加えて、本開示は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(磁気ディスクメモリ、コンパクトディスクリードオンリーメモリ(CD-ROM)、および光学メモリなどを含むがこれらに限定されない)上で実施されるコンピュータプログラム製品の形式を使用し得る。
【００８５】
本開示は、本開示の実施形態に基づいて、方法、デバイス(装置)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明している。コンピュータプログラム命令がフローチャートおよび/またはブロック図中の各プロセスおよび/または各ブロックならびにフローチャートおよび/またはブロック図中のプロセスおよび/またはブロックの組合せを実施するために使用され得ることを留意されたい。このようなコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行された命令がフローチャート中の1つまたは複数のプロセスにおけるおよび/またはブロック図中の1つまたは複数のブロックにおける特定の機能を実施するための装置を生成するように、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または別のプログラマブルデータ処理デバイスのプロセッサに提供され、機構を生成し得る。
【００８６】
このようなコンピュータプログラム命令は、コンピュータ可読メモリに記憶されている命令が命令装置を含むアーチファクトを生成するように、コンピュータまたは別のプログラマブルデータ処理デバイスが特定の方法で動作するように命令し得るコンピュータ可読メモリに記憶され得る。命令装置は、フローチャート中の1つまたは複数のプロセスにおけるおよび/またはブロック図中の1つまたは複数のブロックにおける特定の機能を実施する。
【００８７】
このようなコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスにロードされ得る、その結果、一連の動作およびステップがコンピュータまたは別のプログラマブルデバイス上で行われ、それによって、コンピュータ実施処理を生成している。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、フローチャート中の1つまたは複数のプロセスにおいておよび/またはブロック図中の1つまたは複数のブロックにおいて特定の機能を実施するためのステップを提供する。
【００８８】
典型的な設定においては、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入力/出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。
【００８９】
メモリは、例えば、リードオンリーメモリ(ROM)またはフラッシュメモリ(フラッシュRAM)といった、コンピュータ可読媒体に存在する、非持続性メモリ、ランダムアクセスメモリ(RAM)、および/または不揮発性メモリを含み得る。メモリは、コンピュータ可読媒体の一例である。
【００９０】
コンピュータ可読媒体は、任意の方法または技術を使用して情報を記憶することができる、持続性、非持続性、リムーバブル、および非リムーバブルメディアを含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであり得る。コンピュータ記憶媒体の例としては、位相変化ランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのランダムアクセスメモリ(RAM)、リードオンリーメモリ(ROM)、電気的消去可能プログラマブルリードオンリーメモリ(EEPROM)、フラッシュメモリ、もしくは別のメモリ技術と、コンパクトディスクリードオンリーメモリ(CD-ROM)、デジタル多用途ディスク(DVD)、もしくは別の光学ストレージと、カセット、カセット磁気ディスクストレージ、もしくは別の磁気ストレージデバイスと、または任意の他の非伝送媒体とを含むがこれらに限定されない。コンピュータ記憶媒体は、コンピューティングデバイスによってアクセスされ得る情報を記憶するために使用され得る。本明細書において説明しているように、コンピュータ可読媒体は、変調データ信号およびキャリアなどのコンピュータ可読一時的媒体(一時的媒体)を含まない。
【００９１】
「含む」、「備える」といった用語、またはそれらの任意の他の類型は、非排他的な包含をカバーすることを意図しており、その結果、多くの要素を含むプロセス、方法、物品、もしくはデバイスが、これらの要素だけでなく、明示的に記載していない他の要素も含む、または、そのようなプロセス、方法、物品、もしくはデバイスに本来備わっている要素をさらに含むことをさらに留意されたい。「・・・を含む」で終わる要素は、さらなる制約がない状態で、要素を含むプロセス、方法、物品、またはデバイスにおける追加の同一要素の存在を除外することはしない。
【００９２】
本出願の実施形態が方法、装置、またはコンピュータプログラム製品として提供され得ることを当業者は理解されたい。したがって、本開示は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアとの組合せを用いた実施形態の形式を使用し得る。加えて、本出願は、コンピュータ使用可能プログラムコードを含む(磁気ディスクメモリ、コンパクトディスクリードオンリーメモリ(CD-ROM)、光学メモリを含むがこれらに限定されない)1つまたは複数のコンピュータ使用可能記憶媒体上で実施されるコンピュータプログラム製品の形式を使用し得る。
【００９３】
本出願は、プログラムモジュールなどの、コンピュータによって実行されるコンピュータ実行可能命令の一般的な状況において説明することができる。一般的に、プログラムモジュールは、特定のタスクを実行するまたは特定の抽象データタイプを実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本出願はまた、分散コンピューティング環境において実施することができる。これらの分散コンピューティング環境においては、タスクは、通信ネットワークを使用して接続されたリモート処理デバイスによって実行される。分散コンピューティング環境においては、プログラムモジュールは、ストレージデバイスを含むローカルコンピュータ記憶媒体およびリモートコンピュータ記憶媒体に位置し得る。
【００９４】
本明細書の実施形態は、漸進的方法で説明している。実施形態における同一または同様の部分については、実施形態を参照されたい。各実施形態は、他の実施形態とは異なる部分に焦点を置いている。特に、装置またはクライアントの実施形態は、方法の実施形態と基本的に同様であるため、したがって、簡潔に説明している。関連する部分については、方法の実施形態における説明の一部を参照されたい。
【００９５】
上記の説明は、本出願の実施形態であり、本出願を限定することは意図していない。当業者は、本出願に対して様々な修正および変更をなし得る。本出願の精神および原理から逸脱することなくなされた任意の修正、均等物との置換、または改善は、本出願における特許請求の範囲の範囲に含まれるものとする。
【符号の説明】
【００９６】
900  サービスデータを処理するための装置
910  ターゲットデータ決定モジュール
920  第1の問合せモジュール
930  第1のラベル設定モジュール
940  第1の確認メッセージ表示モジュール
950  第1のデータ結合モジュール
1100  サービスデータを処理するための装置
1110  ターゲットオブジェクト決定モジュール
1120  第2の問合せモジュール
1130  第2のラベル設定モジュール
1140  第2の確認メッセージ表示モジュール
1150  第2のデータ結合モジュール
【図１】
0006860670.tif 000002
【図２】
0006860670.tif 000003
【図３】
0006860670.tif 000004
【図４】
0006860670.tif 000005
【図５】
0006860670.tif 000006
【図６】
0006860670.tif 000007
【図７】
0006860670.tif 000008
【図８】
0006860670.tif 000009
【図９】
0006860670.tif 000010
【図１０】
0006860670.tif 000011
【図１１】
0006860670.tif 000012
【図１２】
0006860670.tif 000013
【図１３】
0006860670.tif 000014