Adding hierarchy of objects when ingesting and normalizing data from heterogeneous data sources

Systems and methods are described herein relating to ingesting data objects from various sources and associating them in a hierarchy with a profile. In some aspects, a data object, including a set of fields and indicating a data object type, may be obtained for associating with a profile maintained by a computing resource service provider. The data object may be converted into a standardized format based on the data object type indicated in the data object using an object mapping associated with the data object. A key associated with the data object and indicated in the object mapping may be selected and used to search an index for a related profile. Upon finding a profile with the matching key, the profile may be updated to include an association of the standardized data object, such as in a hierarchy.

BACKGROUND

A data store service may utilize a collection of programs that enables storage, modification, and extraction of information from a data store. Many different types of data store services exist, ranging from small systems that execute on client devices to large systems that run on server computer systems. Data storage services can differ widely in the types of data that are stored and the ways in which that data is organized within a particular data store service. For example, user data can include order history, call log, contact information, and other structured and unstructured data which might be stored using various relational, flat, or hierarchical techniques. Storing and presenting this heterogeneous user data in a standardized hierarchical way can present challenges when the data comes from various sources that utilize different mapping and formats for the data.

DETAILED DESCRIPTION

Systems and methods are described herein relating to heterogeneous data object ingestion that enables loosely related data to be coherently organized into profiles and hierarchies within profiles. In some aspects, data objects including various data in various formats may be ingested from various sources (e.g., various customer relationship management (CRM) systems). The data objects may include data related to profile information of an entity (e.g., a customer), such as contact information relating to one or potentially many individuals linked to or associated with an account of the entity. In other cases, the data objects may include data relating to various information associated with an account history, such as including information pertaining to assets relating to the account, cases associated with the account, or order history information. In some aspects, the data objects may originate from one or many sources, including various customer relationship management systems, which may indicate what type of information the data objects contain. In various examples, the source and the indicated type of other information contained within the data object may be used to convert or map the data object into one of a number of standard templates, which format the data contained in the data objects in a way that is made usable by various other applications. The converted data object (e.g., standardized data object) may then be associated with a profile, such as adding the standardized data object to an existing profile, or by adding it to a newly created profile. In some cases, multiple instances of the same standardized data object, or multiple instances of different standardized data objects, or a combination thereof, may be associated with a single profile. The data objects may be organized in a hierarchy within the profile, such that various different relationships of data objects can be maintained and stored with one or more profiles.

In some examples, a single profile contains all the information collected and ingested for a particular entity (e.g., a user) and enables access to the information from a single profile view. An ingestion service may be responsible for ingesting (e.g., collecting, processing, storing, etc.) data objects from various sources and persisting and/or updating profiles to include information obtained from the data objects and/or the data objects themselves. A profile can include any number of fields representing data associated with a user or other entity, and any number of data objects of one or more data object types such as data objects that have been converted to a standardized format or data objects that have their own structure. In addition to maintain profiles, the data storage model may include keys that are indexed and associated with the profiles and data objects, such that when data objects are ingested the keys can be used to determine a particular profile or other data object to associate the data objects with. In some aspects, a data object, once ingested and associated with a profile, may itself be associated with one or more other data objects, to create a hierarchy of data objects, organized at a high level by profile. In some aspects, a profile may contain multiple data objects having a contact data type, where each contact data object may contain information pertaining to an individual or entity, with each individual or entity linked to or associated with the profile. In this example, each contact data object may in essence be or refer to a child profile or the main or parent profile. In some cases, keys may be generated for the data objects, such that the data objects may be individually searchable, and/or may be provided in response to queries for related data objects and/or profiles.

In some aspects, when ingesting a data object, an object mapping can be used to obtain a set of keys associated with profiles and data objects. In such examples, an index or other data store is searched using at least one key of the set of keys to determine a profile associated with the data object, and/or to locate individual data objects after they have been ingested. In this manner the set of keys can be used to relate heterogeneous data objects (e.g., records, order history, communications, account information, etc.) to a particular profile. In addition, this enables access to these different data objects from a single location. For example, a profile can represent a particular entity and can provide access to various ingested data objects including information, for example, associated with deliveries, support contacts, emails, and other information associated with the particular entity.

As described in greater detail below, the keys can include any value that is indexed. In one example, the keys can include string values, phone numbers, email addresses, street addresses, account numbers, or other values that are capable of being indexed. Furthermore, the keys can include both unique and non-unique keys (e.g., unique relative to other keys used by the profile service). In addition, the keys can be associated with a particular type. In one example, a key is assigned as a search only key (e.g., phone number), which may prevent the profile service from persisting the key. Other types of keys can include profile identifying keys (e.g., an account number), which can be used to uniquely identify a data object within a profile. Furthermore, in some examples, unique keys (e.g., profile identifying keys) are used to replace data objects associated with a particular profile with new data objects including updated information.

As described in greater detail below, the keys obtained from the data objects include various values such as string values which, in some examples, are normalized or standardized. For example, normalizing phone numbers, names, addresses, account numbers, and other values associated with the keys. Once the keys have been obtained from a particular data object and the data object has been ingested by the ingestion service, the keys are then searchable by the ingestion service, profile service, or other systems and services of a computing resource service provider. This enables systems and services of the computing resource service provider to determine which profile that a particular piece of information is related to (e.g., a particular data object). The data objects can include any structured and/or semi-structured data object. Furthermore, the data objects can include an object type and/or a domain name (e.g., a logical container that allows for multiple groups of profiles).

When ingesting data objects, the ingestion service or other system, utilizes the object mapping to determine the location of a key within the data object, extract the key, and searches the key in a key repository or other index. If the key is stored in the key repository, this indicates that a previously ingested data object including the key has been persisted and associated with a particular profile or data object. As a result, the ingestion service or other system, may determine that the data object should be associated with a particular profile or other data object as well. However, if none of the keys obtained from the data object match keys stored in the key repository, a new profile may be created and associated with the data object. In some situations, the ingestion service or other system, may prevent the creation of new profiles using particular types of keys and an error is returned. Returning to the previous examples, if the key is found in the repository or a new profile is created, the profile service or other system, causes the data object to be persisted and updates the profile based at least in part on information included in the data object (e.g., fields such as name, address, order number, etc.). In addition, the profile service or other system, can also update and/or generate keys maintained by the key repository.

As one skilled in the art will appreciate in light of this disclosure, certain embodiments may be capable of achieving certain advantages, including some or all of the following: (1) allowing ingestion of heterogeneous data objects and creating a hierarchy to access those data objects; (2) simplifying the user experience when ingesting heterogeneous data objects from a plurality of different sources; (3) allowing loosely related data objects to be correlated and accessed through a single profile; (4) creating a single location of the aggregation of all data related to a particular entity, and other benefits and advantages, as will be described in greater detail below throughout this document.

