JP2019512143A - データ処理方法及び装置 - Google Patents

Abstract

本開示の実施はデータ処理方法及びデバイスを提供する。本開示の実施では、既存の技術における格納構造を取り入れていない。先ず、空フィールドがないので、空フィールドのために格納スペースが無駄になってしまうという問題は回避され、格納スペース節約の目的が達成される。加えて、既存の技術では、各フィールドに格納される属性は１つだけである。しかし、本開示の実施では、１つの属性フィールドに複数の属性対応が格納され、各属性対応は属性値を含む。そのため、既存の技術と比較して、本開示の実施では、１つの属性格納フィールド内に複数の属性値を格納し、属性格納フィールド内の格納スペースが十分に利用されることで、格納スペースの節約となる。

Description

本願は、インターネット技術の分野に関し、特に、データ処理方法及び装置に関する。

インターネット技術の急速な発展に伴い、人々はますますインターネット上で様々な便利なサービスを楽しむ傾向にある。サービスプロバイダにとって、特定の分野において的確なサービスをどのようにしてユーザに提供するかが、ユーザの認知を得る上で重要な要素である。ユーザの個々のニーズを満たし、的確なサービスをユーザに提供するためには、ユーザの個人属性に従ってユーザに的確なサービスを提供できるように、ユーザの個人属性を収集してこれを格納しておく必要がある。

個人属性は、ユーザの行動習慣、趣味趣向、カスタマイズ要件等のいくつかを含む。個人属性として、例えば、ユーザが望む決済方法、ユーザが望む決済アカウント番号、ユーザの興味のある製品のカテゴリ、ユーザが頻繁に訪れるネット店舗、及びユーザ自身のデフォルトのログインアカウント番号が挙げられる。

ユーザの個人属性は、個人属性の属性名と個人属性の属性値とを含む。例えば、ユーザの個人属性の属性名は「デフォルトの決済方法」であり、属性値は「オンライン決済」である。また、別の例では、ユーザの別の個人属性の属性名は「興味ある製品のカテゴリ」であり、属性値は「デジタル家電」である。

現在、既存の技術では、ユーザの個人属性は下記の表１に示す方法で格納されることが一般的である。表１の左端の列（ｃｏｌｕｍｎ）の各フィールドには各ユーザ（例えば、それぞれユーザＡからユーザＭ）のＩＤ（ ）が格納され；表１の最上の行（ｒｏｗ）の各フィールドには、技術者により事前に収集された各個人属性の属性名、例えば属性名１から属性名Ｎ、がそれぞれ格納される。表１には、合計で（Ｍ＋１）＊（Ｎ＋１）フィールドが含まれる。

或るユーザの個人属性の属性値を表１に格納する必要がある場合、ユーザのユーザＩＤが位置する行と、個人属性の属性名が位置する列とを表１で検索する。次に、見つかった行と見つかった列の両方に位置するフィールドを特定し、このフィールドに個人属性の属性値を入力する。

表１で、ユーザＩＤが位置する行と属性名が位置する列とにおけるフィールドが空フィールドである場合、ユーザＩＤに対応するユーザが、属性名に対応する個人属性を持っていないことを示す。

このアプリケーションを実施する工程において、本発明者は、関連技術の解決策には少なくとも以下の欠点があることに気付いた。

技術者により事前に収集される個人属性は様々であるため、表１の第１の行には多数（複数）のフィールドが含まれることになり、異なるユーザ間での個人属性は時には大きく異なり、一致も少なく、又、事前に技術者により収集された全ての個人属性において各ユーザの個人属性が占める割合はほんの一部に過ぎない。その結果、ユーザＩＤに対応する行内における少数のフィールドのみに属性値が入力され、その他のフィールドは全て空フィールドとなる。そのため、表１の多くは空フィールドとなり、又、一定量の格納スペースが空フィールドによって占められることで、格納スペースの膨大な容量が表１内の多数（複数）の空フィールドによって埋められることになる。

関連技術における問題を軽減するために、本開示はデータ処理方法及びデバイスを提供する。

本開示の第１の実施の形態により、データ処理方法が提供され、前記方法は以下を含む：ユーザ識別子に加えて前記ユーザ識別子に対応する少なくとも１つの個人属性の属性識別子及び属性値を取得するステップ；各々の前記個人属性について、前記個人属性の前記属性識別子及び前記属性値に基づき、前記個人属性の対象属性対応を生成するステップ；ユーザ識別子と属性格納フィールドとの間の格納された第１の対応内に前記ユーザ識別子に対応する対象属性格納フィールドが存在するかどうかを特定するステップ；前記第１の対応内に前記ユーザ識別子に対応する前記対象属性格納フィールドが存在する場合に、前記対象属性格納フィールド内に全ての前記対象属性対応を格納するステップ；又は、前記第１の対応内に前記ユーザ識別子に対応する前記対象属性格納フィールドが存在しない場合に、前記ユーザ識別子に対応する属性格納フィールドを作成し、前記作成された属性格納フィールド内に全ての前記対象属性対応を格納するステップ。

個人属性の属性識別子及び属性値に基づき、個人属性の対象属性対応を生成する前記ステップは以下を含む：
前記個人属性の前記属性識別子と前記個人属性の前記属性値との間に対象属性対応を確立するステップ；又は、
属性識別子とシーケンスインデックスのインデックス識別子との間の格納された第２の対応を取得するステップと、前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するステップと、前記インデックス識別子と前記個人属性の前記属性値との間に対象属性対応を確立するステップ。

対象属性格納フィールドに全ての対象属性対応を格納する前記ステップは以下を含む：
全ての前記対象属性対応により占められる格納スペースが、前記対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しいかどうかを特定するステップ；
全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも小さい又はこれと等しい場合に、前記対象属性格納フィールドに全ての前記対象属性対応を格納するステップ；又は
全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも大きい場合に、前記ユーザ識別子に対応する少なくとも１つの新たな属性格納フィールドを作成するステップと、前記新たな属性格納フィールドに、又は、前記対象属性格納フィールド及び前記新たな属性格納フィールドに、全ての前記対象属性対応を格納するステップ。

前記対象属性格納フィールドに全ての前記対象属性対応を格納する前記ステップは以下を含む：前記対象属性格納フィールド内で前記対象属性対応が格納される場所を、前記対象属性対応内の前記インデックス識別子と、前記対象属性格納フィールドに格納された全ての前記属性対応内のインデックス識別子とに基づいて特定するステップ；前記特定された場所に前記対象属性対応を格納するステップ。

本開示の第２の実施の形態により、データ処理方法が提供され、前記方法は以下を含む：ユーザ識別子と個人属性の属性識別子とを含む取得要求を取得するときに、ユーザ識別子と属性格納フィールドとの間の前記第１の対応を検索するステップであって、第１の対応内に前記ユーザ識別子に対応する属性格納フィールドが存在するかどうかを特定する、前記検索するステップ；前記ユーザ識別子に対応する前記属性格納フィールドが存在する場合に、前記属性格納フィールドを検索するステップであって、前記属性格納フィールドに前記属性識別子に対応する属性対応が存在するかどうかを特定する、前記検索するステップ；前記属性識別子に対応する前記属性対応が存在する場合に、前記属性対応内の属性値を取得するステップ。

前記属性格納フィールドを検索するステップであって、前記属性格納フィールド内に前記属性識別子に対応する属性対応が存在するかどうかを特定する、前記検索するステップは以下を含む：前記属性格納フィールドを検索するステップであって、前記属性格納フィールド内に前記属性識別子を含む属性対応が存在するかどうかを特定する、前記検索するステップ；前記属性識別子を含む前記属性対応が存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する前記属性対応が存在する、と特定するステップ。

