(57)【要約】  電子商取引ユーザーからの定期注文を処理するための方法及びシステム。選択製品の定期注文のために受信されたユーザー・リクエストに従って、複数の発注タスクの実行時間を確定するために、サーバ・システムが使用される。サーバ・システムは、周期タスクを生成してデータベース内へ記憶する。アプリケーション・サーバが、データベースから履行予定タスクを読み込んで、製品を出荷するためのロジスティック命令を作成するために、読み込んだ履行予定タスクを実行する。ユーザーは、再発注の必要なく、指定時間に注文製品を定期的に受け取る。
2017510886.tif 000002
【特許請求の範囲】
【請求項１】
定期注文の処理方法であって、
選択製品の定期注文のために受信されたユーザー・リクエストに従って、定期注文を設定する複数のタスクの各々の実行時間を確定すること、
各々の履行予定実行時間及び前記選択製品の情報などのデータを含む前記複数のタスクを生成してデータベース内へ記憶すること、
前記データベース内に記憶された前記複数のタスクから履行予定タスクを読み込むこと、及び
読み込んだタスクに従って前記製品を出荷するためのロジスティック命令を作成するために、前記読み込んだ履行予定タスクを実行することからなる前記方法。
【請求項２】
さらに、複数のアプリケーション・サーバ間で現在の受付周期内の前記履行予定タスクを配分することからなる、請求項１に記載の方法。
【請求項３】
前記履行予定タスクを配分することが、予めデザインされたアルゴリズムを使用する制御サーバによって行われる、請求項２に記載の方法。
【請求項４】
前記履行予定タスクを配分することが、
前記複数のアプリケーション・サーバ間で前記現在の受付周期内の前記履行予定タスクを配分させるようにデザインされたアルゴリズムを使用するために、各アプリケーション・サーバによって制御サーバから命令を受信すること、及び
前記命令及び前記アルゴリズムを使用する各アプリケーション・サーバによって、前記履行予定タスクのいずれを前記各々のアプリケーション・サーバによって読み込ませるべきかを判定することからなる、請求項２に記載の方法。
【請求項５】
前記履行予定タスクを配分することが、
前記複数のアプリケーション・サーバをモニターすること、及び
ダウンタイム状態にない前記アプリケーション・サーバ間で、前記現在の受付周期内の前記履行予定タスクを配分することからなる、請求項２に記載の方法。
【請求項６】
前記履行予定タスクを配分することが、
前記複数のアプリケーション・サーバをモニターすること、及び
ダウンタイム状態にない前記アプリケーション・サーバへ前記履行予定タスクを読み込むための命令を送信することからなる、請求項２に記載の方法。
【請求項７】
さらに、
前記複数のアプリケーション・サーバをモニターすること、及び
一つ以上のアプリケーション・サーバのダウンタイムが検出された場合、ダウンタイム状態にない前記アプリケーション・サーバ間で前記現在の受付周期内の前記履行予定タスクを再配分することからなる、請求項２に記載の方法。
【請求項８】
前記複数のアプリケーション・サーバ間で前記履行予定タスクを配分することが、
各アプリケーション・サーバへＩＤ番号を割り当て、且つ各履行予定タスクへＩＤ番号を割り当てること、
各履行予定タスクに関して、前記各々の履行予定タスクの前記ＩＤ番号に対する前記アプリケーション・サーバの合計数のモジュロを演算すること、及び
各アプリケーション・サーバへ、前記各々のアプリケーション・サーバの前記ＩＤ番号に一致するモジュロになった前記履行予定タスクを配分することからなる、請求項２に記載の方法。
【請求項９】
各アプリケーション・サーバへＩＤ番号を割り当てることが、制御サーバによって行われる、請求項８に記載の方法。
【請求項１０】
前記複数のアプリケーション・サーバ間で前記現在の受付周期の前記履行予定タスクを配分することが、
各アプリケーション・サーバへ命令を送信すること（前記命令は、前記アプリケーション・サーバの合計数と前記命令を受信する前記アプリケーション・サーバの各々のＩＤ番号とを示すデータを含む）、
各アプリケーション・サーバで、前記履行予定タスクのいずれが、前記各々のアプリケーション・サーバの前記ＩＤ番号に一致するモジュロに対応するかを判定すること（各履行予定タスクに対応する前記モジュロは、前記アプリケーション・サーバの合計数を前記履行予定タスクの前記各々のＩＤ番号で除算した剰余である）、及び
各アプリケーション・サーバによって、前記各々のアプリケーション・サーバの前記ＩＤ番号に一致するモジュロに対応する前記履行予定タスクのみを読み込むことからなる、請求項２に記載の方法。
【請求項１１】
各アプリケーション・サーバへ命令を送信することが、制御サーバによって行われる、請求項１０に記載の方法。
【請求項１２】
さらに、将来の読み取り処理によって実行済み履行予定タスクが再度読み込まれることを回避するために、実行された前記履行予定タスクを完了と標識することからなる、請求項１に記載の方法。
【請求項１３】
プリセット・タスク読み取り周期が、各々が異なるセットのタスク読み取り周期を有する複数の読み取りスレッドを含む、請求項１に記載の方法。
【請求項１４】
各読み取りスレッドの前記セットのタスク読み取り周期が、均一に分割された時間間隔を有し、各間隔の長さが、一つのスレッドから次のスレッドへ延長する、請求項１３に記載の方法。
【請求項１５】
さらに、すべての前記複数の読み取りスレッドが実行された後に未実行のまま残った履行予定タスクを、例外キューへ書き込むことからなる、請求項１３に記載の方法。
【請求項１６】
前記データベースから前記履行予定タスクを読み込むことが、複数のアプリケーション・サーバ間で配分されて、各アプリケーション・サーバのプリセット・タスク読み取り周期が、各々が異なるセットのタスク読み取り周期を含む複数の読み取りスレッドからなる請求項１に記載の方法であって、さらに、
各アプリケーション・サーバに関して、前記複数の読み取りスレッドを使用する前記アプリケーション・サーバによって読み込まれた前記履行予定タスクを、複合タスク実行キューへ書き込むこと、及び
前記複合タスク実行キューから前記履行予定タスクの重複を削除することからなる前記方法。
【請求項１７】
定期注文の処理方法であって、
選択製品の定期注文のために受信されたユーザー・リクエストに従って、定期注文を設定する複数のタスクの各々の実行時間を確定すること、
前記各々の履行予定実行時間及び前記選択製品の情報などのデータを含む前記複数のタスクを生成してデータベース内へ記憶すること、
前記複数のタスクを複数のアプリケーション・サーバ間で配分すること、及び
前記製品を出荷するためのロジスティック命令を作成するために、履行予定タスクを実行することからなる前記方法。
【請求項１８】
前記複数のアプリケーション・サーバ間で前記複数のタスクを配分することが、
各アプリケーション・サーバへＩＤ番号を割り当て、且つ各タスクへＩＤ番号を割り当てること、
各タスクに関して、前記履行予定タスクの前記各々のＩＤ番号に対する前記アプリケーション・サーバの合計数のモジュロを演算すること、及び
各アプリケーション・サーバへ、前記各々のアプリケーション・サーバの前記ＩＤ番号に一致する前記モジュロを生じるＩＤ番号を有する前記タスクを配分することからなる、請求項１７に記載の方法。
【請求項１９】
定期注文を処理するためのコンピュータ・システムであって、前記コンピュータ・システムが制御サーバ及び複数のアプリケーション・サーバからなり、各サーバが、プロセッサ、コンピュータ可読メモリ及び記憶メディア、及び入出力デバイスを有し、
選択製品の定期注文のために受信されたユーザー・リクエストに従って、定期注文を設定する複数のタスクの各々の実行時間を確定するための発注準備ユニット、
前記各々の履行予定実行時間及び前記選択製品の情報などのデータを含む前記複数のタスクを生成してデータベース内へ記憶するためのタスク生成ユニット、
前記複数のアプリケーション・サーバ間で、現在の受付周期内の履行予定タスクを配分するためのタスク配分ユニット、及び
前記製品を出荷するためのロジスティック命令を作成するために、履行予定タスクを実行するためのタスク実行ユニットを含む機能ユニットを有するようにプログラムされる前記コンピューティング・システム。
【請求項２０】
前記タスク配分ユニットが、さらに、
各アプリケーション・サーバへＩＤ番号にを割り当て、且つ各タスクへＩＤ番号を割り当て、
各タスクに関して、前記履行予定タスクの前記各々のＩＤ番号に対する前記アプリケーション・サーバの合計数のモジュロを演算し、
各アプリケーション・サーバへ、前記各々のアプリケーション・サーバの前記ＩＤ番号に一致する前記モジュロを生じるＩＤ番号を有する前記タスクを配分するようにプログラムされる、請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連特許出願
本出願は、参照により本文に全文が援用される２０１４年３月２４日に申請の、Ｃｈｉｎｅｓｅ  Ｐａｔｅｎｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｎｏ．２０１４１０１１１４９３．６、名称「定期注文の処理方法及びシステム」への外国優先権を主張する。
【０００２】
本出願は、電子商取引プラットホーム技術に関し、特に、顧客注文処理の方法及びシステムに関する。
【背景技術】
【０００３】
電子商取引プラットホームの改善ならびに従来の通信及び移動通信の急速な発展と共に、ますます多くの人々がウェブ上で買い物をするようになってきている。オンライン・ショッピングを通して入手可能な商品のタイプは、人々の日常生活のあらゆる局面に渡り、多くの便宜を提供している。
【０００４】
オンライン・ショッピング中、人々は、定期的な購入を行う必要がある場合もある。例えば、ミルク、米などの特定の消費品目は、定期的に毎月または毎週購入する必要があり得る。しかしながら、人々は、しばしば、これらの購入を忘れてしまう、あるいは、毎週または毎月の購入が非常に面倒と感じてしまう。したがって、そのようなオンライン・ショッピング・ニーズを満たす技術的解決策が必要である。
【発明の概要】
【０００５】
この概要は、「詳細な説明」において、下記に更に説明する簡略形態において、一連の概念を紹介するものである。この概要は、請求項の内容のすべての重要な特徴または必須の特徴を特定することを意図していない、あるいは請求項の内容の範囲を確定する支援として単独で用いられることを意図していない。
【０００６】
本開示の一つの態様は、電子商取引ユーザーが出す定期注文の処理方法である。選択製品の定期注文のために受信されたユーザー・リクエストに従って複数の発注タスクの実行時間を決定するために、サーバ・システムが用いられる。サーバ・システムは、周期タスクを発生させてデータベース内へ記憶する。アプリケーション・サーバは、データベースから、プリセット・タスク読み取り周期で、現在の読み取り周期に該当する実行時間を有する履行予定タスクを読み込み、製品を出荷するためのロジスティク命令を作成するために、その読み込んだ履行予定タスクを実行する。その結果、再発注の必要なく、ユーザーは、注文製品を指定時間に定期的に受け取ることになる。
【０００７】
複数のアプリケーション・サーバと協調して、サーバ・システム内の制御サーバによって履行予定タスクの配分が実行されてもよい。例えば、複数のアプリケーション・サーバ間で、各々のアプリケーション・サーバは、現在の受付周期にある履行予定タスクを配分するようにデザインされたアルゴリズムを使用するよう、制御サーバから命令を受信してもよい。命令及びアルゴリズムを使用して、各アプリケーション・サーバは、履行予定タスクのうちのどれをそのアプリケーション・サーバが読み込むべきかを判定する。
【０００８】
複数のアプリケーション・サーバ間での履行予定タスクの配分は、アプリケーション・サーバの各々にＩＤ番号を割り当てる、また、各履行予定タスクにＩＤ番号を割り当てること、各履行予定タスクに関して、履行予定タスクの各々のＩＤ番号に対するアプリケーション・サーバの合計数のモジュロを計算すること、及び、各アプリケーション・サーバへ、各々のアプリケーション・サーバのＩＤ番号に一致するモジュロの履行予定タスクを配分することによって行われてもよい。
【０００９】
この方法は、また、サーバ・ダウン時間をモニターし、存続アプリケーション・サーバ間で履行予定タスクを再配分する。
【００１０】
加えて、この方法は、また、タスク重複及びタスク脱漏を回避する。例えば、プリセット・タスク読み取り周期は、複数の読み取りスレッドを有し、各々が、異なるセットのタスク読み取り周期を含んでもよい。各読み取りスレッドのタスク読み取り周期の各セットは、均一に分割された時間間隔を有し、以前に逃したタスクを収集するために、段階的な、部分的に重なり合う複数のブラケットになるよう、一つのスレッドから次のスレッドへの間隔が長くなる。
【００１１】
本開示のもう一つの態様は、定期注文の処理のためのコンピュータ・システムである。このコンピュータ・システムは、制御サーバ及び複数のアプリケーション・サーバを有し、各サーバは、プロセッサ、コンピュータ可読メモリ、記憶メディア及び入出力デバイスを有する。コンピューティング・システムは、以下のような機能ユニットを有するようにプログラムされる。
【００１２】
発注準備ユニットは、選択製品の定期注文のために受信されたユーザー・リクエストに従って、複数の発注タスクの各々の実行時間を決定する。
【００１３】
タスク生成ユニットは、ユーザー・リクエストに記載された各々の履行予定実行時間及び製品情報などのデータを含む複数のタスクを生成し、データベース内へ記憶する。
【００１４】
タスク配分ユニットは、制御サーバを使用して、複数のアプリケーション・サーバ間で、現在の受付周期にある履行予定タスクを配分する。
【００１５】
タスク実行ユニットは、プリセット・タスク読み取り周期で、製品を出荷するためのロジスティク命令を作成するために、現在の読み取り周期に該当する実行時間を有する履行予定タスクを実行する。
【００１６】
本開示の他の特徴及び利点については、以下の説明に記載するが、他の特徴及び利点は、その説明から部分的に明らかになる、あるいは適用を実践することによって理解できる。本出願の目的及び他の利点は、特に特定、実現及び達成された構造の説明文、請求項及び図面から理解できる。
【図面の簡単な説明】
【００１７】
【図１】定期注文を処理するための実施例プロセスを表すブロック・フローチャートである。
【図２】定期注文を処理するための実施例システムの機能ブロックを示す概略図である。
【発明を実施するための形態】
【００１８】
本開示を、添付図面及び実施例実施形態と併せて、より詳細に説明する。説明文中の用語「技術」は、上記及び開示の全文を通して文脈が許容する限り、例えば、方法、装置デバイス、システム及び／またはコンピュータ可読命令に言及してもよい。
【００１９】
この説明文においては、プロセスを説明する順序が、限定として解釈されることを意図していない。この方法または代替方法を具現するために、複数の説明プロセス・ブロックが、どんな順序で組み合わされてもよい。実施形態は、解説の便宜のためにのみ、順次ステップで説明される。矛盾を生じない限り、本開示で説明する実施例及び実施形態、それらの特色及び特徴は、自由に組み合わされてもよい。さらに、実施形態での説明のすべてのステップが、この開示の技術の実践のために必要というわけではない。
【００２０】
本開示の実施形態は、ユーザーが特定製品を定期購入するための既存の電子商取引プラットホーム手段の上に提供される。開示の機能を利用することで、ユーザーは、選択製品を購入する一定期間（例えば、１年、または、より長い、あるいはより短い他の期間）に対しての支払いができる。支払われた期間中、定期注文の選択製品は、毎月または毎週などの、比較的短い周期で、繰り返し自動的に出荷されてもよい。これを行うために、技術的に電子商取引プラットホームは、早過ぎず遅過ぎず正しい時間に周期的出荷を行うロジスティックス・プロセスを管理する必要がある。在庫及び輸送は、正確にタイミングを図る必要がある。電子商取引プラットホームから定期注文リクエストを受信すると即座に、Ｎロジスティク命令が作成されてもよい。各ロジスティク命令は、在庫及び輸送がロジスティク命令に従って適時に準備されるよう実行される特定時間を有する。
【００２１】
定期注文が適時に実行されるために、データベースから、実行必須のタスクを周期的に（例えば、５分、３０分、１時間または１日など毎に）読み込むよう、タスク・スケジュール管理システムが使用される。読み込んだタスクは、定期注文を発生させるために実行され、それら定期注文が、在庫及び輸送を準備するためのロジスティック・システムへ送信される。このプロセスを、以下に詳細に説明する。
【００２２】
図１は、定期注文を処理するための実施例プロセスを表すブロック・フローチャートである。
【００２３】
ブロックＳ１０１で、システムは、選択製品の定期注文のためのユーザー・リクエストに従って、発注のための一連のタスクの実行時間を確定する。
【００２４】
実際には、ユーザーが定期注文のリクエストを提出するためのユーザー・インターフェイスが提供される。ユーザーは、ユーザー・インターフェイスを使用して、注文すべき製品を選択し、定期注文の合計数（例えば、各注文が順次周期に対応する六個の注文または十二個の注文）、各反復周期の長さ（例えば、週につき、または月につき一つの注文）、及び注文につき出荷される製品の数量を指定する。ユーザーは、各月の第一日など、指定発送時間を選択してもよい。リクエストを提出すると、ユーザーは、その後、これらの定期注文を手作業で行うことなく、定期注文の選択製品を受け取ることになる。
【００２５】
ユーザーが提出したリクエストを受信すると、システムは、リクエストに記載された出荷情報に従って、各定期注文に対する在庫時間を確定する。出荷情報が要求定期注文の発送時間を指定している場合、システムは、指定発送時間に応じて在庫時間を確定してもよい。例えば、指定発送時間が毎月２５日であれば、在庫時間は、１日の在庫準備を設け、毎月２４日と確定してもよい。システムは、在庫時間を、定期注文に対する発注タスクの実行時間とみなしてもよい。
【００２６】
ブロックＳ１０２で、システムは、ユーザー・リクエストに記載された各々の実行時間及び製品情報などのデータを含むタスクを生成しデータベース内へ記憶する。
【００２７】
定期注文に対する発注タスクの実行時間を確定すると即座に、システムは、対応タスクを生成し、それらタスクをデータベース内に記憶してもよい。例えば、ユーザーが製品について十二個の定期注文を要求した場合は、システムは、要求された十二個の定期注文に対する１２の発注タスクを生成し、それらタスクをデータベース内へ記憶することになる。各々のタスクは、それの実行時間と、製品ＩＤ、モデル及び品質などの注文製品情報を有する。タスクは、注文の受取人を指定するユーザー情報を含んでもよい。このように、定期注文のためのリクエストは、実行すべき複数のタスクへ分割される。一つの実施形態において、タスクは、表１に示すようなテーブルとしてデータベース内に記憶される。
【００２８】
【表１】
2017510886.tif 000003
【００２９】
電子商取引プラットホームでは、定期注文を出すユーザーの数が非常に大きく、その結果、タスクに対する大量のデータが生成される可能性があることに留意する必要がある。データのバックエンド読み取りの便宜のために、タスクは複数のテーブル内に記憶されてもよい。例えば、タスクは、タスクの実行時間に応じて、複数のテーブルへ分けてもよい。同じ日に実行時間を有するすべてのタスクは、同じテーブル内に配置され、それに応じて記憶されてもよい。テーブルは、更に細かなデータ塊へ分割されてもよい。例えば、日毎のタスクは、各テーブルが１時間以内のタスクに対するデータを含んで２４のテーブルへ分割されてもよい。これは、データベース内に記憶されたテーブルのサイズを減少させ、バックエンド読み取りの効率を向上させる可能性がある。この実践では、同じユーザーが要求した定期注文に対して生成されたタスクが、異なるテーブル内へ配置されてもよい。
【００３０】
ブロックＳ１０３で、システムは、プリセット・タスク読み取り周期でデータベースから、現在の読み取り周期に該当する実行時間を有するタスクを読み込む。
【００３１】
一つの実施形態において、システムは、データベースからタスクを読み込む複数のアプリケーション・サーバを有する。アプリケーション・サーバは、現在の読み取り周期内で履行予定の実行時間を有するタスクを読み込むよう、予め構成されている。例えば、アプリケーション・サーバは、タスクを５分毎に読み取ってもよく、毎回、現５分周期内の実行時間を有するすべてのタスクを読み込んでもよい。
【００３２】
ブロックＳ１０４で、システムは、各々のタスクに従って製品を出荷するためのロジスティック命令を作成するために、ブロックＳ１０３で読み込んだタスクを実行する。
【００３３】
タスクが読み込まれたら、タスクに含まれる製品情報及びユーザー情報に基づいて、ロジスティク命令が作成される。倉庫が出荷のための在庫を準備できるように、ロジスティク命令の通知が倉庫システムへ送信されてもよい。
【００３４】
プロシージャは、データベース内のすべてのタスクが予定の時間に実行されることを確実にし、ユーザーは、毎月または毎週発注する必要なく、注文製品を要求時間に受け取ることができる。
【００３５】
倉庫システムへ通知を送信するためには、予め倉庫の呼出しインターフェイスが取得される。それによって、ロジスティク命令が作成されると、倉庫システム・インターフェイスが呼び出され、在庫保有及び在庫準備のために倉庫システムへ、注文の製品ＩＤ、製品仕様及び製品品質などの注文情報が送信されてもよい。加えて、注文製品の受取人の住所などの出荷情報が確定され、在庫確保後の妥当な出荷を準備するために、倉庫システムへ送信されてもよい。
【００３６】
タスク数が過度に大きくなければ、単一のアプリケーション・サーバでも十分である。しかし、タスク数が大きい場合は、これらの時限周期タスクを実行するために、一群のアプリケーション・サーバ（例えば、図２に示す複数のアプリケーション・サーバ２２０）が使用されてもよい。このシナリオにおいて、システムは、複数のアプリケーション・サーバへ制御命令を送信するための制御サーバ（例えば、図２に示す制御サーバ２１０）を含んでもよい。
【００３７】
アプリケーション・サーバ間でタスクを配分するために、システムは、各アプリケーション・サーバが受信可能な履行予定タスクのアイデンティティを判定する必要がある。一つの実施形態においては、各アプリケーション・サーバは、各々のアプリケーション・サーバが受信可能な履行予定タスクのアイデンティティを判定するための、所定構成のアルゴリズムを使用する。このアルゴリズムは、利用可能なアプリケーション・サーバ間で、現在の読み取り周期において、タスクを均一に配分するように最適化されることが好ましい。アプリケーション・サーバは、タスク読み取り周期を合わせるために、共用クロックを使用してもよい。
【００３８】
例えば、実際に、タスクを均一に配分するために、ハッシュアルゴリズムを使用してもよい。制御サーバは、システム内で利用可能なアプリケーション・サーバの各々へサーバＩＤを割り当て、制御命令をアプリケーション・サーバへ送信する際に、制御サーバは、制御命令内に、システム内で利用可能なアプリケーション・サーバの合計数、及び、制御命令を受信するアプリケーション・サーバのサーバＩＤ等の情報を含ませる。例えば、アプリケーション・サーバの合計数が１０で、アプリケーション・サーバＡがサーバＩＤ０を割り当てられる場合、制御サーバがアプリケーション・サーバＡへ送信する制御命令は、サーバの合計数が１０であること、及び、アプリケーション・サーバＡに対して割り当てられたＩＤ番号が０であることを示すようなデータを含む。
【００３９】
正しいタスクをデータベースから受信するために、アプリケーション・サーバは、二つの局面での判定を行ってもよい。第一に、受信される各タスクの実行時間が、現在の読み取り周期内に該当する必要がある。第二に、受信される各タスクのＩＤ番号が、アルゴリズムによって定義されたルールを満たす必要がある。
【００４０】
一つの実施形態において、システムは、アプリケーション・サーバの各々へＩＤ番号を割り当て、且つ各履行予定タスクへもＩＤ番号を割り当てる。システムは、各タスクに関して、タスクの各々のＩＤ番号に対するアプリケーション・サーバの合計数のモジュロを計算する。詳しくは、システムは、アプリケーション・サーバの合計数を該当タスクのＩＤ番号で除算した剰余を計算する。アプリケーション・サーバの合計数は、システム全体で一定であるため、計算されたモジュロは、モジュロの計算に使用されるＩＤ番号を有するタスクの特徴マークを代表する。システムは、それから、各アプリケーション・サーバへ、各々のアプリケーション・サーバのＩＤ番号に一致するモジュロを有するタスクを配分する。モジュロ演算は、アプリケーション・サーバによって行われてもよい。例えば、各アプリケーション・サーバは、各タスクのＩＤ番号に対するアプリケーション・サーバの合計数のモジュロを計算し、アプリケーション・サーバのＩＤ番号に一致するモジュロを生じるタスクを選択して読み込む。
【００４１】
例えば、読み取り周期が５分であるとすれば、アプリケーション・サーバＡが、１１時５５分の時点において、現在の読み取り周期で履行予定必須タスクを読み込むとき、アプリケーション・サーバＡは、最初に、タスクが１１時５０分〜１１時５５分に該当する実行時間を有するかどうかを判定し、是である場合、さらに、タスクのＩＤ番号に対して計算されたアプリケーション・サーバの合計数のモジュロが、アプリケーション・サーバＡのＩＤ番号に一致するかどうかを判定する。肯定であれば、アプリケーション・サーバＡは、そのタスクを読み込むが、否定であれば、アプリケーション・サーバＡはタスクを読み込まない。この技術を使用することで、同じ読み取り周期内のタスクは、実行されるための利用可能なアプリケーション・サーバへ均一に配分されるため、いくつかのサーバがオーバーロードになっているのに他のサーバがロード不足であるという状況は回避される。例えば、各々、ＩＤ番号０、１、２、３、４、５、６、７、８及び９の、十個のアプリケーション・サーバがある場合、ＩＤ番号０のアプリケーション・サーバは、タスクを読み込むのに、以下の条件が満たされることを要求する。タスクのＩＤ番号に対する１０のモジュロが０であること（つまり、０であるアプリケーション・サーバのＩＤ番号と一致すること）。同様に、ＩＤ番号１のアプリケーション・サーバは、タスクを読み込むのに、以下の条件が満たされることを必要とする。タスクのＩＤ番号に対する１０のモジュロが１であること（つまり、１であるアプリケーション・サーバのＩＤ番号と一致すること）、等々。すべてのタスクは、アプリケーション・サーバ間で、このように均一に配分される。
【００４２】
モジュロ演算は、択一的に、制御サーバによって行われてもよい。その場合、制御サーバが、正しいタスクを正しいアプリケーション・サーバへ渡す。
【００４３】
実際には、アプリケーション・サーバは、ダウンタイムに遭遇することもある、あるいは、いくつかのタスクは、うまく読み込まれるが、種々の理由により、うまく実行されないこともあり得る。このことは、特定のタスクが実行されない、という結果に至ってしまう。本開示は、そのような課題を解決するための技術を提供する。
【００４４】
一つの実施形態において、プリセット・タスク読み取り周期は、各々が異なるセットのタスク読み取り周期を含む複数の読み取りスレッドを有する。各読み取りスレッドのタスク読み取り周期のセットは、均一に分割された時間間隔を有してもよい。異なるタスク読み取りスレッドは、異なる長さの間隔を有してもよい。例えば、一つのスレッドから次のスレッドへ間隔が増加してもよい。
【００４５】
例えば、一つの読み取りスレッドが、５分の読み取り周期、もう一つが、２０分の読み取り周期、もう一つが、１時間の読み取り周期、もう一つが一日、さらにもう一つが２日、等を有してもよい。概して、各アプリケーション・サーバは、限られた数のスレッドを持つべきである。通常、すべての読み取りスレッドが適用された後にすべてのタスクが拾われていることを保証するのに、読み取り周期の最大長が２日を超える必要はないであろう。
【００４６】
各読み取りスレッドは、それ自身の周期スケジュールに従って、データベースからタスクを読み込む。例えば、５分の読み取り周期を有するスレッドは、５分毎に１回、データベース内のタスクを読み取り、また、２０分の読み取り周期を有するスレッドは、２０分毎に１回、データベース内のタスクを読み取る。同じアプリケーション・サーバのすべてのスレッドが読み取るタスクのアイデンティティは、アプリケーション・サーバの合計数と同じアプリケーション・サーバのＩＤ番号によって決定されるため、同じアプリケーション・サーバのすべてのスレッドは、データベース内のタスクを選択する同じルールを使用する。これにより、一つのタスクが、同じアプリケーション・サーバの異なる読み取りスレッドによって、複数回読み取られることになる。
【００４７】
例えば、アプリケーション・サーバＡのＩＤ番号が０であり、且つ５分の読み取り周期の読み取りスレッド１を有し、１１時５０分〜１１時５５分の履行予定必須タスク中の１０タスクを読み込む。この場合、１０個の読み込んだタスクのＩＤ番号は、すべて、アプリケーション・サーバの合計数である数１０に対してモジュロ０を生じることになる（つまり、１０を１０の読み込んだタスクのいずれのＩＤ番号で除算しても、アプリケーション・サーバＡのＩＤ番号０と一致する剰余０を有することになる）。アプリケーション・サーバＡは、また、２０分の読み取り周期の読み取りスレッド２を有し、１１時４０分〜１２時００分の履行予定必須タスク中のタスクを読み込む。この場合、これら読み込んだタスクのＩＤ番号も、数１０に対してモジュロ０を生じることになる。その結果、読み取りスレッド２は、読み取りスレッド１によっても読み取られるタスクのいくつかを読み取る可能性があり、このことは問題を引き起こす恐れがある。
【００４８】
同じタスクが繰り返し実行されることを避けるために、既に実行されたタスクは、以降の読み取りスレッドが実行済み履行予定タスクを再び読み込むことを避けるために、完了済みとマークされる。このデザインにより、同じアプリケーション・サーバの以降の読み取りスレッドは、まだ完了済みとマークされていないタスクのみを読み取るため、以降の読み取りスレッドによって同じタスクが再度読み込まれることは回避される。
【００４９】
もう一つのあり得るシナリオは、特定のタスクが、読み取りスレッド１に読み込まれた後にまだ実行されずに、以降の読み取りスレッド２によって読み込まれてしまう可能性である。これは、そのタスクが究極的にスレッド１によって実行された場合、タスクのスレッド１による実行の前の時点で完了済みとマークされていない同じタスクがスレッド２によって読み込まれて再度実行されるかもしれないため、問題を生じる可能性がある。このシナリオにおいては、そのタスクが複数回実行されることを回避するために、同じアプリケーション・サーバの読み取りスレッドによって読み込んだすべてのタスクは、まず、複合タスク実行キューへ書き込み、タスクのすべての重複が、複合タスク実行キュー内に含まれないよう取り除いてもよい。読み取りスレッドは、それから、複合タスク実行キューから実行すべきタスクを読み取る。
【００５０】
もう一つのあり得るシナリオは、すべての読み取りスレッドが全タスクを読み取って実行した後に、あるタスクが読み込まれても実行されないで残ることである。例えば、タスクが、２月１７日１１時５２分の実行時間を有するとする。そのタスクが、５分の読み取り周期を有するスレッドによって、最初に２月１７日１１時５５分に読み込まれたが、うまく実行されず、そのため、完了とマークされなかった。同じタスクが、それから、２０分の読み取り周期を有するスレッドによって、再び１２時００分に読み込まれたが、再度うまく実行されなかった。その後、同じスレッドは、一日の読み取り周期を有するスレッドによって、三度目の２月１８日０時００分に読み込まれてもよい。それでも実行されないなら、そのタスクは、２日の読み取り周期を有するスレッドによって、四度目の２月１９日０時００分に読み込まれてもよい。この時点で、すべての読み取りスレッドが実行されて、もはや読み取りスレッドは残っていないため、そのタスクが再度読み取られることはない。その時点で実行されていない場合、タスクは、例外キューから実行されるよう、例外キュー内へ書き込まれる。
【００５１】
タスクが例外キューの実行後でさえも実行されずに残る場合、他のシステム問題に起因する故障の可能性があるため、管理手段を用いてタスクが処理できるよう、管理者へ通知が送信されてもよい。加えて、例外キューに含むことができるタスクの合計数に対して、最大数を設定してもよい。これにより、例外キューが最大数を超過した場合に管理者に対して警告を発することが可能である。
【００５２】
同じアプリケーション・サーバに複数の読み取りスレッドを使用することによって、たとえ一つのアプリケーション・サーバがダウンしていても、全タスクが読み込まれて実行されることを保証できる。これを行うために、システムは、アプリケーション・サーバをモニターし、未だに利用可能でダウンタイムにないアプリケーション・サーバ間で、現在の受付周期内の全タスクを配分することができる。一つの実施形態においては、一つ以上のアプリケーション・サーバのダウンタイムが検出された場合、システムは、存続するアプリケーション・サーバへ、異なるＩＤ番号を割り当て、存続アプリケーション・サーバへ、履行予定タスクを読み取るための命令を再送信する。これは、タスクが、存続アプリケーション・サーバ間で再配分されることを可能とする。例えば、ＩＤ番号７のアプリケーション・サーバがダウンしている場合、存続サーバへのＩＤ番号の再割り当て後、元々のＩＤ番号８及び９のアプリケーション・サーバには新しいＩＤ番号７及び８が割り当てられ、存続アプリケーション・サーバの合計数は９になる。新しい命令を受信すると、存続アプリケーション・サーバは、未だに同じ読み取りスレッド及び同じクロックを有するが、サーバのＩＤ番号の変更により異なるモジュロ合致に至るであろう、今度は、異なるタスクを読み取ることになる。
【００５３】
例えば、１１時５５分に、アプリケーション・サーバＡのスレッド１は、１１時５０分〜１１時５５分の実行時間を有するタスク間の１０個のタスクを読み取る。アプリケーション・サーバＡは、それらタスクのいくつかを実行し、いくつかを実行しないまま、１１時５７分にダウンしてしまう。他のアプリケーション・サーバは利用可能なので、制御サーバは、存続アプリケーション・サーバへＩＤ番号を再設定し、制御命令を再送信する。例えば、アプリケーション・サーバＢは、５分の読み取り周期のスレッド１を有し、最新読み取りが１１時５５分に発生している。再送信制御命令の受信後、アプリケーション・サーバＢは、１１時５５分〜１２時００分の実行時間を有するタスクを読み込むために、１２時００分に次の読み取りを実行することになる。アプリケーション・サーバＡによって読み込まれたが未だに実行されていないタスクは、２０分以上の読み取り周期を有するスレッドによって、再度読み取られてもよい。例えば、２０分の読み取り周期を有するもう一つのスレッドは、その最新読み取りが１１時４０分であり、新しい制御命令を受信すると、１１時４０分〜１２時００分の実行時間を有し完了済みとマークされていないタスクを読み込むために、１２時００分に次の読み取りを実行することになる。これらのタスクは、１１時５０分〜１１時５５分に履行予定すべきとして以前にアプリケーション・サーバＡによって読み込まれたが未だに実行されていないタスクを含んでもよい。利用可能なアプリケーション・サーバの合計数が変わったため、データベース内のタスクは、存続アプリケーション・サーバ間で再配分され、異なるアプリケーション・サーバによって読み込まれる。未実行タスクを受け取った新しいサーバがダウンしない限り、これらのタスクは実行されることになる。
【００５４】
要約すると、ここに開示の技術は、多くのタスクがある場合に、履行予定すべきタスクが未実行のまま残される、あるいは重複実行されることがないことを保証する。この技術は、システムの拡大縮小にも適切である。タスク数の急激な増加がある場合、サーバ間での均等なタスク負荷を保証するのに、より多くのアプリケーション・サーバを追加すればよい。新しいアプリケーション・サーバが追加されると、タスクが利用可能なアプリケーション・サーバ間で均一に配分されることを保証するために、制御サーバは、利用可能なアプリケーション・サーバへサーバＩＤ番号を再設定し、利用可能なアプリケーション・サーバへ制御命令を再送信してもよい。新しいアプリケーション・サーバを追加することに加えて、既存のアプリケーション・サーバへ新しい読み取りスレッドを追加することによって、システムのタスク読み取り能力を向上させてもよい。このシナリオにおいて、制御サーバは、制御命令を再送する必要はない。システムに必要なことは、新しい読み取りスレッドの読み取り周期を設定し、新しい読み取りスレッドを始動させるだけである。
【００５５】
ここに開示の方法に関連して、本開示は、また、本文で説明の方法を具現するためのサーバ・システムを提供する。
【００５６】
上記の技術は、コンピュータ実行可能命令を含む一つ以上の非一時的コンピュータ可読媒体の支援により具現されてもよい。非一時的コンピュータ実行可能命令は、コンピュータ・プロセッサが、本文で説明の技術による機能を実行することを可能にする。コンピュータ可読媒体は、コンピュータ・データを記憶するための適切なメモリ・デバイスのいずれであってもよい、と認識される。そのようなメモリ・デバイスは、限定せずに、ハードディスク、フラッシュ・メモリ・デバイス、光学的データ記憶装置及びフロッピーディスクを含む。さらに、コンピュータ実行可能命令を含むコンピュータ可読媒体は、ローカル・システム内の構成要素、または、ネットワークを介して配分された複数のリモート・システムの構成要素からなってもよい。コンピュータ実行可能命令のデータは、有形物理メモリ・デバイスとして供給されても、あるいは電子的に送信されてもよい。
【００５７】
本開示において、概して「ユニット」または「モジュール」は、特定のタスクまたは機能を実行するようにデザインされた機能性へ言及する。モジュールまたはユニットは、特定のタスクまたは機能に関連する目的を達成するためのハードウェア、ソフトウェア、プランまたはスキーム、あるいはそれらの組み合わせであってもよい。加えて、別個のモジュールまたはユニットの線引きは、物理的に別個のデバイスが使用されることを、必ずしも示唆するものではない。そのかわり、その線引きが機能なものであってもよく、その場合、複数のモジュールまたはユニットの機能は、単一の複合デバイスまたは構成要素によって実行されてもよい。コンピュータに基づくシステム内で使用される場合は、プロセッサ、記憶装置及びメモリ等の正規のコンピュータ構成要素が、種々各々の機能を実行するために、一つ以上のモジュールまたはユニットとして機能するようにプログラムされてもよい。
【００５８】
図２は、定期注文を処理するための実施例サーバ・システムを表す機能ブロックの概略図である。サーバ・システム２００は、制御サーバ２１０及びアプリケーション・サーバ２２０を含む。サーバは、各々、一つ以上のプロセッサ、入出力デバイス、アプリケーション・プログラムを記憶するコンピュータ可読メモリ及び記憶メディアを有してもよい。サーバ・システム２００は、以下の機能ユニットを有するようにプログラムされる。
【００５９】
発注準備ユニット２０１は、選択製品の定期注文のために受信されたユーザー・リクエストに従って、複数の発注タスクの各々の実行時間を確定するようにプログラムされる。
【００６０】
タスク生成ユニット２０２は、ユーザー・リクエストに記載された各々の実行時間及び製品情報などのデータを含む複数のタスクを生成してデータベース内へ記憶するようにプログラムされる。
【００６１】
タスク配分ユニット２０３は、複数のアプリケーション・サーバ間で、現在の受付周期内の履行予定タスクを配分するようにプログラムされる。
【００６２】
タスク実行ユニット２０４は、製品を出荷するためのロジスティック命令を作成するために、プリセット・タスク読み取り周期で、現在の読み取り周期内に該当する実行時間を有するタスクを実行するようにプログラムされる。
【００６３】
実際には、多数のタスクを処理するために、複数のアプリケーション・サーバ２２０が配分構成で使用される。一つの実施形態において、タスク配分ユニット２０３は、アプリケーション・サーバ上に各々具現された複数のサブユニットを含み、アプリケーション・サーバは、各々のアプリケーション・サーバで読み取り可能なタスクのアイデンティティを判定するために、制御サーバ２１０から受信された制御命令及び所定構成のアルゴリズムを使用する。アルゴリズムは、利用可能なアプリケーション・サーバ２２０間で、現在の読み取り周期内で履行予定すべきタスクを均一に配分するように設計される。
【００６４】
たとえアプリケーション・サーバ２２０のいくつかがダウンしていてもタスクが実行されることを保証するために、制御サーバ２１０は、アプリケーション・サーバ２２０の作動状態をモニターし、一つ以上のアプリケーション・サーバ２２０がダウンしている場合には、利用可能なアプリケーション・サーバ２２０へ制御命令を再送信する。
【００６５】
実際には、制御サーバ２１０は、利用可能なアプリケーション・サーバ２２０へサーバＩＤ番号を割り当て、各々のアプリケーション・サーバ２２０へ送信される命令内にサーバＩＤ番号を含ませる。各アプリケーション・サーバ２２０は、各々のアプリケーション・サーバ２２０によって読み取り可能なタスクのアイデンティティを確定するために、以下のモジュール（図示せず）を有するようにプログラムされる。
【００６６】
モジュロ演算ユニットは、履行予定すべき各タスクのＩＤ番号に対する、利用可能なアプリケーション・サーバの合計数のモジュロを演算するようにプログラムされる。
【００６７】
アイデンティティ判定ユニットは、各タスクのＩＤ番号を用いて演算されたモジュロをアプリケーション・サーバのＩＤ番号に合致させることによって、アプリケーション・サーバによって読み取り可能なタスクのアイデンティティを確定するようにプログラムされる。
【００６８】
図１に関して本文で説明したように、各アプリケーション・サーバは、読み取りスレッドによって定義された現在の読み取り周期内で履行予定必須のタスクを、データベースから各々が読み込む複数の読み取りスレッドを有してもよい。異なる読み取りスレッドは、ピックアップされる複数の機会をタスクが有することを保証するために、重なり合う異なる読み取り周期を有する。
【００６９】
タスク配分ユニット２０３は、さらに、各アプリケーション・サーバへＩＤ番号を割り当て、且つ各履行予定タスクへＩＤ番号を割り当て、及び各履行予定タスクに関して、履行予定タスクの各々のＩＤ番号に対するアプリケーション・サーバの合計数のモジュロを演算する、及び、各アプリケーション・サーバへ、各々のアプリケーション・サーバのＩＤ番号に一致するモジュロを有するタスクを配分するようにプログラムされてもよい。
【００７０】
システムは、タスクが実行された後にタスクを完了とマークするためのタスク標識ユニット等の、他の機能ユニットを含んでもよい。
【００７１】
各アプリケーション・サーバ２２０は、少なくとも一つの読み取りスレッドを有してもよく、同じアプリケーション・サーバは、さらに、異なる複数の読み取りスレッドによって読み込まれたすべてのタスクを複合実行キューとして書き取るようにプログラムされた実行キュー書き込みユニットを有する。
【００７２】
一つのタスクが複数回実行されることを回避するために、システムは、図１に関して説明したように、同じ実行キュー内のタスクの重複を取り除く、すべての読み取りスレッドが実行された後にタスクが実行されていない場合に例外キュー内へそのタスクを書き込む、及び、倉庫システムへの既知のインターフェイスを呼び出すことによってロジスティク命令を倉庫システムへ送信する等の、他の処理を実行するようにプログラムされたユニットを含んでもよい。
【００７３】
上記の方法及びシステムを使用することで、ユーザーによる要求の定期注文に対応するタスクが、作成され、記憶され、読み取られ、管理される。この場合、複数のタスク読み取りスレッドを実行する配分型アプリケーション・サーバ・システムを使用することによって、時宜を得て信頼可能なタスクの実行が保証できる。実行の際に、これらのタスクは、ユーザーが要求したように正しい時間に正しい数量で製品が自動的に出荷されることを保証し、ユーザーにそのような定期注文を手作業で発注させることを要求しない。
【００７４】
典型的な構成においては、コンピュータ・メモリは、揮発性メモリ、ランダム・アクセス・メモリ（ＲＡＭ）等のコンピュータ可読媒体、及び／または、読み取り専用メモリ（ＲＯＭ）またはフラッシュメモリ（フラッシュＲＡＭ））等の不揮発性メモリの他の形態を含んでもよい。コンピューティング・デバイスの内蔵メモリは、一種のコンピュータ可読記憶媒体である。
【００７５】
コンピュータ可読媒体は、永久不変及び非永久不変、リムーバブル及び非リムーバブル・メディアを含み、情報の記憶のためのどんな方法または技術で形成されてもよい。記憶される情報は、一セットのコンピュータ可読命令、データ構造、プログラム・モジュールまたは他のデータであってもよい。コンピュータ記憶媒体の実施例は、相変化メモリ（ＰＲＡＭ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、他のタイプのランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気的消去可能プログラム可能な読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他の記憶装置技術、ＣＤ-ＲＯＭ読み出し専用メモリ（ＣＤ-ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）または他の光記憶装置、磁気カセット、磁気テープ・ディスク記憶装置または他の磁気記憶デバイス、あるいはコンピューティング・デバイスによってアクセス可能な、情報記憶に使用可能な他の非透過媒体を含むが、これらに限定されるものではない。本開示の定義によれば、コンピュータ可読媒体は、変調データ信号及び搬送波などの、一時的なコンピュータ可読媒体（一過性の媒体）を含まない。
【００７６】
特に、モジュールまたはユニットは、機械実行可能なコマンド及びコードに基づくコンピュータプログラムを用いて具現されてもよい。概して、コンピュータプログラムは、特定のタスクを実行してもよい、あるいは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などの、特定の抽象データ・タイプを具現してもよい。本開示で説明の技術は、通信ネットワークを介して結合された複数の遠隔処理デバイスによってタスクを実行するための、配分コンピューティング環境などの、配分コンピューティング環境内で実践することもできる。配分コンピューティング環境下では、プログラムされたモジュールまたはユニットは、メモリ・デバイスを含むローカルまたは遠隔のコンピュータ記憶媒体内に配置されてもよい。
【００７７】
本明細書の種々の実施形態は、実施例及び環境と共に、次第に詳細を増して説明されている。各実施形態は、開示の特定の態様に焦点を絞っているため、異なる実施形態は、相互に異なっているが、類似の部分も共有している。
【００７８】
例示的実施形態は、この開示において、本発明の概念及び具現化を説明するために採用している。例示的実施形態は、本開示の方法及びコア概念のより良い理解のためにのみ用いられる。この開示の概念に基づき、当業者は、例示的実施形態及び適用分野を修正してもよい。
【図１】
2017510886.tif 000004
【図２】
2017510886.tif 000005
【国際調査報告】
2017510886.tif 000006