FIG.1is a block diagram illustrating an environment100in which an ingestion service106obtains a set of keys112A-112N from data objects104in order to associate the data objects104with a set of profiles114A-114N in accordance with at least one embodiment. In various embodiments, the data objects104are obtained from one or more source(s)102by the ingestion service106. The data objects104, as described in greater detail below, may include structured or semi-structured data objects. In one example, a semi-structured data object includes one or more fields organized within the data object in accordance with a format and/or syntax associated with the semi-structured data objects. In various examples, the data objects include documents, contact lists, call logs, chat logs, data logs, HyperText Markup Language (HTML) data, Extensible Markup Language (XML) data, JavaScript data, Cascading Style Sheets (CSS) data, JavaScript Object Notation (JSON) data, and/or another appropriate structured language or semi-structured data.

In various aspects, the ingestion service106includes a computer system, program, process, client, server, service, application, module, operating system entity, controlling domain, communication node or collection of these and/or other such computer system entities that implement various components of the ingestion service106as described in the present disclosure. In one example, the ingestion service106includes an interface that receives Application Programming Interface (API) calls that, as a result of being processed, cause servers executing the ingestion service106to perform various operations described in the present disclosure such as ingesting data objects104.

In various embodiments, the source(s)102include any computer system capable of recording, storing, and/or transmitting the data objects104. For example, the source(s)102include, in various embodiments, a service, a database, storage system, client computer system, customer relationship management (CRM) system, service, or other computing device. In one example, the source102includes a cloud contact center which records communications between users and the cloud contact center as data objects104. In such examples, the data objects104can include user phone numbers, account numbers, an identifier of the communication, subject information, call logs, chat logs, or other information associated with the communication stored as a JSON data object. Examples of JSON data objects are described in greater detail below. In various embodiment, this enables data from any of the source(s)102to be ingested and incorporated into the profiles regardless of how the profile has the data organized or how the incoming data objects have the data organized.

In various embodiments, the sources102transmit the data objects104to the ingestion service106periodically or aperiodically. For example, the sources102may transmit the data objects104contemporaneously or near contemporaneously with generation of the data objects104. Returning to the example above, once a communication between a user and the cloud contact center is complete, a corresponding data object is generated and/or completed and transmitted to the ingestion service106. In yet other embodiments, an intermediary such as a storage service obtains the data objects104and the ingestion service106obtains a notification that the data objects104have been received by the storage service. In such embodiments, the ingestion service106may place the data objects104in a queue and process the data objects104for ingestion from the queue.

In various embodiments, an API call causes the ingestion service106to obtain the data objects104from a data store of a data storage service accessible to the ingestion service106. In yet other embodiments, the sources102provide the data objects104directly to the ingestion service106(e.g., via an API call). In addition, a topic or feed can be used to trigger the API when the data objects are available for ingestion in accordance with at least one embodiment. Once the data objects104are obtained by the ingestion service106, in various embodiments, the ingestion service106unpacks the data objects104to obtain a set of keys112A-112N. As described in greater detail below, the set of keys112A-112N, in one example, includes different types of keys that define how the ingestion service106utilizes the keys. For example, the set of keys112A-112N includes profile keys that the ingestion service106uses to search a key repository110.

In various embodiments, at least one key of the set of keys112A-112N identifies a particular profile of the set of profiles114A-114N maintained by a profile service116. As described in greater detail below, a profile of the set of profiles114A-114N is associated with a particular entity, and enables access to all ingested information associated with the particular entity. In an embodiment, once the ingestion service106obtains the set of keys112A-112N from the data objects104, a subset of keys of the set of keys112A-112N are used to obtain search results108from the key repository110. As described in greater detail below, the key repository110, in at least one embodiment, includes an index of at least a subset of the keys ingested by the ingestion service106and is included in at least one profile of the set of profiles114A-114N. In one example, the keys are not cryptographic keys, but rather represent information such as, for example, names, email addresses, phone numbers, etc. of entities stored as profiles, as such the key repository110indexes particular values (e.g., a phone number) with the profile within which the particular value is stored and/or associated with. Additional details relating to ingesting and generate keys for profiles may be found in U.S. patent application Ser. No. 17/364,389, titled “HETERGENOUS DATA INGESTION AND INTEGRATION,” filed on Jun. 30, 2021, the contents of which are herein incorporated by reference in their entirety.

In some aspects, profiles114A-114N may include additional data objects, such that represent contacts or individuals or entities118,120, and/or data objects that represent various types of data, such as assets122, orders124, cases126, or various other forms or organizations of various data, as will be describe din greater detail below. In some aspects, one or more contacts can be associated with a profile, such as contacts118,120with profile114A. In some cases, contacts118,120may represent members of an account associated with a profile114A. A contact, such as contact118,120may include various information relating to an individual or entity, such as contact information, including email dress, address, phone number, account information. A data object that is ingested and becomes a contact may be referred to as a contact data object or a data object.

Similarly, a profile, such as profile114N, may have or be associated with various other types of data objects. For example, an asset data object, such as data object122, may include information relating to one or more assets associated with a profile or contact, such as physical assets, digital assets, and various other forms of items that a CRM system may account for, such as financial instruments and the like. An order data object, such as data object124, may include various information relating to prior orders associated with a profile or contact, such as items ordered, cost, payment, shipping, and various other details relating to a given order. A case data object, such as data object126may include various information relating to a case associated with a profile or contact, such as investigatory case, a return of an item, etc. The described techniques may generate keys for some or all of these various types of data objects that may be stored and associate with profiles, in a similar way that keys may be generated for profiles. This may enable precise access to these various data objects in relation to profiles and may enable creation of simple or complex hierarchies of data objects that may be made accessible to various entities.

In various embodiments, the search results108indicate a subset of keys of the set of keys112A-112N that match (e.g., are equivalent to or otherwise associated with) keys maintained in the key repository110and that are associated with one or more profiles of the set of profiles114A-114N. In one example, the set of keys112A-112N includes a first key corresponding to a name (e.g., “John Doe”) and a second key corresponding to a phone number (e.g., (555) 123-4567), the search results108indicate a match to one or more profiles if the index includes either the first key, the second key, or any equivalents (e.g., the first key with the value “John Doe” is the same as an indexed value “John Doe” maintained in the key repository110). In various embodiments, equivalents include keys that represent the same data, but that may be in a different format. For example, a phone number may be considered equivalent if the data is the same, but the format is different (e.g., “555-123-4567” and “(555) 123-4567”). In yet other embodiments described below, the values corresponding to keys are normalized when determined whether a particular key extracted from a data object matches a particular key indexed in the key repository110.