属性格納フィールドを検索するステップであって、前記属性格納フィールド内に属性識別子に対応する属性対応が存在するかどうかを特定する、前記検索するステップは以下を含む：属性識別子とインデックス識別子との間の第２の対応を取得するステップ；前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するステップ；前記属性格納フィールドを検索するステップであって、前記属性格納フィールド内に前記インデックス識別子を含む属性対応が存在するかどうかを特定する、前記検索するステップ；前記インデックス識別子を含む前記属性対応が存在する場合に、前記属性格納フィールドに前記属性識別子に対応する前記属性対応が存在する、と特定するステップ。

本開示の第３の実施の形態により、データ処理デバイスが提供され、前記デバイスは以下を含む：ユーザ識別子に加えて前記ユーザ識別子に対応する少なくとも１つの個人属性の属性識別子及び属性値を取得するように構成された第１取得モジュール；前記個人属性の前記属性識別子及び前記属性値に基づき、各々の前記個人属性について、前記個人属性の対象属性対応を生成するように構成された生成モジュール；ユーザ識別子と属性格納フィールドとの間の格納された第１の対応内に前記ユーザ識別子に対応する対象属性格納フィールドが存在するかどうかを特定するように構成された特定モジュール；前記第１の対応内に前記ユーザ識別子に対応する前記対象属性格納フィールドが存在する場合に、前記対象属性格納フィールドに全ての前記対象属性対応を格納するように構成された第１の格納モジュール；前記第１の対応内に前記ユーザ識別子に対応する対象識別子格納フィールドが存在しない場合に、前記ユーザ識別子に対応する属性格納フィールドを作成するように構成された作成モジュール；作成された前記属性格納フィールド内に全ての前記対象属性対応を格納するように構成された第２の格納モジュール。

前記生成モジュールは以下を含む：前記個人属性の前記属性識別子と前記個人属性の前記属性値との間に対象属性対応を確立するように構成された第１の確立ユニット；又は、
属性識別子とシーケンスインデックスのインデックス識別子との間の格納された第２の対応を取得するように構成された第１の取得ユニットと、前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するように構成された検索ユニットと、前記インデックス識別子と前記個人属性の前記属性値との間に対象属性対応を確立するように構成された第２の確立ユニット。

前記第１の格納モジュールは以下を含む：全ての前記対象属性対応により占められる格納スペースが、前記対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しいかどうか特定するように構成された特定ユニット；全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも小さい又はこれと等しい場合に、前記対象属性格納フィールドに全ての前記対象属性対応を格納するように構成された第１の格納ユニット；全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも大きい場合に、前記ユーザ識別子に対応する少なくとも１つの新たな属性格納フィールドを作成するように構成された作成ユニット；前記新たな属性格納フィールドに、又は、前記対象属性格納フィールド及び前記新たな属性格納フィールドに、全ての前記対象属性対応を格納するように構成された第２の格納ユニット。

前記第１の格納モジュールは以下を含む：前記対象属性対応内のインデックス識別子と、前記対象属性格納フィールドに格納された全ての属性対応内のインデックス識別子とに基づき、前記対象属性格納フィールド内で前記対象属性対応が格納される場所を特定するように構成された第１の特定ユニット；前記特定された場所に前記対象属性対応を格納するように構成された第３の格納ユニット。

本開示の第４の実施の形態により、データ処理デバイスが提供され、前記デバイスは以下を含む：ユーザ識別子と個人属性の属性識別子とを含む取得要求を取得する際に、前記第１の対応内に、前記ユーザ識別子に対応する属性格納フィールドが存在するかどうかを特定するために、ユーザ識別子と属性格納フィールドとの間の第１の対応を検索するように構成された第１の検索モジュール；前記ユーザ識別子に対応する前記属性格納フィールドが存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する属性対応が存在するかどうかを特定するために、前記属性格納フィールドを検索するように構成された第２の検索モジュール；前記属性識別子に対応する前記属性対応が存在する場合に、前記属性対応内の属性値を取得するように構成された第２の取得モジュール。

前記第２の検索モジュールは以下を含む：前記属性格納フィールドに前記属性識別子を含む属性対応が存在するかどうかを特定するために、前記属性格納フィールド内を検索するように構成された第１の検索ユニット；前記属性識別子を含む前記属性対応が存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する前記属性対応が存在する、と特定するように構成された第２の特定ユニット。

前記第２の検索モジュールは以下を含む：属性識別子とインデックス識別子との間の第２の対応を取得するように構成された第２の取得ユニット；前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するように構成された第２の検索ユニット；前記属性格納フィールドに前記インデックス識別子を含む属性対応が存在するかどうかを特定するために、前記属性格納フィールドを検索するように構成された第３の検索ユニット；前記インデックス識別子を含む前記属性対応が存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する前記属性対応が存在する、と特定するように構成された第３の特定ユニット。

本開示の実施で提供される技術的解決策は以下の有益な効果を奏する。

本開示の実施においては、ユーザＩＤに加えてユーザＩＤに対応する少なくとも１つの個人属性の属性識別子（ＩＤ）及び属性値を取得する。各個人属性について、個人属性の属性ＩＤ及び属性値に基づき、個人属性の対象（ターゲット）属性対応が生成される。ユーザＩＤと属性格納フィールドとの間の格納された第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在するかどうかが特定される。第１の対応内にユーザＩＤに対応する対象格納フィールドが存在する場合には、対象属性格納フィールドに全ての対象属性対応が格納される。反対に、第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在しない場合には、ユーザＩＤに対応する属性格納フィールドが作成され、作成された属性格納フィールドに全ての対象属性対応が格納される。

本開示のこの実施では、既存の技術における格納構造を取り入れていない。まず、空フィールドがないため、空フィールドのために格納スペースが無駄になるという問題が回避され、格納スペース節約の目的が達成される。加えて、既存の技術では、各フィールドに格納される属性は１つだけである。しかし、本開示の実施では、１つの属性格納フィールドに複数の属性対応が格納され、各属性対応が属性値を含む。そのため、既存の技術と比較して、本開示の実施では、１つの属性格納フィールド内に複数の属性値が格納され、属性格納フィールド内の格納スペースが十分に利用されることで、格納スペースの節約となる。

更に、サービス業の急速な発展に伴い、ユーザの個人的なニーズは尽きることなく多様に現れる。そのため、新たな個人属性を頻繁に開設する必要がある。この場合、既存の技術においては、表１の第１の行の最も右側にフィールドを１つ追加し、新たに追加したこのフィールドに新たな個人属性の属性名を追加する必要がある。次に、表１の各ユーザＩＤの最も右側にも新たなフィールドを１つ追加する必要があり、ユーザが新たな個人属性を有する場合、ユーザＩＤが位置している行の最も右側の新たに追加されたこのフィールドに、個人属性の属性値が入力される。

しかし、この場合、表１のユーザＩＤに対応する全てのユーザが新たな個人属性を有する訳ではないため、全てのユーザＩＤが位置している行の最も右側の新たに追加されたフィールドが属性値で埋められることはなく、結果として、いくつかの空フィールドが生じ、多かれ少なかれ格納スペースが無駄になってしまう。