In an embodiment, if the search results108obtained by the ingestion service106indicate more than one result (e.g., profiles), the result is discarded as invalid. In other words, in such embodiments, if a particular key is associated with more than one profile, the ingestion service determines the search results are invalid and does not use the particular key to associate the data object from which the particular key was obtained with a profile of the set of profiles114A-114B. Furthermore, if the search for a particular key returns an invalid result (e.g., no matching profiles, more than one matching profile, etc.), the ingestion service106selects another key to perform the search. In various embodiments, searching for the subset of keys within the key repository110is performed in serial (e.g., a first key is selected and searched, if the results are invalid, then a second key is selected and searched). In yet other embodiments, the subset of keys is searched in parallel in order to obtain results faster and/or determine a plurality of matches. The ingestion service106, in various embodiments, performs the search and obtains the search results until a profile is uniquely (e.g., relative to the set of profiles114A-114N) identified. In addition, in some embodiments, a plurality of keys obtained from a particular data object104are capable of uniquely identifying a particular profile (e.g., profile112A). In such embodiments, the ingestion service106can terminate the search once the first key is determined to uniquely identify the particular profile. In one example, a first key representing a name and a second key representing an email address both uniquely identify the profile112A, when ingesting the data object104with these keys, the ingestion service106terminates the search once either the first key or the second key has been searched and identifies the profile112A as being associated with the data object104.

In addition, in various embodiments, the ingestion service106maintains a hierarchy for searching particular keys of the set of keys112A-112N. In one example, certain keys are marked as secondary. In such an example, keys marked as secondary may be searched only if all other keys obtained for a particular data object have failed to return a valid result (e.g., a particular profile). In various embodiments, the search results108indicate that a particular profile includes that same value as a search for the same field. In one example, the keys include a key name and/or category (e.g., username) and a value (e.g., “John Doe”). In such examples, the search results108indicate a positive result (e.g., a match) if the value and the category match. In addition, values associated with the keys, in an embodiment, can be normalized prior to searching and storing. For example, a string value representing the key can be normalized (e.g., removing white spaces, changing case, removing special characters, etc.) and a search for the normalized string value can be performed on the category matching the key as indicated in the key repository110(e.g., name, email, address, phone number, etc.).

In various embodiments, the key repository110includes any database or other storage system that supports indexing. For example, the key repository can include any database such as a Structured Query Language (SQL) database or a non-SQL database. The key repository110, in at least one embodiment, provides a repository for keys that can be searched from specific values and/or string values. In addition, the set of profiles114A-114N includes semi-structured information about a particular entity in accordance with at least one embodiment. Furthermore, in some examples, a standard profile scheme is used containing one or more fields, such as phone numbers, email addresses, names, and other data. In various embodiments, data obtained from the data objects104is retrieved and converted to the standard format regardless of the source102.

In various embodiments, a profile object is a single unit of information known about a profile (e.g., data object associated of a profile). Furthermore, in various embodiments, a particular profile includes a set of profile objects that includes data associated with an entity. Such data, in an example, can include information about a phone call, a ticket, a case, a click-stream record from a website, name, address, phone number, other contact information, order history, promotional material, support information, sales information, marketing information, biographical data, historical data, or any other data that can be associated with an entity. As described in the present disclosure, profile objects, in one example, can be obtained from a semi-structured JSON document. Furthermore, in various embodiments, the profile objects can be associated with type information and/or field information. In such embodiments, the type and/or field refers to a particular location and/or structure as indicated in an object mapping described in greater detail below in connection withFIG.4. In one example, the object mapping defines how that specific type of data object (e.g., contact cards, call logs, etc.) should be ingested either into a profile or as a separate data object to be linked or associated with a profile. In addition, in various embodiments, the object mapping indicates to the ingestion service106how to ingest a specific type of data object. For example, the object mapping indicates how data should be populated from the data objects (e.g., of the particular type indicated) and ingested into the standardized or normalized data objects and/or profiles, what fields should be indexed in the data object, and how those fields should then be used to assign the data object a specific profile.

In various embodiments, the data object mapping indicates a conversion schema that maps particular data objects104, types of data objects104, data within the data objects104, and/or fields within the data objects104to the set of profiles114A-114N maintained by the system (e.g., profile service116). Data objects104, in various embodiments, include various semi-structured data objects such as JSON blobs, XML documents, of other structured data or unstructured data. An example is illustrated by the following pseudo-code of a data object:

In an embodiment, data object mapping defines a schema for mapping or otherwise converting values within the data object104to values within profiles114A-114N and/or standardized data objects such as any of data objects118-126. In addition, the data object mapping, in various embodiments, defines indexing for keys (e.g., the set of keys112A-112N) associated with the profiles114A-114N and/or standardized data objects such as any of data objects118-126. In one example, the following pseudo-code shows that incoming data object mapping into a particular profile and indexing PersonalEmailAddress, fullName, and accountId (which is a unique key relative to the set of keys):

In this example, “email” and “fullname” are indexed, but are not used to search for the profiles114A-114N. Furthermore, in this example, the “account” key is indicated as a unique key. In various embodiments, any time a particular data object with the same “account” value is ingested, the ingestion service106or other service, overwrites the previous value with the same “account” value.

FIG.2is a block diagram illustrating an environment200in which an ingestion service206ingests data objects from various sources202A &202B to populate a set of profiles214A-214N in accordance with at least one embodiment. In various embodiments, a computing resource service provider220provides entities with computing resources to perform various operations as described in the present disclosure. For example, the computing resource service provider220provides computational and storage resources to allow an entity to maintain the set of profiles214A-214N and ingest data objects (not shown inFIG.2for simplicity) which can be used to update the set of profiles214A-214N and related data objects218-226. In some cases, data objects218-226may include one or more aspects of data objects118-126described above in reference toFIG.6. Furthermore, the set of profiles214A-214N, in at least one embodiment, includes a logical container for information associated with a single entity or user as described above in connection with the set of profiles114A-114N illustrated inFIG.1.

The computing resource service provider220may provide a variety of services to the entity and the entity may communicate with the computing resource service provider220via an interface, which may be a web service interface or any other type of user interface. As illustrated inFIG.2, server computer systems212, in accordance with an embodiment, provide the interface for the services of the computing resource service provider220as well as execute the services themselves. In one example, each service has a separate interface. In other examples, subsets of the services have corresponding interfaces in addition to or as an alternative to the interface described above. In an embodiment, the entity is an organization that utilizes one or more of the services provided by the computing resource service provider220to maintain and deliver information to its employees, which may be located in various geographical locations. For example, a profile service as described above in connection withFIG.1, provides support agents with information associated with the profiles214A-214N to help users troubleshoot and correct various issues.