加えて、表１に新たなフィールドを追加する工程において、表１をロックする必要があり、ロックされた状態の表１は使用できなくなる。表１に非常に多くのユーザＩＤが格納されている場合には、つまり、表１に多数（複数）の行がある場合には、全てのユーザＩＤが位置している行の最も右側に新たなフィールドを追加するために多くの時間を要する。その結果、表１を長時間使用できなくなり、長時間にわたりユーザに的確なサービスを提供することが不可能となる。しかし、本開示のこの実施では、新たな個人属性が展開されたとしても、展開された新たな個人属性にフィールドを割り当てる必要がなく、又、格納された個人属性をロックする必要がないため、ユーザは絶えず的確なサービスを受けることができる。加えて、展開された新たな個人属性にフィールドを割り当てる必要がない。したがって、空フィールドが生じない。よって、格納スペースが無駄になるという問題を軽減できる。

前述の一般的な説明及び以下の詳細な説明は単なる例であり、本開示を限定するものではないことを理解されたい。

添付の図面は、本明細書に組み込まれ、本明細書の一部を構成するものであり、本開示と一致する実施を示し、説明と共に本開示の原理を説明する役割を果たす。

実施によるデータ処理方法を示すフローチャートである。

実施によるデータ処理方法を示すフローチャートである。

実施によるデータ処理方法を示すフローチャートである。

実施によるデータ処理方法を示すフローチャートである。

実施によるデータ処理デバイスを示すブロック図である。

実施によるデータ処理デバイスを示すブロック図である。

実施は本明細書で詳細に説明され、実施例は添付図面に示される。以下の説明は、添付の図面と関連している場合、別段の指定がない限り、異なる添付の図面における同一の番号は、同一又は類似の要素を表す。以下に説明される実施は、本開示と一致する全ての実施を表すものではない。それどころか、実施は、添付の特許請求の範囲に詳細に記載され、本開示のいくつかの態様に一致する、デバイス及び方法の単なる例である。

図１は、実施によるデータ処理方法を示すフローチャートである。図１に示すように、本方法は以下のステップを含む。

ステップＳ１０１：ユーザ識別子（ＩＤ）に加えてユーザＩＤに対応する少なくとも１つの個人属性の属性識別子（ＩＤ）及び属性値を取得する。

ユーザＩＤはユーザのアカウント番号であってよい。例えば、ユーザはユーザアカウントをサーバに事前に登録でき、ユーザＩＤは、このユーザアカウントのアカウント番号であってよい。

個人属性の属性ＩＤは、例えば、「デフォルトの決済方法」及び「デフォルトの決済アカウント番号」等の個人属性の名称であってよい。

個人属性の名称が「デフォルトの決済方法」である場合には、個人属性の属性値は「オンライン決済」又は「現金引換え」であってよい。

個人属性の名称が「デフォルトの決済アカウント番号」である場合には、個人属性の属性値は、アカウント番号、例えば、「２７３３５６２１４」や「１７８５４９６２４」であってよい。

個人属性の名称が「興味ある製品のカテゴリ」である場合には、個人属性の属性値は、「デジタル家電」、「食品」、又は「靴／バッグ」等であってよい。

本開示のこの実施では、サーバが、特定のユーザの個人属性を初めて格納する場合、ユーザのユーザアカウントから、ユーザのユーザＩＤ並びにそのユーザの各個人属性の属性ＩＤ及び属性値を取得できる。

その後、ユーザが自分の端末デバイス上で自分のユーザＩＤを用いてサーバにログインした後に、ユーザが自分のアカウント内の１つ以上の既存の個人属性の属性ＩＤに対応する属性値を更新する場合、端末デバイスが、ユーザのユーザＩＤと、１つ以上の更新された個人属性の属性ＩＤと、更新された１つ以上の個人属性の各属性ＩＤに対応する属性値とを取得し、次に、取得したユーザＩＤと、属性ＩＤと、属性値とをサーバへ送信する。サーバが、端末デバイスにより送信されたユーザＩＤと、属性ＩＤと、属性値とを受信する。

ユーザが自分の端末デバイス上で自分のユーザＩＤを用いてサーバにログインした後に、ユーザが１つ以上の新たな個人属性の属性ＩＤ、各々の新たな属性ＩＤに対応する属性値をユーザ自身のアカウントに追加する場合、端末デバイスが、ユーザのユーザＩＤと、各々の新たな個人属性の属性ＩＤと、各々の新たな個人属性に対応する属性値とを取得し、次に、取得したユーザＩＤと、属性ＩＤと、属性値とをサーバへ送信する。サーバは、端末デバイスにより送信されたユーザＩＤと、属性ＩＤと、属性値とを受信する。

ステップＳ１０２：各個人属性について、個人属性の属性ＩＤ及び属性値に基づき、個人属性の対象属性対応を生成する。

本開示の実施では、各個人属性について、個人属性の属性ＩＤと個人属性の属性値との間に対象属性対応を確立できる。対象属性対応は個人属性の属性ＩＤ及び個人属性の属性値を含む。個人属性の属性ＩＤ及び個人属性の属性値は、キー値ペアを形成できる。この操作を各個人属性について実行する。

キー値ペアにおいて、「キー」は個人属性の属性ＩＤを表すために用いられ、「値」は個人属性の属性値を表すために用いられ、属性ＩＤと属性値は第１の所定識別子を用いて接続されている。第１の所定識別子は「＝」、「−」、「＋」等であってよく、これは本開示では限定されない。

例えば、個人属性の属性ＩＤが「デフォルトの決済方法」であり、個人属性の属性値が「オンライン決済」であると仮定すると、対象属性対応は「デフォルトの決済方法＝オンライン決済」であってよい。

先の実施では、個人属性の属性ＩＤは、通常、個人属性の名称、例えば「デフォルトの決済方法」、「デフォルトの決済アカウント番号」、「興味ある製品のカテゴリ」である。しかし、個人属性の名称は、通常、多くの文字を含むため、個人属性の属性ＩＤが格納スペースの大きな容量を占めてしまう。属性対応は個人属性の属性ＩＤを含むため、属性ＩＤが格納スペースの大きな容量を占めると、属性対応が格納スペースのかなり大きな容量を占めることになる。

本開示の目的は、１つの属性格納フィールド内に可能な限り多くの属性対応を格納することである。しかし、１つの属性格納フィールドの総格納スペースは限られている。そのため、属性対応が比較的大きな格納スペースを占めるケースでは、１つの属性格納フィールドに格納できる属性対応の数は少なくなる。

より多くの属性対応を１つの属性格納フィールドに格納するために、本開示の別の実施では、各個人属性にインデックス識別子（ＩＤ）を事前に割り当てることができる。種々の個人属性に種々のインデックスＩＤが割り当てられる。各個人属性の属性ＩＤが占める格納スペースは、個人属性の属性ＩＤに割り当てられたインデックスＩＤが占める格納スペースよりも小さい。

次に、各個人属性の属性ＩＤと、その個人属性に割り当てられたインデックスＩＤとが、属性ＩＤとシーケンスインデックスのインデックスＩＤとの間の第２の対応に格納される。

割り当てられた全てのインデックスＩＤには所定のインデックス順序がある。例えば、インデックスＩＤは１、２、３、４、５等の数字であり、これらの数字は昇順に配列される。

このように、本開示の別の実施では、個人属性の属性ＩＤと属性値とに基づき個人属性の対象属性対応を生成するステップは以下のとおりであってよい。

任意の個人属性について、属性ＩＤとシーケンスインデックスのインデックスＩＤとの間の格納された第２の対応を取得し、個人属性の属性ＩＤに対応するインデックスＩＤについて第２の対応を検索し、更に、インデックスＩＤと個人属性の属性値との間の対象属性対応を確立することで、個人属性の属性ＩＤと属性値とに基づいて個人属性の対象属性対応を生成できる。対象属性対応は、個人属性の属性ＩＤと個人属性の属性値とに対応するインデックスＩＤを含む。個人属性の属性ＩＤと個人属性の属性値とに対応するインデックスＩＤはキー値ペアを形成できる。この操作を各個人属性について実行する。

キー値ペアにおいて、「キー」は個人属性の属性ＩＤに対応するインデックスＩＤを表すために用いられ、「値」は個人属性の属性値を表すために用いられ、インデックスＩＤと属性値は第１の所定識別子を用いて接続されている。第１の所定識別子は「＝」、「−」、「＋」等であってよく、これは本開示では限定されない。

例えば、個人属性の属性ＩＤが「デフォルトの決済方法」であり、個人属性の属性値が「オンライン決済」であり、個人属性の属性ＩＤに対応するインデックスＩＤが１であると仮定すると、対象属性対応は「１＝オンライン決済」であってよい。

ステップＳ１０３：ユーザＩＤと属性格納フィールドとの間の格納された第１の対応内に、ユーザＩＤに対応する対象属性格納フィールドが存在するかどうかを特定する。

サーバにアカウントを登録する任意のユーザについて、サーバがユーザの属性対応を最初に格納する際に、ユーザＩＤと属性格納フィールドとの間の第１の対応内に、ユーザＩＤに対応する属性格納フィールドが確立される。次に、ユーザの属性対応が属性格納フィールドに格納される。本開示のこの実施では、後にユーザの新たな個人属性が追加される場合、新たな個人属性の属性ＩＤと属性値に基づいて新たな個人属性の新たな属性対応が生成された後に、この新たな属性対応は属性格納フィールドに引き続き格納される。これは、サーバにアカウントを登録するその他全てのユーザに適用される。

対象属性対応の生成後に、ユーザＩＤと属性格納フィールドとの間の格納された第１の対応内に、ユーザＩＤに対応する対象属性格納フィールドが存在するかどうかを特定する必要がある。

ユーザＩＤに対応する対象属性格納フィールドが存在する場合には、この対象属性対応を、対象属性格納フィールドに直接格納できる。

ユーザＩＤに対応する対象属性格納フィールドが存在しない場合には、ユーザの属性対応がそれまでに格納されたことがないこと、つまり、ユーザＩＤに対応する属性格納フィールドが格納されていないことを意味する。この場合、ユーザＩＤに対応する属性格納フィールドを第１の対応内に作成する必要があり、その後に、作成した属性格納フィールド内に対象属性対応を格納できる。

ステップＳ１０４：第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在する場合、全ての対象属性対応を対象属性格納フィールドに格納する。

ステップＳ１０５：第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在しない場合、ユーザＩＤに対応する属性格納フィールドを作成し、ステップＳ１０６を実行する。

ステップＳ１０６：全ての対象属性対応を、作成した属性格納フィールドに格納する。

図１に示す本開示のこの実施では、ユーザＩＤに加えてこのユーザＩＤに対応する少なくとも１つの属性ＩＤ及び属性値を取得し；各個人属性について、個人属性の属性ＩＤ及び属性値に基づき、個人属性の対象属性対応を生成し；ユーザＩＤと属性格納フィールドとの間の格納された第１の対応内に、ユーザＩＤに対応する対象属性格納フィールドが存在するかどうかを特定し；第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在する場合、全ての対象属性対応を対象属性格納フィールドに格納し；又は、第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在しない場合、ユーザＩＤに対応する属性格納フィールドを作成し、作成したこの属性格納フィールドに全ての対象属性対応を格納する。

本開示のこの実施では、既存の技術における格納構造を取り入れていない。まず、空フィールドがないので、空フィールドのために格納スペースが無駄になるという問題が回避され、格納スペース節約の目的が達成される。加えて、既存の技術では、各フィールドに格納される属性は１つだけである。しかし、本開示のこの実施では、１つの属性フィールドに複数の属性対応が格納され、各属性対応が属性値を含む。そのため、既存の技術と比較して、本開示の実施では、１つの属性格納フィールド内に複数の属性値が格納され、属性格納フィールド内の格納スペースが十分に利用されることで、格納スペースの節約となる。

更に、サービス業の急速な発展に伴い、ユーザの個人的なニーズは尽きることなく多様に現れる。そのため、新たな個人属性を頻繁に開設する必要がある。この場合、既存の技術においては、表１の第１の行の最も右側にフィールドを１つ追加し、新たに追加したこのフィールドに新たな個人属性の属性名を追加する必要がある。次に、表１の各ユーザＩＤの最も右側に新たなフィールドを１つ追加する必要があり、ユーザが新たな個人属性を有する場合、ユーザＩＤが位置している行の最も右側の新たに追加されたこのフィールドは、個人属性の属性値で埋められる。

しかし、この場合、表１のユーザＩＤに対応する全てのユーザが新たな個人属性を有する訳ではないため、全てのユーザＩＤが位置している行の最も右側の新たに追加されたフィールドが属性値で埋められることはなく、結果として、いくつかの空フィールドが生じ、多かれ少なかれ格納スペースが無駄になってしまう。

加えて、表１に新たなフィールドを追加する工程において、表１をロックする必要があり、ロックされた状態の表１は使用できない。表１に非常に多数のユーザＩＤが格納されている場合、つまり、表１に多数（複数）の行がある場合、全てのユーザＩＤが位置している行の最も右側に新たなフィールドを追加するために多大な時間を要する。その結果、表１を長時間使用できなくなり、長時間にわたりユーザに的確なサービスを提供することが不可能となる。しかし、本開示のこの実施では、新たな個人属性が展開されたとしても、展開された新たな個人属性にフィールドを割り当てる必要がなく、又、格納された個人属性をロックする必要がないため、ユーザは絶えず的確なサービスを受けることができる。加えて、展開された新たな個人属性にフィールドを割り当てる必要がない。したがって、空フィールドが生じない。よって、格納スペースが無駄になるという問題を軽減できる。

本開示の別の実施では、図２を参照すると、ステップＳ１０４は以下を含む。

ステップＳ２０１：全ての対象属性対応によって占められる格納スペースは、対象属性格納フィールドの空き状態の格納スペースよりも少ない又はこれと等しいかどうかを特定する。

本開示のこの実施では、各文字が格納スペースの１ユニットを占め、各属性対応が複数の文字を含む。そのため、各属性対応が一定量の格納スペースを占める。属性格納フィールドの利用可能な格納スペースには限りがあるため、属性対応を属性格納フィールドに格納する必要がある場合には、属性対応により占められる格納スペースは、属性格納フィールドの利用可能な格納スペースよりも少ない又はこれと等しい、という客観的条件を満たす必要がある。この条件を満たす場合に限って、属性対応は属性格納フィールドに首尾よく格納される。そうでなく、属性対応により占められる格納スペースが属性格納フィールドの利用可能な格納スペースよりも大きい場合、属性対応は属性格納フィールドに首尾よく格納されない。

同様に、１つの属性格納フィールドに複数の属性対応を格納する必要がある場合にも、複数の属性対応により占められる格納スペースが、属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しいかどうかを特定する必要がある。

ステップＳ２０２：全ての対象属性対応により占められる格納スペースが対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しい場合、全ての対象属性対応を対象属性格納フィールド内に格納する。