In another example, the entity utilizes the services of the computing resource service provider220to provide content from the sources202A and/or202B for ingestion by the ingestion service206. As shown inFIG.2, the sources202A and/or202B communicate with the computing resource service provider220through a network204, whereby the network204may be a communication network, such as the Internet, an intranet or an Internet service provider (ISP) network in accordance with an embodiment. In one example, communications from the sources202A and/or202B to the computing resource service provider220cause the computing resource service provider220and/or services thereof, such as the ingestion service, to operate in accordance with one or more embodiments described in the present disclosure or a variation thereof. For example, data objects from the sources202A and/or202B are obtained by the server computer systems212of the computing resource service provider220and stored by a storage service208such that the data objects are accessible by the ingestion service206.

The computing resource service provider220may provide various computing resource services to the entity. The services provided by the computing resource service provider220, in this example, include a storage service208. It is noted that not all embodiments described herein include all the services described with reference toFIG.2and additional services may be provided in addition to or as an alternative to services explicitly described. As described herein, each of the services may include one or more web service interfaces that enable the entity and/or other services to submit appropriately configured API calls to the various services through web service requests. In addition, in various embodiments, each of the services include one or more service interfaces that enable the services to access each other (e.g., to enable the ingestion service206to store data in or retrieve data from the storage service208and/or to access one or more databases provided by a database service).

In various embodiments, the storage service208comprises one or more computing resources that collectively operate to store data for the entity and/or other services using various storage devices (and/or virtualizations thereof). For example, the storage service208operates using computing resources (e.g., databases) that enable the storage service208to locate and retrieve data quickly and provided data in response to requests for the data. In an embodiment, the storage service208maintains stored data in a manner such that, when a request for a data object is retrieved, the data object can be provided (or streaming of the data object can be initiated) in response to the request. As noted, data stored in the storage service208, in an example, is organized into data objects.

The data objects, in various embodiments, have arbitrary sizes except, perhaps, for certain constraints on size. Thus, the storage service208stores numerous data objects of varying sizes from the sources202A and/or202B in accordance with an embodiment. In various embodiments, the storage service208operates as a key value store that associates data objects with identifiers of the data objects which are used by the entity and/or other services to retrieve or perform other operations in connection with the data objects stored by the storage service208. For example, the ingestion service206obtains a set of identifiers associated with data objects provided by the sources202A and/or202B and stored by the storage service208. In such examples, the identifiers are placed in a queue and, when the ingestion service206ingests the data objects, the identifiers are retrieved from the queue and used to obtain the data objects (e.g., an API call to the storage service) from the storage service for ingestion.

In various embodiments, a notification service (not illustrated inFIG.2for simplicity) comprises a collection of computing resources collectively configured to provide notifications and/or topics to which entities and/or other services can subscribe to receive notification. For example, the ingestion service206, via the notification service, receives a notification when the sources202A and/or202B provide data objects for ingestion (e.g., once the data objects have been received by the server computer systems212and/or stored by the storage service208). In an embodiment, the notification service is used to generate topics for which entities and/or other services seek to receive notifications, execute applications, subscribe to topics, publish messages, or obtain delivery of the messages over a protocol of choice (e.g., hypertext transfer protocol (HTTP), e-mail, short message service (SMS), etc.). The notification service, for example, provides a “push” notification mechanism without the need to periodically or aperiodically check or “poll” for new information and updates. The notification service, in other embodiments, is used for monitoring applications by the ingestion service, workflow systems, time-sensitive information updates, mobile applications, and other services.

As described above, in various embodiments, the ingestion service206obtains a set of keys (not shown inFIG.2for simplicity) from the data objects in order to associate the data object with a single profile of the set of profiles214A-214N. In addition, the set of keys are indexed and stored in a key repository210. The key repository, in an embodiment is provided by a database service. The database service, in one example, is a collection of computing resources that collectively operate to run one or more databases. The ingestion service206, in such examples, operates and manages a database (e.g., the key repository210) from the database service by utilizing appropriately configured API calls. This, in turn, allows the ingestion service206to maintain and potentially scale the operations in the key repository210in accordance with an embodiment. Other services of the computing resource service provider220, in various embodiments, include, but are not limited to, object-level archival data storage services, services that manage and/or monitor other services.

In various embodiments, unless otherwise stated or clear from context, the term “service” is understood to be a computer system program, process, client, server, service, application, module, operating system entity, controlling domain, communication node or collection of these and/or other such computer system entities. Furthermore, in an example, a “service” is a client and/or a server configured to send and/or receive communications, data, requests, and/or other such requests from other services within an environment.

FIG.3illustrates two examples of profiles302,316storing data objects in a hierarchical way. In the example illustrated, profile302may include two distinct contacts304,312, each associated with one or more different data object types, such as one or more of an order data object306, a case data object308,314, and an asset data object314. As used herein, a profile may be a collection of data objects, and may be ingested in a similar way as other data objects to form various relationships between the different data objects.

In the example illustrated, all of the data objects304-314of profile302may be accessed when the profile302is accessed, such that no restrictions are placed on accessing any of data objects304-314. In another example of a profile316, various data objects318-328may be organized in a similar way. However, in this example, one or more restrictions, such as access or modify restrictions, may be placed on some of the data objects, such that some of the data objects may not be access from or through other data objects, when appropriate permissions are not in place. For example, data objects318-324may be placed in a restricted group330. In some cases, when another data object is accessed, such as contact326, group330may not be made accessible or returned in response to a query to access the contact data object326. However, in cases where profile16is accessed, group330of data objects may be accessed or returned. These various restrictions may be implemented by an identity access management system or service, as known in the art.

In order to associate these various data objects304-314in a hierarchical structure, one or more data fields may be added to the data objects as they are ingested to form standardized data objects. In one example, two data fields may be added, one indicating whether the given data object is or refers to a primary profile, and a second indicating the profile of a parent profile, in the case that the data object is not a parent or primary profile.

In some aspects a field, such as a Boolean field, or other indication, may indicate whether a given data object or collection of data objects (referred to herein both as a data object for simplicity) is a parent or primary profile, such that it should form its own separate record or item in when ingested. If a data object is a parent or primary profile, this field, which may be referred to as an isParentProfile field, may be set to true. If the data object is not a parent profile, it may be set to a default value or null. Another field (e.g., a parentProfileId field that can include any string value) may be included that indicates the name or identifier of the parent profile. In some cases, this field may be null when the data object is a parent profile and may include a parent profile ID when the data object is a child profile/contact data object to be associated with a primary profile. In some cases, the isParentProfile field may be set to true for a hierarchical profile and may be set to false for a standalone profile, or one that is not associated with any other contact data objects/profiles.