全ての対象属性対応により占められる格納スペースが対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しい場合、それは、対象属性格納フィールドが全ての対象属性対応を収納できることを意味する。したがって、全ての対象属性対応を対象属性格納フィールドに直接格納できる。

ステップＳ２０３：全ての対象属性対応により占められる格納スペースが対象属性格納フィールドの空き状態の格納スペースよりも大きい場合、ユーザＩＤに対応する新たな属性格納フィールドを少なくとも１つ作成し、次に、ステップＳ２０４を実行する。

全ての対象属性対応により占められる格納スペースが対象属性格納フィールドの空き状態の格納スペースよりも大きい場合、それは、対象属性格納フィールドが全ての対象属性対応を収納できない事を意味し、したがって、ユーザＩＤに対応する新たな属性格納フィールドを少なくとも１つ作成する必要がある。

作成する新たな属性格納フィールドの数は、１つの属性格納フィールドの利用可能な格納スペース、全ての対象属性対応により占められる格納スペースに基づいて、又は、対象属性フィールドの利用可能な格納スペースに基づいて決定できる。本開示では具体的な決定方法を限定しない。

ステップＳ２０４：全ての対象属性対応を、新たな属性格納フィールド内、又は、対象属性格納フィールド及び新たな属性格納フィールド内に格納する。

対象属性格納フィールドが完全に占められている場合、対象属性対応を新たな属性格納フィールドに格納する。対象属性格納フィールドが完全に占められていない場合、最初にいくつかの対象属性対応を対象属性格納フィールドに格納し、対象属性格納フィールドが完全に占められた後に、残りの対象属性対応を新たな属性格納フィールドに格納する。

全ての対象属性対応が格納されると、所定の第２のセパレータを用いて、隣接し合う属性対応を分離して、異なる属性対応が互いに混同されないようにする。所定の第２のセパレータは「｜」、「＊」、「〜」等であってよく、本開示ではこれらを限定しない。

例えば、ある属性対応は「デフォルトの決済方法＝オンライン決済」であり、別の属性対応は「興味のある製品のカテゴリ＝デジタル家電」であり、また別の属性対応は「デフォルトの決済アカウント番号＝１２３４５６７８９」であると仮定する。３つの属性対応を属性格納フィールドに格納する場合に、３つの属性対応を所定の第２のセパレータ「｜」を用いて次のように分離できる：「デフォルトの決済方法＝オンライン決済｜興味ある製品のカテゴリ＝デジタル家電｜デフォルトの決済アカウント番号＝１２３４５６７８９」。

先の実施では、属性対応は個人属性の属性ＩＤ及び個人属性の属性値に対応するインデックスＩＤを含み、全ての個人属性のインデックスＩＤ間には所定のインデックス順序がある。そのため、本開示のこの実施では、後の個人属性の属性値の問い合わせの効率を向上させるために、対象属性対応に含まれているインデックスＩＤと、格納された属性対応内のインデックスＩＤ間の所定のインデックス順序とに基づいて対象属性対応を格納できる。

したがって、本開示の別の実施では、図３を参照すると、ステップＳ１０４は以下を含む。

ステップＳ３０１：対象属性格納フィールド内で対象属性対応が格納される場所を、対象属性対応内のインデックスＩＤ及び対象属性格納フィールドに格納された全ての属性対応内のインデックスＩＤに基づいて特定する。

本開示のこの実施では、属性格納フィールド内での属性対応の場所は、属性対応が、属性対応に含まれているインデックスＩＤ間の所定のインデックス順序に基づいて分類された後に特定される。

例えば、インデックスＩＤは、例えば、１、２、３、４、５等の通し番号であると仮定する。任意の属性格納フィールドについて、この属性格納フィールドに隣接する２つの属性格納フィールドにおいて、一方の属性格納フィールドの通し番号はその属性格納フィールドの通し番号よりも大きく、他方の属性格納フィールドの通し番号はその属性格納フィールドの通し番号よりも小さい。これは、その他全ての属性格納フィールドにも当てはまる。

このステップでは、対象属性対応を、対象属性対応内のインデックスＩＤと、格納された属性対応内のインデックスＩＤとに基づいて全ての格納された属性対応内で分類でき、又、対象属性対応が間に位置する、対象属性格納フィールド内の２つの属性対応が特定される。２つの属性対応において、一方の属性対応の通し番号は対象属性対応の通し番号よりも大きく、他方の属性対応の通し番号は対象属性対応の通し番号よりも小さい。２つの属性対応の間の場所は、対象属性対応を格納する場所として特定できる。

ステップＳ３０２：特定された場所に対象属性対応を格納する。

正確なサービスをユーザに提供しなければならない場合、サーバはユーザの１つ以上の個人属性の属性値を問い合わせる必要がある。図４を参照すると、問い合わせは以下の方法に従って実行できる。この方法は以下のステップを含む。

ステップＳ４０１：ユーザＩＤと個人属性の属性ＩＤとを含んだ取得要求を取得するときに、ユーザＩＤに対応する属性格納フィールドが第１の対応内に存在するかどうかを特定するために、ユーザＩＤと属性格納フィールドとの間の第１の対応を検索する。

本開示のこの実施では、ユーザに正確なサービスを提供しなければならない場合に、ユーザの１つ以上の個人属性の属性値を取得する必要がある。先ず、取得すべきユーザのユーザＩＤと個人属性の属性ＩＤとに基づいて取得要求を生成する。その後、ユーザＩＤと属性格納フィールドとの間の第１の対応を取得でき、更に、この第１の対応内にユーザＩＤに対応する属性格納フィールドが存在するかどうかを特定するために、第１の対応を検索する。

ステップＳ４０２：ユーザＩＤに対応する属性格納フィールドが存在する場合には、属性格納フィールドを検索して属性格納フィールド内に属性ＩＤに対応する属性対応が存在するかどうかを特定する。

本開示の実施では、属性対応が属性ＩＤと属性値との間の対応である場合、このステップで、属性格納フィールドを検索して属性格納フィールド内に属性ＩＤを含む属性対応が存在するかどうかを特定でき、属性ＩＤを含む属性対応が存在する場合には、属性格納フィールド内に属性ＩＤに対応する属性対応が存在する、と特定できる。

具体的に、属性格納フィールド内で第１の属性対応を取得し、第１の属性対応内の属性ＩＤを取得し、更に、第１の属性対応内の属性ＩＤが属性ＩＤと同じものであるかどうかを特定する。この２つが同一である場合には、第１の属性対応を、属性ＩＤに対応する属性対応である、と特定する。反対に、この２つが異なる場合には、第２の属性対応を取得し、第２の属性対応内の属性ＩＤを取得し、更に、第２の属性対応内の属性ＩＤが属性ＩＤと同じであるかどうかを特定する。この２つが同じである場合には、第２の属性対応を、属性ＩＤに対応する属性対応である、と特定する。反対に、この２つが異なる場合には、次の属性対応を取得して、この属性対応内の属性ＩＤが属性ＩＤと同じになるまで先の手順を実行し、取得した属性対応を、属性ＩＤに対応する属性対応である、と特定する。属性格納フィールド内の全ての属性対応内の属性ＩＤが属性ＩＤと異なる場合には、属性格納フィールド内には属性ＩＤに対応する属性対応がない、と特定できる。

属性ＩＤに対応する属性格納フィールドがない場合に、工程は終了する。

概して、属性格納フィールドは複数の属性対応を格納する。属性ＩＤに対応する属性対応が属性格納フィールド内の後方の場所に格納されている場合には、前出の方法ではほとんどの属性対応を通すので、時間がかかり、検出効率が低下する。

本開示の別の実施では、属性対応が、属性ＩＤに対応するインデックスＩＤと属性値との間の対応である場合に、このステップにおいて属性ＩＤとインデックスＩＤとの間の第２の対応を取得できる。属性ＩＤに対応するインデックスＩＤについて第２の対応を検索し；属性格納フィールドを検索して属性格納フィールド内にインデックスＩＤを含む属性対応が存在するかどうかを特定し；インデックスＩＤを含んだ属性対応が存在する場合には、属性格納フィールド内に属性ＩＤに対応する属性対応が存在する、と特定できる。

本開示のこの実施では、属性格納フィールド内の属性対応の場所は、属性対応が、属性対応内に含まれているインデックスＩＤ間での所定のインデックス順序に基づいて分類された後に特定される。そのため、検索効率を向上させるためには、属性格納フィールドを検索して属性格納フィールド内にインデックスＩＤを含んだ属性対応が存在するかどうかを特定するときに、先ず、インデックスＩＤを、属性格納フィールド内の１つ以上の所定の場所における属性対応内のインデックスＩＤと比較することができ；この比較結果に基づき、属性格納フィールド内におけるインデックスＩＤを含んでいる属性対応のおおよその場所を特定し；次に、インデックスＩＤを、このおおよその場所における１つ以上の属性対応内のインデックスＩＤと比較して、インデックスＩＤを含んだ属性対応が存在するかどうかを特定する。

ステップＳ４０３：属性ＩＤに対応する属性対応が存在する場合、属性対応内の属性値を取得する。

属性ＩＤに対応する属性対応が存在しない場合、それは、ユーザＩＤに対応するユーザが個人属性を持っていないことを意味する。更に、ユーザＩＤに対応するユーザが個人属性を持たない旨をユーザにプロンプト表示することができる。

図５は、実施によるデータ処理デバイスを示すブロック図である。図５を参照すると、このデバイスは：ユーザＩＤに加えてユーザＩＤに対応する少なくとも１つの個人属性の属性ＩＤ及び属性値を取得するように構成された第１の取得モジュール１１と；各個人属性について、個人属性の属性ＩＤ及び属性値に基づき個人属性の対象属性対応を生成するように構成された生成モジュール１２と；ユーザＩＤと属性格納フィールドとの間の格納された第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在するかどうかを特定するように構成された特定モジュール１３と；第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在する場合に、全ての対象属性対応を対象格納フィールドに格納するように構成された第１の格納モジュール１４と；第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在しない場合に、ユーザＩＤに対応する属性格納フィールドを作成するように構成された作成モジュール１５と；作成された属性格納フィールドに全ての対象属性対応を格納するように構成された第２の格納モジュール１６と；を含む。

生成モジュール１２は：個人属性の属性ＩＤと個人属性の属性値との間の対象属性対応を確立するように構成された第１の確立ユニットと；格納された属性ＩＤとシーケンスインデックスのインデックスＩＤとの間の第２の対応を取得するように構成された第１の取得ユニットと；属性ＩＤに対応するインデックスＩＤについて第２の対応を検索するように構成された検索ユニットと：インデックスＩＤと個人属性の属性値との間の対象属性対応を確立するように構成された第２の確立ユニットと；を含む。

第１の格納モジュール１４は：全ての対象属性対応により占められる格納スペースが、対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しいかどうかを特定するように構成された特定ユニットと；全ての対象属性対応により占められる格納スペースが、対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しい場合に、対象属性格納フィールドに全ての対象属性対応を格納するように構成された第１の格納ユニットと；全ての対象属性対応により占められる格納スペースが、対象属性格納フィールドの空き状態の格納スペースよりも大きい場合に、ユーザＩＤに対応する少なくとも１つの新たな属性格納フィールドを作成するように構成された作成ユニットと；新たな属性格納フィールド内に、又は対象属性格納フィールド及び新たな属性格納フィールド内に、全ての対象属性対応を格納するように構成された第２の格納ユニットと；を含む。

第１の格納モジュール１４は：対象属性対応内のインデックスＩＤと、対象属性格納フィールド内に格納された全ての属性対応内のインデックスＩＤとに基づき、対象属性格納フィールド内で対象属性対応が格納される場所を特定するように構成された第１の特定ユニットと；特定された場所に対象属性対応を格納するように構成された第３の格納ユニットと：を含む。

図５に示す本開示のこの実施では、ユーザＩＤに加えてユーザＩＤに対応する少なくとも１つの個人属性の属性ＩＤと属性値を取得する。各個人属性について、個人属性の属性ＩＤと属性値に基づき、個人属性の対象属性対応を生成する。ユーザＩＤと属性格納フィールドとの間の格納された第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在するかどうかを特定し；第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在する場合は、対象属性格納フィールドに全ての対象属性対応を格納する。反対に、第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在しない場合は、ユーザＩＤに対応する属性格納フィールドを作成し、更に、作成された属性格納フィールド内に全ての対象属性対応を格納する。

本開示のこの実施では、既存の技術における格納構造を取り入れていない。先ず、空フィールドがないため、空フィールドのために格納スペースが無駄になるという問題が回避され、格納スペース節約の目的が達成される。加えて、既存の技術では、各フィールドに格納される属性は１つだけである。しかし、本開示のこの実施では、１つの属性格納フィールドに複数の属性対応が格納され、各属性対応が属性値を含む。そのため、既存の技術と比較して、本開示の実施では、１つの属性格納フィールド内に複数の属性値が格納され、属性格納フィールド内の格納スペースが十分に利用されることで、格納スペースの節約となる。

更に、サービス業の急速な発展に伴い、ユーザの個人的なニーズは尽きることなく多様に現れる。そのため、新たな個人属性を頻繁に展開する必要がある。この場合、既存の技術においては、表１の第１の行の最も右側にフィールドを１つ追加し、新たに追加したこのフィールドに新たな個人属性の属性名を追加する必要がある。次に、表１の各ユーザＩＤの最も右側にも新たなフィールドを１つ追加する必要があり、ユーザが新たな個人属性を有する場合、ユーザＩＤが位置している行の最も右側の新たに追加されたこのフィールドに、個人属性の属性値が入力される。

しかし、表１のユーザＩＤに対応する全てのユーザが新たな個人属性を有する訳ではないので、全てのユーザＩＤが位置している行の最も右側の新たに追加されたフィールドが属性値で埋められることはなく、結果として、いくつかの空フィールドが生じ、多かれ少なかれ格納スペースが無駄になってしまう。

加えて、表１に新たなフィールドを追加する工程において、表１をロックする必要があり、ロックされた状態の表１は使用できない。表１に非常に多数のユーザＩＤが格納されている場合、つまり表１に多数（複数）の行がある場合、全てのユーザＩＤが位置している行の最も右側に新たなフィールドを追加するために多大な時間を要する。その結果、表１を長時間使用できなくなり、長時間にわたりユーザに的確なサービスを提供することが不可能となる。しかし、本開示のこの実施では、新たな個人属性が展開されたとしても、展開された新たな個人属性にフィールドを割り当てる必要もなく、格納された個人属性をロックする必要もないため、ユーザは絶えず的確なサービスを受けることができる。加えて、展開された新たな個人属性にフィールドを割り当てる必要がないので空フィールドが生じない。よって、格納スペースが無駄になるという課題を軽減できる。