In some examples, when a data object is ingested and indicates a contact data object and refers to a parent profile ID (e.g., these indicators collectively translating to this contact being a child profile of an existing profile), then the fields of the parent profile may be modified to reflect that the profile is a parent profile. In addition, a key indicating or identifying the child profile/contact data object may be appended to the parent profile. The child data object, when it is converted into a standardized format, may also be modified to indicate that it is not a parent profile, but include the parent profile ID of the indicated parent profile. In this way, both data objects may be linked, such that when accessed, one may refer to the other and both may be presented to a user, for example, in response to a query of either.

In some cases, various other types of data objects, such as any of data objects306-310,314, and320-324,328may be associated with a profile (e.g., parent profile302,316), and a child profile or contact data object304,312,318,326. In some cases, the key or identifier of the child profile/contact data object304,312,318,326may be associated with the various data objects306-308,314and320-324,328to form various different relationships and hierarchies. In the case that a child profile identifier or key is not associated with a data object, the data object may simply be associated with a profile.

In some aspects, various restriction may be placed on how different data objects may be associated with one another, to facilitate better management of the data objects. In some examples, the relationship between one or more contact data objects or child profiles and parent profiles may be restricted. For example, in some cases, a parent profile may be able to be associated with multiple child profiles/contact data objects. In some aspects, a child profile may have or be associated with only one parent profile. Similarly, a child profile may not be a parent profile of another child, and a parent profile may not have a parent of its own. It should be appreciated that these specific restrictions may be useful for certain situations; however, the described techniques are not so limited. In some aspects, some or no restrictions may be implemented for different data objects, to provide more flexibility in data organization.

FIG.4is a diagram400illustrating an object mapping402used to map data included in a data object to a data storage schema used to maintain data in a profile404or other data object. In various embodiments, the profile404includes a data storage model that represents how data is stored within the profile404. For example, as illustrated inFIG.4, the profile404includes a set of fields (e.g., “account,” “email,” etc.) that indicate a structure and/or location of data stored within the profile404. In addition, the object mapping402provides a mapping and/or translation for data included in a particular type of data object to fields within the profile404in accordance with an embodiment. In one example, the object mapping402is associated with a customer list data object and provides a mapping of data within the customer list data object (e.g., account number, name, address, etc.) to corresponding fields in the profile404.

In various embodiments, a profile parser or other source code executed by a computer system, converts data from an incoming data object (e.g., a data object being ingested by the ingestion service as described above) into the data storage model used by the profile404. In addition, both the data object and any updates (if the data object includes data to update one or more fields in the profile404) are persisted to the profile404in accordance with an embodiment. In one example, the data object is persisted within the profile along with any updates to one or more fields of the profile404. In another example, an identifier or other data suitable for obtaining the data object (e.g., via an API call to a data storage service) is persisted in the profile404along with any updates to one or more fields of the profile404. In addition, in various embodiments, the profile parser updates a set of indexes maintained in a key repository as described above, for the keys obtained from the data object and/or keys corresponding to fields that have been updated in the profile404.

In an embodiment, the object mapping402defines or indicates where the keys are located within particular data objects and/or types of data objects. For example, the object mapping402provides a definition of one or more fields in an ingested data object that are to be mapped or otherwise assigned to a particular location and/or fields within the profile404. In an embodiment, the object mapping402indicates to the ingestion service or other service fields in an ingested source data object to assign or otherwise store in corresponding fields in the profile404. Various sources can define or otherwise provide the object mapping402including users, service providers, or other entities in accordance with an embodiment. For example, a cloud contact center can provide a mapping of contact records to profiles. In some cases, the object mapping may also include or be referred to as a template.

Furthermore, the object mapping402, in an embodiment, includes information indicating fields in the data object that are to be indexed when ingested. For example, when data from a data object is ingested by the ingestion service, the indexed fields are determined based at least in part on information included in the object mapping402. Indexing the keys, in various embodiments, allows the ingestion service to determine which profile a specific data object belongs to and/or is associated with (e.g., by searching the keys) and what values can be used to find the profile404. For example, a user's name can be indexed, which allows agents (e.g., through the profile service or other service that can search the index) to find all profiles that belong to the user with that specific name.

As illustrated inFIG.4, the key can be made up of one or more fields in accordance with an embodiment. The object mapping402, in such embodiments, includes at least one key that uniquely identifies the profile404so that it can be updated by specifying the same value of this field (these requirements can be satisfied with a single key). For example, the profile404includes an “account” field for which each value is unique to a single profile. In various embodiments, a field definition specifies how to read a value for that field name from a data object (e.g., a data object of a particular type). In other embodiments, the field definition also specifies what kind of data is stored in the field. For example, as illustrated inFIG.4“Source:” specifies the data object (e.g., a JSON blob) being accessed; “Target:” specifies where in the profile404the data of this field should be mapped; “ContentType:” specifies the type of data being ingested.

In an embodiment, the following content types can be a specified string, number, phone number, email address, street address, name, and account number. In one example, if no “ContentType” is specified, a string value is used. Furthermore, “ContentType,” in an embodiment, is used to determine how to index the value so it can be searched for. For example, if “ContentType” is set to phone number, a phone number is processed which it can search for in various formats (e.g., the string “+15551234567” matches “(555)-123-4567”).

In various embodiments, the key contains one or more fields that together define the key that can be used to search for data, data objects, and/or the profiles associated with the key. In one example, the key repository is searched for using an API call and the key. As described above, the key can also be defined to uniquely identify the profile404or uniquely identify the data object itself in accordance with an embodiment. Furthermore, as described above, in at least one embodiment, key names are global to a domain and/or logical groupings of profiles. In other embodiments, if two keys share the same name in association with two different fields and/or data objects within the object mapping402, the keys can be used to potentially link profiles together between different fields. For example, if the keys match between two distinct data objects, the ingestion service places the two data objects in the same profile (e.g., a phone number specified in one type of data object would be related to the same phone number specified in another type of data object).

In various embodiments, identifiers associated with keys allow the ingestion service or other service to set attributes on a particular key. For example, the identifier “profile” causes the key to be treated as a unique identifier for the profile (e.g., a search for a key marked a profile returns a single profile). Therefore, in such embodiments, if a key marked as “profile” is included in two or more profiles, the profiles will be merged. In yet other embodiments, keys can be indicated as “unique.” In such embodiments, the “unique identifier” is specified by exactly one index for the field. This key is used to uniquely identify data of a particular field for either fetching profiles or updating a field based at least in part on a data object being ingested.