図６は、実施によるデータ処理デバイスを示すブロック図である。図６を参照すると、本デバイスは：個人属性のユーザＩＤ及び属性ＩＤを含んだ取得要求を取得するときに、ユーザＩＤと属性格納フィールドとの間の第１の対応を検索してユーザＩＤに対応する属性格納フィールドが第１の対応内に存在するかどうかを特定するように構成された第１の検索モジュール２１と；ユーザＩＤに対応する属性格納フィールドが存在する場合に、属性格納フィールドを検索して属性ＩＤに対応する属性対応が属性格納フィールド内に存在するかどうかを特定するように構成された第２の検索モジュール２２と；属性ＩＤに対応する属性対応が存在する場合に、属性対応内の属性値を取得するように構成された第２の取得モジュール２３と；を含む。

第２の検索モジュール２２は：属性格納フィールドを検索して属性ＩＤを含む属性対応が属性格納フィールド内に存在するかどうかを特定するように構成された第１の検索ユニットと；属性ＩＤを含む属性対応が存在する場合に、属性ＩＤに対応する属性対応が属性格納フィールド内に存在する、と特定するように構成された第２の特定ユニットと；を含む。

第２の検索モジュール２２は：属性ＩＤとインデックスＩＤとの間の第２の対応を取得するように構成された第２の取得ユニットと；属性ＩＤに対応するインデックスＩＤについて第２の対応を検索するように構成された第２の検索ユニットと；属性格納フィールドを検索して属性格納フィールド内にインデックスＩＤを含む属性対応が存在しているかどうか特定するように構成された第３の検索ユニットと；属性ＩＤを含む属性対応が存在している場合に、属性格納フィールド内に属性ＩＤに対応する属性対応が存在する、と特定するように構成された第３の特定ユニットと；を含む。

図６に示す本開示のこの実施では、ユーザＩＤに加えてユーザＩＤに対応する少なくとも１つの個人属性の属性ＩＤ及び属性値を取得する。各個人属性について、個人属性の属性ＩＤ及び属性値に基づき、個人属性の対象属性対応を生成する。ユーザＩＤと属性格納フィールドとの間の格納された第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在するかどうかを特定し；第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在する場合に、対象属性格納フィールドに全ての対象属性対応を格納する。反対に、第１の対応内にユーザＩＤに対応する対象属性格納フィールドが存在しない場合は、ユーザＩＤに対応する属性格納フィールドを作成し、更に、作成した属性格納フィールド内に全ての対象属性対応を格納する。

図１に示す本開示のこの実施では、既存の技術における格納構造を取り入れていない。まず、空フィールドがないので、空フィールドのために格納スペースが無駄になってしまうという問題が回避され、格納スペース節約の目的が達成される。加えて、既存の技術では、各フィールドに格納される属性は１つだけである。しかし、図６に示す本開示の実施では、１つの属性格納フィールドに複数の属性対応が格納され、各属性対応が属性値を含む。そのため、既存の技術と比較して、図６に示す本開示のこの実施では、１つの属性格納フィールド内に複数の属性値が格納され、属性格納フィールド内の格納スペースが十分に利用されることで、格納スペースの節約となる。

更に、サービス業の急速な発展に伴い、ユーザの個人的なニーズは尽きることなく多様に現れる。そのため、新たな個人属性を頻繁に開設する必要がある。この場合、既存の技術においては、表１の第１の行の最も右側にフィールドを１つ追加し、新たに追加したこのフィールドに新たな個人属性の属性名を追加する必要がある。次に、表１の各ユーザＩＤの最も右側にも新たなフィールドを１つ追加する必要があり、ユーザが新たな個人属性を有する場合、ユーザＩＤが位置している行の最も右側の新たに追加されたこのフィールドに、個人属性の属性値が入力される。

しかし、この場合、表１のユーザＩＤに対応する全てのユーザが新たな個人属性を有する訳ではないため、全てのユーザＩＤが位置している行の最も右側の新たに追加されたフィールドが属性値で埋められることはなく、結果として、いくつかの空フィールドが生じ、多かれ少なかれ格納スペースが無駄になる。

加えて、表１に新たなフィールドを追加する工程において、表１をロックする必要があり、ロックされた状態の表１は使用できない。表１に非常に多数のユーザＩＤが格納されている場合、つまり、表１に多数（複数）の行がある場合、全てのユーザＩＤが位置している行の最も右側に新たなフィールドを追加するために多大な時間を要する。その結果、表１を長時間使用できなくなり、長時間にわたりユーザに的確なサービスを提供することが不可能となる。しかし、図６に示す本開示のこの実施では、新たな個人属性が展開されたとしても、展開された新たな個人属性にフィールドを割り当てる必要がなく、又、格納された個人属性をロックする必要がないため、ユーザは絶えず的確なサービスを受けることができる。加えて、展開された新たな個人属性にフィールドを割り当てる必要がなく、したがって、空フィールドが生じないため、格納スペースが無駄になってしまうという問題を軽減できる。

上記の実施におけるデバイスに関して、モジュールにより操作を実行する具体的な方法は、その方法に関連する実施において詳細に述べているため、ここでは簡略化の目的で詳細を省略する。

当業者であれば、本明細書を考察して本開示を実行した後、本開示の別の実施を容易に理解することができる。本願は、本開示のあらゆる変形、使用、又は適応を包含するように意図されており、これらの変形、使用、又は適合は、本開示の一般原則に従うものであり、本開示の技術分野において開示されていない一般的知識又は従来技術をも含む。明細書及び実施は、例示としてのみ考慮され、本開示の真の範囲及び精神は添付の特許請求の範囲によって示される。

本開示は、上で説明され、図面に示されている厳密な構造に限定されず、本開示の範囲から逸脱することなく様々な修正及び変更を行うことができることを理解されたい。本開示の範囲は、添付の特許請求の範囲によってのみ限定される。

Claims (14)

1. ユーザ識別子に加えて前記ユーザ識別子に対応する少なくとも１つの個人属性の属性識別子及び属性値を取得するステップと；
   各々の前記個人属性について、前記個人属性の前記属性識別子及び前記属性値に基づき、前記個人属性の対象属性対応を生成するステップと；
   ユーザ識別子と属性格納フィールドとの間の格納された第１の対応内に前記ユーザ識別子に対応する対象属性格納フィールドが存在するかどうかを特定するステップと；
   前記第１の対応内に前記ユーザ識別子に対応する前記対象属性格納フィールドが存在する場合に、前記対象属性格納フィールド内に全ての前記対象属性対応を格納するステップ；又は
   前記第１の対応内に前記ユーザ識別子に対応する前記対象属性格納フィールドが存在しない場合に、前記ユーザ識別子に対応する属性格納フィールドを作成し、前記作成された属性格納フィールド内に全ての前記対象属性対応を格納するステップと；を備える、
   データ処理方法。
2. 個人属性の属性識別子及び属性値に基づき、個人属性の対象属性対応を生成する前記ステップは：
   前記個人属性の前記属性識別子と前記個人属性の前記属性値との間に対象属性対応を確立するステップ；又は、
   前記属性識別子とシーケンスインデックスのインデックス識別子との間の格納された第２の対応を取得するステップと、前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するステップと、前記インデックス識別子と前記個人属性の前記属性値との間に対象属性対応を確立するステップ；を備える、
   請求項１に記載の方法。
3. 対象属性格納フィールドに全ての対象属性対応を格納する前記ステップは：
   全ての前記対象属性対応により占められる格納スペースが、前記対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しいかどうかを特定するステップと；
   全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも小さい又はこれと等しい場合に、前記対象属性格納フィールドに全ての前記対象属性対応を格納するステップ；又は
   全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも大きい場合に、前記ユーザ識別子に対応する少なくとも１つの新たな属性格納フィールドを作成するステップと、前記新たな属性格納フィールドに、又は、前記対象属性格納フィールド及び前記新たな属性格納フィールドに、全ての前記対象属性対応を格納するステップ；を備える、
   請求項１又は請求項２に記載の方法。
4. 前記対象属性格納フィールドに全ての前記対象属性対応を格納する前記ステップは：
   前記対象属性格納フィールド内で前記対象属性対応が格納される場所を、前記対象属性対応内の前記インデックス識別子と、前記対象属性格納フィールドに格納された全ての前記属性対応内のインデックス識別子とに基づいて特定するステップと；
   前記特定された場所に前記対象属性対応を格納するステップと；を備える、
   請求項２に記載の方法。
5. ユーザ識別子と個人属性の属性識別子とを含む取得要求を取得するときに、ユーザ識別子と属性格納フィールドとの間の前記第１の対応を検索するステップであって、第１の対応内に前記ユーザ識別子に対応する属性格納フィールドが存在するかどうかを特定する、前記検索するステップと；
   前記ユーザ識別子に対応する前記属性格納フィールドが存在する場合に、前記属性格納フィールドを検索するステップであって、前記属性格納フィールドに前記属性識別子に対応する属性対応が存在するかどうかを特定する、前記検索するステップと；
   前記属性識別子に対応する前記属性対応が存在する場合に、前記属性対応内の属性値を取得するステップと；を備える、
   データ処理方法。
6. 前記属性格納フィールドを検索するステップであって、前記属性格納フィールド内に前記属性識別子に対応する属性対応が存在するかどうかを特定する、前記検索するステップは：
   前記属性格納フィールドを検索するステップであって、前記属性格納フィールド内に前記属性識別子を含む属性対応が存在するかどうかを特定する、前記検索するステップと；
   前記属性識別子を含む前記属性対応が存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する前記属性対応が存在する、と特定するステップと；を備える、
   請求項５に記載の方法。
7. 前記属性格納フィールドを検索するステップであって、前記属性格納フィールド内に前記属性識別子に対応する属性対応が存在するかどうかを特定する、前記検索するステップは：
   前記属性識別子とインデックス識別子との間の第２の対応を取得するステップと；
   前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するステップと；
   前記属性格納フィールドを検索するステップであって、前記属性格納フィールド内に前記インデックス識別子を含む属性対応が存在するかどうかを特定する、前記検索するステップと；
   前記インデックス識別子を含む前記属性対応が存在する場合に、前記属性格納フィールドに前記属性識別子に対応する前記属性対応が存在する、と特定するステップと；を備える、
   請求項５に記載の方法。
8. ユーザ識別子に加えて前記ユーザ識別子に対応する少なくとも１つの個人属性の属性識別子及び属性値を取得するように構成された第１取得モジュールと；
   前記個人属性の前記属性識別子及び前記属性値に基づき、各々の前記個人属性について、前記個人属性の対象属性対応を生成するように構成された生成モジュールと；
   ユーザ識別子と属性格納フィールドとの間の格納された第１の対応内に前記ユーザ識別子に対応する対象属性格納フィールドが存在するかどうかを特定するように構成された特定モジュールと；
   前記第１の対応内に前記ユーザ識別子に対応する前記対象属性格納フィールドが存在する場合に、前記対象属性格納フィールドに全ての前記対象属性対応を格納するように構成された第１の格納モジュールと；
   前記第１の対応内に前記ユーザ識別子に対応する対象識別子格納フィールドが存在しない場合に、前記ユーザ識別子に対応する属性格納フィールドを作成するように構成された作成モジュールと；
   作成された前記属性格納フィールド内に全ての前記対象属性対応を格納するように構成された第２の格納モジュールと；を備える、
   データ処理デバイス。
9. 前記生成モジュールは：
   前記個人属性の前記属性識別子と前記個人属性の前記属性値との間に対象属性対応を確立するように構成された第１の確立ユニット；又は、
   属性識別子とシーケンスインデックスのインデックス識別子との間の格納された第２の対応を取得するように構成された第１の取得ユニットと；
   前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するように構成された検索ユニットと；
   前記インデックス識別子と前記個人属性の前記属性値との間に対象属性対応を確立するように構成された第２の確立ユニットと；を備える、
   請求項８に記載のデバイス。
10. 前記第１の格納モジュールは：
    全ての前記対象属性対応により占められる格納スペースが、前記対象属性格納フィールドの空き状態の格納スペースよりも小さい又はこれと等しいかどうか特定するように構成された特定ユニットと；
    全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも小さい又はこれと等しい場合に、前記対象属性格納フィールドに全ての前記対象属性対応を格納するように構成された第１の格納ユニット；又は、
    全ての前記対象属性対応により占められる前記格納スペースが、前記対象属性格納フィールドの前記空き状態の格納スペースよりも大きい場合に、前記ユーザ識別子に対応する少なくとも１つの新たな属性格納フィールドを作成するように構成された作成ユニットと；
    前記新たな属性格納フィールドに、又は、前記対象属性格納フィールド及び前記新たな属性格納フィールドに、全ての前記対象属性対応を格納するように構成された第２の格納ユニットと；を備える、
    請求項８又は請求項９に記載のデバイス。
11. 前記第１の格納モジュールは：
    前記対象属性対応内のインデックス識別子と、前記対象属性格納フィールドに格納された全ての属性対応内のインデックス識別子とに基づき、前記対象属性格納フィールド内で前記対象属性対応が格納される場所を特定するように構成された第１の特定ユニットと；
    前記特定された場所に前記対象属性対応を格納するように構成された第３の格納ユニットと；を備える、
    請求項９に記載のデバイス。
12. ユーザ識別子と個人属性の属性識別子とを含む取得要求を取得する際に、前記第１の対応内に、前記ユーザ識別子に対応する属性格納フィールドが存在するかどうかを特定するために、ユーザ識別子と属性格納フィールドとの間の第１の対応を検索するように構成された第１の検索モジュールと；
    前記ユーザ識別子に対応する前記属性格納フィールドが存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する属性対応が存在するかどうかを特定するために、前記属性格納フィールドを検索するように構成された第２の検索モジュールと；
    前記属性識別子に対応する前記属性対応が存在する場合に、前記属性対応内の属性値を取得するように構成された第２の取得モジュールと；を備える、
    データ処理デバイス。
13. 前記第２の検索モジュールは：
    前記属性格納フィールドに前記属性識別子を含む属性対応が存在するかどうかを特定するために、前記属性格納フィールド内を検索するように構成された第１の検索ユニットと；
    前記属性識別子を含む前記属性対応が存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する前記属性対応が存在する、と特定するように構成された第２の特定ユニットと；を備える、
    請求項１２に記載のデバイス。
14. 前記第２の検索モジュールは：
    属性識別子とインデックス識別子との間の第２の対応を取得するように構成された第２の取得ユニットと；
    前記属性識別子に対応するインデックス識別子について前記第２の対応を検索するように構成された第２の検索ユニットと；
    前記属性格納フィールドに前記インデックス識別子を含む属性対応が存在するかどうかを特定するために、前記属性格納フィールドを検索するように構成された第３の検索ユニットと；
    前記インデックス識別子を含む前記属性対応が存在する場合に、前記属性格納フィールド内に前記属性識別子に対応する前記属性対応が存在する、と特定するように構成された第３の特定ユニットと；を備える、
    請求項１２に記載のデバイス。

Images