In yet other embodiments, the identifier “look up” indicates that the key is not stored after ingesting the data object. For example, the key is only to be used for determining the profile during ingestion and the key value is not associated with the profile during ingestion. In an embodiment, the identifier “new only” causes the ingestion service or other service to use the key to generate a new profile if a profile matching the key does not already exist before the data object is ingested, otherwise the key is only used for matching data objects to profiles. In another embodiment, the identifier “secondary” indicates that during the matching of a data object to a profile, the ingestion service first looks up all other keys prior to searching any keys marked “secondary.” In addition, in various embodiments, an identifier can be assigned to a key that prevents the key from being used to generate new profiles.

As described in more detail above, two additional fields may be added to the profile data object404that is generated using the object mapping402. These two data fields may include an isParentProfile field and a parentProfileId, or similar field that indicates similar information, to facilitate data objects hierarchies, such as profile hierarchies and/or data object hierarchies within various profiles.

In some aspects, an object mapping402may be similarly generated for various data objects of different types, such as any of a contact data object (e.g., a child profile), one of an asset, case, or order data object type, or for various other configurable data object types. In some cases, a mapping may correspond to a contact data object or child profile. In these cases, the mapping may incorporate one or more aspects of the profile mapping described above, but may additionally include an indication of whether the data object is a child profile and an indication of a related profile, such as an identifier of a parent profile. In some cases, these indications may include an isParentProfile field and a parent ProfileId. In some cases, a further indicator of a type of data object may also be included, such as whether the data object is a profile/contact data object or another type of data object (e.g., contact data object or not, or specifying one of a variety of different types, such as asset, case, or order). This type indicator may be used to determine if a data object can then be organized in a way where other data objects are organized in a hierarchy below or subordinate to that data object. In some cases, each of an asset, case, or order data object may have its own mapping, similar to the object mapping402, or may share some or all aspects of a common data mapping, such as via use of a type indication in the mapping.

As used herein, a standardized data object may refer to the output or data structure that is produced after a data object is modified by object mapping402. In some cases, the standardized data object may be a profile, such as profile404, or may be a standardized data object, such as a standardized contact data object (e.g., child profile) which may be similar or the same as a profile, but may include a contact identifier. In other cases, the standardized data object may be of a different type than a standardized contact data object, such as one or an asset, case, or order standardized data object, or a standardized data object of a different type which may be custom defined. As also used herein, a standardized data object may refer to a data object that either has been modified or has been confirmed to already follow a certain format. The format may include relative locations of certain pieces of information (e.g., name, address, order number, item purchased, case number, asset identifier, etc.) for the different types of standardized data objects, certain types of values for certain data fields, inclusion of additional data fields, and so on.

FIG.5shows a process500for ingesting a data object in accordance with at least one embodiment. The process500, in an embodiment, is performed by an ingestion service or other service as described above. Now referring toFIGS.5-7, the operations of processes500and600, described in the present disclosure, in various embodiments, include a computing process that is performed using any combination of hardware, firmware, and/or software. The various functions, processes, and/or operations described in the present disclosure may be carried out by a processor executing instructions stored in memory. The processes, for example, are embodied as computer usable instructions stored on computer storage media. In addition, in some embodiments, the processes are provided by a standalone application, a service or hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few. In addition, the processes500,600, and700are described, by way of example, with respect to the computer system ofFIG.7. However, these processes may additionally or alternatively be executed by any one system, or any combination of systems, including, but not limited to, those described in the present disclosure. In addition, various operations of the processes500,600, and700may be performed in different and/or alternative orders, performed in serial or parallel, or omitted entirely.

Returning toFIG.5, the system executing the process500, at operation502obtains a data object. In various embodiments, the data object is obtained from a source as described above. In addition, in various embodiments, the data object is maintained by a storage service that is accessible to the system executing the process500. At operation504, the system executing the process500determines if the data object includes one or more non-secondary keys. As described above, keys indicated as secondary, in an embodiment, are used to search for a corresponding profile only if the data object does not contain any non-secondary keys. If the data object includes at least one non-secondary key, the system executing the process500, in an embodiment, continues to operation508and searches the non-secondary keys. However, if no non-secondary keys are included in the data object, the system executing the process500, in an embodiment, proceeds to operation506and searches the secondary keys.

Returning to operation508, the system executing the process500, in an embodiment, searches a key repository for the non-secondary keys. As described above, an object mapping indicates the location of keys included in particular types of data objects. For example, the system executing the process500obtains the object mapping associated with the data objects and extracts the string values associated with the keys (e.g., name, phone number, account number etc.). In various embodiments, the system executing the process500, then searches the key repository of profiles matching the keys extracted from the data object. Similarly, in operation506, the system executing the process500, in an embodiment, searches the repository for profiles matching the secondary keys extracted from the data object if no non-secondary keys were extracted.

At operation510, the system executing the process500, in various embodiments, determines if a profile is found matching at least one key. In various embodiments, the system executing the process500searches the keys in serial and terminates the search once a single profile is returned matching a particular key being searched. In some cases, performance of operations504and506may be optional, such that process500may be performed without searching for any secondary keys to identify a profile.

In either case, if a single profile is determined (e.g., returned in the search results associated with a particular key), the system executing the process500, continues to operation514. In operation514, the system may determine if the data object includes an indication of the type of data object/information that the data object includes. In some cases, operation514may include searching or a type indictor in the data object, as described above in reference toFIGS.3and4. If no type information is identified, at operation514, the system may then proceed to operation520, in which the data object may be ingested in its native format and associated with the identified profile. In some aspects, operation520may additionally or alternatively include associating one or more keys or identifiers with the data object, a described in more detail above, such that the data object may be individually searchable within the database storing the profiles.

If, at operation514, the system determines that the data object is associated with or otherwise indicates a data object type, process500may proceed to operation522, in which the system may convert the data object into a standardized data object format based on the type of data object indicated in the data object. In some cases, the mapping may be performed using a data object mapping, such as object mapping402described above in reference toFIG.4. In yet some cases, the object mapping may be referred to as a template, and may be selected from a plurality of templates, based on the type of data object and/or a source of the data object. In these cases, the source of the data object may be determined from the data object itself, such as included by the source itself, or it may be appended to the data object during the ingestion process by the system upon identifying the source from which the data object was received.

Next, at operation524, the system may associate the standardized data object with the profile determined in prior operations. Operation524may also include defining one or more keys for the standardized data object, such that the standardized data object may be individually searchable separate from the profile. In some cases, the key or keys may be defined as one or more data fields of the data object. In yet some instances, the key or keys of the standardized data object may be associated with the profile, such that a search for the profile may return the standardized data object as well. In some cases, the data field used to define the key or keys identifying the data object may also include information indicating the type of the data object, such that the key itself identifies the type of data object.

In some cases, if no profile is returned from the search results, at operation512, process500may proceed to operation512, in which that het system executing the process500, determines if at least one key allows for a new profile to be created. At operation512, if the system determines a key allows a new profile to be created, the process500continues to operation516. At operation516, the system creates a new profile including the data extracted from the data object and persists the data object. For example, a new profile is created, and information extracted from the data object is associated with a user (e.g., name, phone number, account number etc.) and are persisted in the profile. Returning to operation512, if the system executing the process500determines that none of the keys allow for the creation of a new profile, in an embodiment, the process500continues to operation518. At operation518, the system executing the process500, in an embodiment, returns information indicating that the data object could not be ingested. For example, a notification is transmitted to a user associated with an account of a profile service indicating the data object could not be ingested.

In some cases, a data object may be ingested that references a profile and another data object, such as a contact data object or child profile. In these scenarios, the data object may be ingested and associated with a profile, such as via process500described above. In addition, in some cases, the data object may also reference another data object, such as a contact data object, to associate the data object with. In this case, during the ingestion process, the data object may also be modified to include an identifier or key of the contact data object to which it is to be associated with. When the contact data object or profile are subsequently queried, the data object may then be provided with either or both of the contact data object and profile. In instances where a data object references a contact data object/child profile that cannot be found, the data object may be associated with the profile only.

FIG.6shows another process600for ingesting a data object into a profile and data object hierarchy. Process600, in an embodiment, is performed by a profile service or other service as described above. Process600may incorporate one or more operations of process500described above, and for the sake of brevity, those operators will not be described in great detail again here.

Process600may begin at operation602, in which the system executing process600may obtain a data object, such as from one of a variety of different sources. The system may then determine, at operation604, if a profile, which is indicated in the data object, can be found in a database of profiles accessible by the system. If not, a new profile may be created and the data object persisted, at operation606, as descried in greater detail above. If the referenced profile is found, at operation604, process600may proceed to operation608, in which it may be determined if the data object includes an indicator of a type of data object. If the data object does not include type information, process600may proceed to operation610, in which the data object (in its unaltered or unconverted state), may be associated with the profile and keys for the data object defined. In some cases, operation610may additionally include appending the data object key or keys to the profile.

If the data object is determined to include an indicator of a type of the data object, at operation608, process600may proceed to operation624, in which it may be determined if the data object already exists in the database. In some cases, operation624may include searching an index for a key or set of keys associated with the data object, such as may be specified by an object mapping specific to the source of the data object, the type of the data object, or a combination of the two. If the data object is found to already exist, the existing record or instance of the data object may be updated, at operation626, to include data that is contained in the data object that is different than the data object that already exists in the database/is indexed by the system.

However, If the data object is not found, at operation624, process600may proceed to operation612, in which it may be determined if the data object includes an indication of a contact data object type (e.g., child profile). If the data object is not of the contact data object type, process600may proceed to operation614, in which an object mapping/template may be selected based on at least one of the data object itself (e.g., type information or other information of the data object) and/or the source of the data object, as described in greater detail above. Next, at operation616, one or more of the data fields of the data object may be mapped into the selected template/object mapping to form a standardized data object. The standardized data object may then be associated and stored with the profile, and one or more keys that identify the standardized data object may be defined, as described in greater detail above.

Returning back to operation612, if the data object is determined to indicate a contact data object type, process may proceed to operation620. At operation620, the system may determine if the proposed relationship is allowed by the system, such as by comparing the proposed relationship between the data object and the specified profile. In some cases, this may include determining the values stored the isParentProfile and parentProfileId fields, as described in greater detail above. If the sParentProfile is a default or null value, and the parentProfileId field identifies a profile that does not itself have a parent, then the relationship may be allowed. In other cases, such as when a parent profile that has a child profile tries to associate itself with another parent profile, or other circumstances as described above, the proposed relationship may be disallowed, and an error message returned. It should be appreciated that operation620is optional, such that process600may be performed without operation620and the associated verification process.

In either case, process600may then proceed to operation622, in which the data fields of the contact data object may be mapped to a standardized contact data object, and subsequently associated with the profile, at operation618. Operation618may also include defining one or more keys that identify the standardized data object and associating those one or more keys with the standardized contact data object and/or profile, as described in greater detail above.

FIG.7shows a process700for updating a key repository in accordance with at least one embodiment. The process700, in an embodiment, is performed by a profile service or other service as described above. At operation702, the system executing the process700, in an embodiment, obtains a key from a data object. As described above, the key, in an example, includes a string value extracted from the data object that is used to search for a matching value stored in a profile or other data object (e.g., a data object that has been converted into a standard or normalized of mat, which may be referred to herein as a standardized data object). At operation704, the system executing the process700, in an embodiment, determines if the key is assigned the identifier “lookup.” As described above, identifiers can be assigned to a particular key to manage how the keys are ingested and indexed by the system executing the process700. Returning to operation704, if the key is identified as lookup only, the system executing the process700continues to operation706. In operation706, the system executing the process700, in an embodiment, does not persist the key in the index and the process700is terminated for that particular key (the process may be repeated for additional keys extracted from the data object).

However, if the key is not lookup only, the process continues to operation710, at operation710, the system executing the process700, in an embodiment, determines if the key is indicated as “new.” If the key is not indicated as new only, the process700continues to operation712. At operation712, the system executing the process700, in an embodiment, persist the key in the index. For example, the system executing the process700, updates the key repository with the key and information indicating a profile or data object for which the key is associated with. However, at operation710, if the identifiers associated with the key indicates a new profile or data object, the process700continues to operation714. At operation714, the system executing the process700, in an embodiment, determines if the key has been associated with a new profile or data object. For example, a search of the key did not return a matching profile or data object and a new profile or data object was created and associated with the key. At operation714, if a new profile or data object was created, the system executing the process700, continues to operation712and the key is persisted in the index. However, at operation714, if the key is not associated with a new profile or data object, the system executing the process700, continues to operation706and the key is not persisted in the index.

FIG.8illustrates aspects of an example system800for implementing aspects in accordance with an embodiment. As will be appreciated, although a web-based system is used for purposes of explanation, different systems may be used, as appropriate, to implement various embodiments. In an embodiment, the system includes an electronic client device802, which includes any appropriate device operable to send and/or receive requests, messages, or information over an appropriate network804and convey information back to a user of the device. Examples of such client devices include personal computers, cellular or other mobile phones, handheld messaging devices, laptop computers, tablet computers, set-top boxes, personal data assistants, embedded computer systems, electronic book readers, and the like. In an embodiment, the network includes any appropriate network, including an intranet, the Internet, a cellular network, a local area network, a satellite network or any other such network and/or combination thereof, and components used for such a system depend at least in part upon the type of network and/or system selected. Many protocols and components for communicating via such a network are well known and will not be discussed herein in detail. In an embodiment, communication over the network is enabled by wired and/or wireless connections and combinations thereof. In an embodiment, the network includes the Internet and/or other publicly addressable communications network, as the system includes a web server806for receiving requests and serving content in response thereto, although for other networks an alternative device serving a similar purpose could be used as would be apparent to one of ordinary skill in the art.

In an embodiment, the illustrative system includes at least one application server808and a data store810, and it should be understood that there can be several application servers, layers or other elements, processes or components, which may be chained or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data store. Servers, in an embodiment, are implemented as hardware devices, virtual computer systems, programming modules being executed on a computer system, and/or other devices configured with hardware and/or software to receive and respond to communications (e.g., web service application programming interface (API) requests) over a network. As used herein, unless otherwise stated or clear from context, the term “data store” refers to any device or combination of devices capable of storing, accessing and retrieving data, which may include any combination and number of data servers, databases, data storage devices and data storage media, in any standard, distributed, virtual or clustered system. Data stores, in an embodiment, communicate with block-level and/or object-level interfaces. The application server can include any appropriate hardware, software and firmware for integrating with the data store as needed to execute aspects of one or more applications for the client device, handling some or all of the data access and business logic for an application.

In an embodiment, the application server provides access control services in cooperation with the data store and generates content including but not limited to text, graphics, audio, video and/or other content that is provided to a user associated with the client device by the web server in the form of HyperText Markup Language (“HTML”), Extensible Markup Language (“XML”), JavaScript, Cascading Style Sheets (“CSS”), JavaScript Object Notation (JSON), and/or another appropriate client-side or other structured language. Content transferred to a client device, in an embodiment, is processed by the client device to provide the content in one or more forms including but not limited to forms that are perceptible to the user audibly, visually and/or through other senses. The handling of all requests and responses, as well as the delivery of content between the client device802and the application server808, in an embodiment, is handled by the web server using PHP: Hypertext Preprocessor (“PHP”), Python, Ruby, Perl, Java, HTML, XML, JSON, and/or another appropriate server-side structured language in this example. In an embodiment, operations described herein as being performed by a single device are performed collectively by multiple devices that form a distributed and/or virtual system.

The data store810, in an embodiment, includes several separate data tables, databases, data documents, dynamic data storage schemes and/or other data storage mechanisms and media for storing data relating to a particular aspect of the present disclosure. In an embodiment, the data store illustrated includes mechanisms for storing production data812and user information816, which are used to serve content for the production side. The data store also is shown to include a mechanism for storing log data814, which is used, in an embodiment, for reporting, computing resource management, analysis or other such purposes. In an embodiment, other aspects such as page image information and access rights information (e.g., access control policies or other encodings of permissions) are stored in the data store in any of the above listed mechanisms as appropriate or in additional mechanisms in the data store810.

The data store810, in an embodiment, is operable, through logic associated therewith, to receive instructions from the application server808and obtain, update or otherwise process data in response thereto, and the application server808provides static, dynamic, or a combination of static and dynamic data in response to the received instructions. In an embodiment, dynamic data, such as data used in web logs (blogs), shopping applications, news services, and other such applications, are generated by server-side structured languages as described herein or are provided by a content management system (“CMS”) operating on or under the control of the application server. In an embodiment, a user, through a device operated by the user, submits a search request for a certain type of item. In this example, the data store accesses the user information to verify the identity of the user, accesses the catalog detail information to obtain information about items of that type, and returns the information to the user, such as in a results listing on a web page that the user views via a browser on the user device802. Continuing with this example, information for a particular item of interest is viewed in a dedicated page or window of the browser. It should be noted, however, that embodiments of the present disclosure are not necessarily limited to the context of web pages, but are more generally applicable to processing requests in general, where the requests are not necessarily requests for content. Example requests include requests to manage and/or interact with computing resources hosted by the system800and/or another system, such as for launching, terminating, deleting, modifying, reading, and/or otherwise accessing such computing resources.

In an embodiment, each server typically includes an operating system that provides executable program instructions for the general administration and operation of that server and includes a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, if executed by a processor of the server, cause or otherwise allow the server to perform its intended functions (e.g., the functions are performed as a result of one or more processors of the server executing instructions stored on a computer-readable storage medium).

The system800, in an embodiment, is a distributed and/or virtual computing system utilizing several computer systems and components that are interconnected via communication links (e.g., transmission control protocol (TCP) connections and/or transport layer security (TLS) or other cryptographically protected communication sessions), using one or more computer networks or direct connections. However, it will be appreciated by those of ordinary skill in the art that such a system could operate in a system having fewer or a greater number of components than are illustrated inFIG.8. Thus, the depiction of the system800inFIG.8should be taken as being illustrative in nature and not limiting to the scope of the disclosure.

The various embodiments further can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices or processing devices that can be used to operate any of a number of applications. In an embodiment, user or client devices include any of a number of computers, such as desktop, laptop or tablet computers running a standard operating system, as well as cellular (mobile), wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols, and such a system also includes a number of workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. In an embodiment, these devices also include other electronic devices, such as dummy terminals, thin-clients, gaming systems and other devices capable of communicating via a network, and virtual devices such as virtual machines, hypervisors, software containers utilizing operating-system level virtualization and other virtual devices or non-virtual devices supporting virtualization capable of communicating via a network.

In various embodiments described throughout this disclosure, computing resources are configured to perform tasks (e.g., generate data, process data, store data, route messages, transmit data, submit requests, process requests) by loading computer-readable executable instructions into memory that, as a result of execution by one or more processors, cause the one or more processors to execute instructions to perform tasks. In at least one embodiment, a computer system is configured to perform a task through a software application that controls the execution of specific commands, requests, tasks, jobs, and more. A computer system may be configured to execute computer-readable instructions encoded in a software application by loading executable code of the software application into memory and using one or more processors of the computer system to run the executable instructions.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the subject matter set forth in the claims.

Other variations are within the spirit of the present disclosure. Thus, while the disclosed techniques are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the subject matter recited by the claims to the specific form or forms disclosed but, on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of this disclosure, as defined in the appended claims.

The use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended merely to better illuminate various embodiments and does not pose a limitation on the scope of the claims unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of subject material disclosed herein.

Embodiments of this disclosure are described herein, including the best mode known for carrying out inventive concepts described herein. Variations of those embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the scope of the present disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.