Apparatus and method for predicting and modeling resource allocation, and for generating, adjusting, and approving resource acquisition offers.

Abstract

In an environment where the demand, usefulness, and perceived value of resources change over time, the present invention provides devices, methods, and computer program products for automated prediction and modeling that improve one or more channels and associated conditions through which resources are directed to users. [Solution] A resource characteristics dataset from a third party with questionable reliability and a resource characteristics dataset from a distributed user platform are input into an exception detection model, and the two datasets are integrated and compared. Specifically, the difference (offset) between the two datasets is identified, and periods in which the deviation of that offset falls outside the normal range are detected as exception periods. Then, these exception periods are removed from the third-party data to create an updated dataset, and a reliable resource characteristics dataset is generated based on this updated dataset.

Description

Technical Field

[0001] Cross-reference to related applications is described. This application claims the benefit of U.S. Provisional Patent Application No. 62 / 673,325, filed May 18, 2018, which is hereby incorporated by reference in its entirety as if fully set forth herein.

[0002] Exemplary embodiments generally relate to the use of predictive models of machine learning for implementing efficient allocation of time-dependent resources. Exemplary implementations specifically target systems, methods, and apparatuses for predicting and modeling future demand for time-dependent, value-degrading objects in an environment with resource constraints. Additional or alternative exemplary embodiments relate to improved generation of resource offsets, and / or improved visualization and display of such resource offsets for analysis, adjustment, and approval.

Background Art

[0003] Many of today's network environments are dynamically resource-constrained in that at least the need for resources and the nature of the resources required can change rapidly and significantly over time and geographically.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Some of the technical problems that impede the effective and efficient allocation of resources in such an environment worsen in situations where the supply, usefulness, and / or value of the resources required change over time. In addition, in this regard, the availability of resources for a particular time and / or geography can vary significantly. Technical problems in the editing, analysis, visualization, and manipulation of data associated with conventional systems impede efficient resource acquisition planning. The inventors of the present invention disclosed herein have identified these and other technical problems and developed the solutions described herein and referenced in other ways. [Means for solving the problem]

[0005] Accordingly, apparatus, computer program products, and methods according to exemplary embodiments are provided to enable efficient determination of one or more channels and / or associated conditions to which a particular set of resources can be effectively allocated. In this regard, the methods, apparatus, and computer program products of exemplary embodiments provide the creation of predicted channel and condition datasets that can be stored in a renderable object and otherwise presented to a user via an interface of a client device.

[0006] Furthermore, the exemplary embodiments of the methods, apparatus, and computer program products provide the use of machine learning models related to determining and retrieving predicted channel and conditional datasets, which are determined at least in part on contextual data associated with a specific set of resources to be distributed at a future time.

[0007] In an exemplary embodiment, a device is provided, the device including a processor and memory, the memory including instructions for configuring the device to: receive a request data object from a client device associated with a user; extract a request dataset from the message request data object, wherein the request dataset is associated with a first set of resources; receive a first context data object, wherein the first context data object is associated with one or more resource distribution channels; retrieve a predicted channel and condition dataset, wherein retrieving the predicted channel and condition dataset includes applying the request dataset and the first context data object to a first model; and generate a control signal to display a renderable object containing the predicted channel and condition dataset on the user interface of the client device associated with the user.

[0008] In another exemplary embodiment, a computer program product is provided, the computer program product comprising at least one non-transient computer-readable storage medium having computer executable program code instructions stored therein, the computer executable program code instructions comprising: receiving a request data object from a client device associated with a user; extracting a request dataset from the message request data object, wherein the request dataset is associated with a first set of resources; receiving a first context data object, wherein the first context data object is associated with one or more resource distribution channels; retrieving a predicted channel and condition dataset, wherein retrieving the predicted channel and condition dataset includes applying the request dataset and the first context data object to a first model; and generating a control signal to display a renderable object containing the predicted channel and condition dataset on the user interface of the client device associated with the user.

[0009] In another exemplary embodiment, a method is provided for determining anticipated future demand for resources in a dynamic environment, the method comprising: receiving a request data object from a client device associated with a user; extracting a request dataset from the message request data object, wherein the request dataset is associated with a first set of resources; receiving a first context data object, wherein the first context data object is associated with one or more resource distribution channels; retrieving a predicted channel and condition dataset, wherein retrieving the predicted channel and condition dataset includes applying the request dataset and the first context data object to a first model; and generating a control signal to display a renderable object containing the predicted channel and condition dataset on the user interface of the client device associated with the user. [Brief explanation of the drawing]

[0010] [Figure 1] Some embodiments of this disclosure illustrate exemplary systems in which they may operate. [Figure 2] The present disclosure illustrates block diagrams of exemplary devices for implementing a prediction system using dedicated circuitry, according to some embodiments of this disclosure. [Figure 3] The following are examples of block diagrams illustrating the functional overview of a system according to several embodiments of this disclosure. [Figure 4] The following are examples of data flow models according to several embodiments of this disclosure. [Figure 5] The following are examples of block diagrams illustrating the functional overview of another aspect of the system according to some embodiments of this disclosure. [Figure 6] A flowchart illustrating exemplary operations for generating resource allocation based on prediction conditions, according to some embodiments of this disclosure, is provided. [Figure 7]A flowchart illustrating exemplary operations for generating resource allocation based on prediction conditions, according to some embodiments of this disclosure, is provided. [Figure 8] Some embodiments of this disclosure illustrate another exemplary system in which they may operate. [Figure 9] The present disclosure illustrates block diagrams of exemplary devices for implementing a resource offer generation system using dedicated circuits, according to some embodiments of this disclosure. [Figure 10] The present disclosure illustrates data flow diagrams illustrating the steps for generating an optimal resource offer set via a resource offer generation system, according to some embodiments of this disclosure. [Figure 11] The present disclosure illustrates data flow diagrams illustrating the steps of rendering and / or adjusting resource offer sets, submitting adjusted resource offer sets for approval, and approving or rejecting adjusted resource offer sets, according to some embodiments of this disclosure. [Figure 12A] A flowchart illustrating the operational blocks in an exemplary process for generating a resource offer set, updating the resource offer set to create a refined resource offer set, and receiving an offer status indicator for the refined resource offer set, according to an exemplary embodiment of the present disclosure, is provided. [Figure 12B] A flowchart illustrating the operational blocks in an exemplary process for generating a trusted resource characteristics dataset from one or more untrusted third-party resource characteristics datasets and distributed resource characteristics sets, according to an exemplary embodiment of the present disclosure, is provided. [Figure 13] The exemplary embodiments of this disclosure illustrate exemplary analytical interfaces accessible via a dashboard, specifically, offer adjustment interfaces. [Figure 14] The exemplary embodiments of this disclosure illustrate another exemplary analytics interface accessible via a dashboard, specifically an offer approval interface. [Figure 15] The exemplary embodiments of this disclosure illustrate another exemplary analytical interface accessible via a dashboard, specifically a market comparison interface. [Modes for carrying out the invention]

[0011] While specific embodiments of this disclosure have been described using general terminology, the attached drawings, which are not necessarily drawn to a consistent scale, are referenced here. Hereinafter, several embodiments of the present disclosure are described in more detail with reference to the accompanying drawings, which show some, but not all, embodiments of the present invention. In fact, various embodiments of the present invention can be embodied in many different forms and should not be construed as being limited to the embodiments described herein, but rather these embodiments are provided to satisfy the legal requirements to which the present disclosure is applicable. Throughout, similar reference numbers refer to similar elements. Overview Various embodiments of this disclosure relate to improved apparatus, methods, and computer-readable media for predicting and determining the optimized allocation of resources in environments where resource demand, availability, usefulness, and / or value are dynamic. By modeling and predicting resource requirements, exemplary implementations of embodiments of the present invention can direct resources (which may be subject to depreciation, impairment, and / or other dynamic changes in usefulness or value) more quickly and efficiently to channels in which such resources can be optimally deployed. One environment recognized by the inventors in which resource demand, availability, usefulness, and value are each dynamic is the market environment involving the acquisition and resale of used mobile devices. In such an environment, the demand for a particular mobile device may fluctuate over time and vary significantly by region, so that demand may be higher in one place at a given time compared to another place at the same time or to the same place at a different time. Furthermore, in such an environment, the supply of a given mobile device can fluctuate based on several factors, while user requirements (such as those for the necessary functions of a mobile device) and the perceived value of a particular mobile device can fluctuate independently over time. In particular, since the value of a particular mobile device tends to decrease over time, delays in allocating a particular mobile device to a particular distribution channel tend to increase the likelihood that used mobile devices will become obsolete due to obsolescence, loss of perceived value, and / or other factors.

[0012] The inventors of the embodiments of this disclosure in this specification have recognized that one of the key factors in efficiently meeting the demand for a particular mobile device in a distribution market environment is the ability to predict and model user demand and perceived device value. Conventional approaches tend to react to existing conditions in the environment rather than predicting future conditions. As a result, decisions to deploy resources to a particular channel tend to be solely focused on meeting user needs and demands. Furthermore, under reactive approaches, delays are often introduced in the process of acquiring potentially desired devices and directing them to users who are looking for such devices. In particular, in situations where devices tend to become obsolete and depreciate in value over time, delays in device allocation can result in devices directed to a particular channel based on past conditions becoming useless, leading to a loss of relevance to existing market conditions at the time the resources were introduced to a given channel (e.g., used mobile devices in this environment), and a decrease in the value that could be realized from such devices.

[0013] As recognized by the inventors of the present disclosure herein, the technical challenges associated with predicting and modeling user needs and perceived device value are exacerbated by a wide range of information attenuation factors. In the case of mobile devices, one of the information attenuation factors in the market includes a wide range of similar but potentially non-identical devices. For example, many mobile device manufacturers assign different identification numbers or other indicators to mobile devices based on mobile networks, retailers, physical characteristics, markets, and / or other aspects associated with the initial sale of the mobile device. For example, the identification number used to identify a mobile device initially sold from a retail store associated with a certain mobile network provider may be different from the identification number of a mobile device initially shipped to a retail store associated with another mobile network provider, despite the fact that the two devices have the same functionality and can function equivalently across a wide range of networks. In some environments, the number of device identifiers can be in the tens of thousands or hundreds of thousands.

[0014] The information that can be used to predict and model user needs and perceived device values can be further obfuscated by large amounts of unscaled and / or heterogeneous data associated with each device and / or device identification number. For example, a predictive model that accurately and reliably identifies the channels to which a particular mobile device should be directed to meet user needs at a given time can use a range of publicly and privately available datasets, including, but not limited to, resource allocation data, seasonality information, sales information (e.g., in a business-to-business and / or business-to-customer context), attribute information of the mobile device, market data, device claim data (e.g., insurance claims, warranties, and / or information regarding other repairs), other macroeconomic indicators, stock information, and / or social media data. Since many of these datasets are independent of each other, it may be necessary to extract, normalize, scale, and / or otherwise condition the relevant components of such datasets so that such information can be used in a predictive model.

[0015] In addition to the technical challenges imposed by the volume, complexity, and variability of the multiple datasets used in relation to the predictive model, the inventors of the present invention described herein have also recognized the technical challenges imposed by the conditions of a given environment (the capabilities of any given channel to effectively receive and distribute resources, the existing resources available for distribution, the actions of external actors, etc.) and the rate at which such conditions change within the technical environment. In particular, the inventors have recognized that the latency inherent in reactive systems often results in inefficiencies and waste associated with resource allocation that does not match the changes and / or shifting conditions in a given environment.

[0016] To address these technical challenges, as well as other technical challenges associated with dynamically allocating variable resources under rapidly changing environmental conditions, users associated with requests for resource allocation to channels capable of efficiently distributing such resources may be able to interact with resource allocation prediction systems that utilize predictive machine learning models. By using machine learning models, the system can identify, generate, and / or otherwise provide resource allocation guidance based on contextual information associated with the environment in which resources are distributed internally. In the context of the distribution of used mobile devices in a market environment, the system can leverage a wide range of information sources that can be fed into the machine learning model to enable the prediction and modeling of market conditions to identify channels to which specific quantities and types of devices should be allocated at a given time. Furthermore, by applying decay curves and other aspects of predictive models, changes in market conditions, resource demand, and other relevant factors can be predicted, enabling resource allocation that is more temporally aligned with the conditions at a given time than is available from conventional reactive approaches.

[0017] For example, in the context of efficiently distributing an existing inventory of used mobile devices, the system may access and process datasets that provide context and / or other information about one or more mobile devices and / or the channels through which such devices may be disposed of, such as existing asset distribution information, historical sales information, competitive pricing information, other market information, device attribute information, device performance information (e.g., insurance claim data associated with one or more mobile device models, device usage and device status data that may be obtained through self-service and / or customer service platforms and / or interfaces, etc.), and / or other publicly and / or privately available datasets associated with a given mobile device, channel, and / or environment. The system may also access and process information associated with additional factors that may influence conditions within a given environment. For example, in addition to any of the above categories, and / or separately, data indicating seasonal and / or other time-based factors, macroeconomic conditions, social media data, and / or other information (e.g., manufacturer behavior, plans, and / or statements, etc.) may be used. The system can also access and process other sources of information, including but not limited to feedback information, decay curve information, and training data for use in relation to machine learning models, which are generated by the system. As a result, by using available data, information produced using the model, and data describing the characteristics of mobile devices and / or environments, one or more channels for the distribution of resources (e.g., used mobile devices) can be identified and selected based on predicted conditions, thereby enabling the resources to be directed in a way that allows them to efficiently reach a given channel when the resources are needed and / or can be disposed of through the channel in other ways.

[0018] To overcome these and other technical challenges, exemplary implementations of the embodiments of the present invention described herein use automated tools to obtain and scale a diverse set of information about channels (e.g., aggregators) through which mobile devices and / or other resources may be distributed. Using the scaled information, groups of aggregators and / or other channels can be assigned to layers that generally reflect the ability of the aggregators and / or other channels to effectively distribute the relevant resources. To effectively forecast pricing information and to otherwise address time-dependent and / or chronological data, a decay function is applied in other ways to the pricing data that has been modeled and received from aggregators and / or other available channels (e.g., distribution channels through which mobile devices may be sold directly). This combination of stratification and data decay enables the identification and ranking of aggregators and / or other channels that are most likely to be able to distribute a particular quantity of specific devices at a predicted price at a later time. Thus, resources can be directed to the right channel in a timely manner to take advantage of the best pricing and / or distribution opportunities available when the resources are available for distribution. In situations where inventory is obtained through secondary markets (e.g., repurchase programs), the value of a particular device and / or set of devices can be calculated, taking into account the available distribution channels and the expected selling price, under pricing and related conditions.

[0019] Many of the exemplary implementations described herein are particularly advantageous in situations and other contexts involving the disposal of inventory of used mobile devices, such as inventory acquired through insurance claims, buyback programs, trade-in programs, etc. In some such situations, the availability of distribution channels, the viability of such channels, existing inventory of devices, the value of those devices, and the demand for such devices all tend to fluctuate over time. By predicting and modeling the ability of one or more channels to accept and distribute one or more sets of mobile devices (and the duration, speed, and other aspects of such acceptance and distribution), resources (e.g., in the form of used mobile devices) can be efficiently distributed to customers and / or other potential users in a manner that closely matches the availability and demand for devices in time. Therefore, for clarity, some of the exemplary implementations described herein may use terminology, background facts, and details associated with the acquisition and distribution of devices and refer to information and data objects associated with the acceptance and distribution of such used mobile devices. However, it will be understood that embodiments of the present invention and its exemplary implementations may be applicable and advantageous in a wide range of contexts and situations other than those related to event preparation and planning.

[0020] Embodiments of this disclosure further cover computer implementations, apparatus, systems, and computer program products for improved generation of resource offer sets, analysis and / or adjustment of generated resource offer sets, and / or approval of resource offer sets. More specifically, a predicted optimal resource offer set can be modeled using a resource offer generation model. Various heterogeneous unstructured datasets (e.g., resource pricing characteristics offered by third-party entities such as vendors and competitors, pricing characteristics offered by resource owners, resource inventory data, social media data related to resources, seasonality data, resource launch data, etc.) can be extracted from one or more heterogeneous data sources, warehouses, data stores, etc. Unstructured datasets can be cleaned, normalized, transformed, and otherwise synthesized for application to a resource offer generation model. By modeling optimal resource offers based on various data sources, exemplary implementations of embodiments of this disclosure can rapidly provide one or more resource offer sets for the purpose of resource acquisition and subsequent distribution (this may be time-dependent or may require careful adjustment to be effective in securing sufficient interest from resource owners). Specifically, for example, in the environment of acquiring and distributing used mobile devices, the resource offer data object associated with the purchase of a used mobile device must be appropriately adjusted to set the corresponding price characteristics or resource offer values ​​so that device owners are likely to take advantage of the offer while ensuring that financial and / or benchmark targets (profitability, margins, desired device acquisition and distribution, etc.) are met with respect to the acquisition and expected distribution of used mobile devices associated with the generated resource offer set (for example, individual device owners may trade in their devices through one or more device acquisition channels, such as carriers).

[0021] The availability and / or distribution of resources, including used mobile devices, can vary dynamically and significantly across regions and / or over time between regions or within a single region. For each region (e.g., a country, city, or other defined geographical area) and collection period (e.g., the time interval during which an offer defined by a resource offer data object can be actively offered to that region), a used mobile device may be best associated with a specific resource offer data object within the generated resource offer set. For example, each resource may be mapped to a specific resource offer data object representing the corresponding offer offered for the acquisition of the resource, as described herein.

[0022] Resources can be identified based on resource attributes and / or corresponding resource set identifiers such as CNNs. For any given resource associated with a corresponding CNN, the ideal resource offer value of the resource offer data object associated with a particular resource set identifier may vary by time and / or region so that a mobile device with certain attributes can be best associated with a first offer value at a first time and a second offer value at a second time, or with a first offer value for a first region and a second offer value for a second region. Offer values ​​may also differ depending on various resource attributes associated with the resource. For example, for a given mobile device, the functionality of the mobile device can, in particular, alter the ideal resource offer value of the resource offer data object associated with the resource. In an exemplary environment, a resource such as a partially functional mobile device may be associated with a lower offer value than a fully functional mobile device. It may be difficult to determine the difference in resource offer values ​​between two resources with different functionalities.

[0023] The inventors of the embodiments of this disclosure have recognized that offer data objects can be modeled and predicted based on various datasets containing various types of data in order to provide an optimal resource offer data object for a particular resource (for example, associated with a specific resource set identifier). Conventional approaches do not accurately consider resource distribution channels and assumed distribution timeframes, promotional periods, and fair market offer values ​​for a given resource, such as used mobile devices. As a result, resource offer data objects may be generated associated with suboptimal or inaccurately predicted offer values, and therefore, providing offers defined by resource offer data objects is more likely to fail to obtain the desired volume of resources for distribution across various channels.

[0024] To address these and other technical challenges, a user associated with a request to generate resource offers (e.g., an offer control user) may interact with a resource offer generation system that uses one or more predictive machine learning models. Using machine learning models, the system can generate resource offer sets containing resource offer data objects for various resources associated with various resource set identifiers. The system may further optimize the resource offer sets provided based on desired benchmarking and / or targets, such as financial and / or business parameters or objectives, provided through benchmark and portfolio target datasets. Based on the output of the predictive model, the machine learning model may improve the generated resource offers to achieve desired financial and / or benchmark targets. As described above, the machine learning model may leverage other market information datasets (multiple) extracted and synthesized for various mobile devices with diverse attributes and characteristics, and offered by various third-party entities (competitors, firm-versus-consumer entities, etc.). The resource offer generation system may also have access to extracted, normalized, scaled, and / or otherwise adjusted information that was previously unavailable due to data destruction.

[0025] The inventors of embodiments of the disclosure herein further recognize that they have presented a set of resource data objects for analyzing and, if desired, efficiently and effectively adjusting resource offer data objects to achieve new desired financial or benchmark targets, for example, by adjusting corresponding resource offer values(or values). A system user, for example, an offer control user, may want to analyze a generated resource offer set to measure the relative strength of the resource offer set, and visualize the effect of adjustments to the strength of the resource offer set and / or the effect of adjustments to achieving benchmark and / or portfolio targets, based on collected and standardized market information, for example, to determine whether the relative strength of the generated resource offer set (e.g., the chance that the offer defined by each resource offer data object will be accepted / utilized by a resource owner) is sufficient, and to determine whether the resource offer set will meet desired financial and benchmark targets. Based on the analysis, the system user may want to adjust one or more of the resource offer data objects within the resource offer set to increase the overall offer strength or improve a benchmark or portfolio target metric (e.g., profitability).

[0026] In this regard, embodiments provide a favorable interface for viewing, analyzing, adjusting, and / or approving resource offer sets. Users may access an offer adjustment interface through embodiments of the disclosure. The offer adjustment interface may be configured to allow system users to view and analyze resource offer sets. The offer adjustment interface may be further configured to allow system users to view and analyze additional information derived from or associated with resource offer sets. For example, the offer adjustment interface may include a dashboard for accessing various interfaces used when analyzing resource offer sets. Additionally, the offer adjustment interface may include metrics from an offer analysis dataset that show financial metrics for the generated resource offer set and are updated to reflect the current adjusted resource offer set when adjustments are made through this interface.

[0027] Furthermore, system users, such as offer control users, can adjust resource offers via an offer adjustment interface. Such adjustments may be made to achieve new financial and / or benchmark targets. As a user adjusts one or more resource offer data objects, the dashboard interface and / or the offer analysis dataset associated with the resource offer are dynamically updated by the system to reflect calculations based on the adjusted resource offer set. Such embodiments offer technical advantages in visualizing changes to promising resource offers and their impact on offer strength, and / or financial and / or benchmark targets.

[0028] The submitted coordinated resource offer set may be subject to approval by another user, such as an offer approval user. The system of this embodiment can facilitate an improved approval process by providing an improved offer approval interface. Through the offer approval interface, the offer approval user can effectively analyze the coordinated resource offer set submitted by the offer control user. The offer approval interface may include dashboards, such as dashboards rendered in association with the offer adjustment interface, to enable efficient and thorough analysis using a specific streamlined interface. Definition Where used herein, “data,” “content,” “information,” and similar terms may be used interchangeably to refer to data that can be transmitted, received, and / or stored in accordance with embodiments of this disclosure. Therefore, the use of such terms should not be construed as limiting the spirit and scope of embodiments of this disclosure. Furthermore, where a computing device is described herein to receive data from another computing device, it will be understood that the data may be received directly from the other computing device or indirectly through one or more intermediate computing devices, such as one or more servers, relays, routers, network access points, base stations, or hosts, which may be referred to herein as a “network.” Similarly, where a computing device is described herein for transmitting data to another computing device, it will be understood that the data may be transmitted directly to the other computing device or indirectly through one or more intermediate computing devices, such as one or more servers, relays, routers, network access points, base stations, or hosts.

[0029] As used herein, the term “circuit mechanism” means (a) a hardware-only circuit implementation (e.g., an implementation in an analog circuit mechanism and / or a digital circuit mechanism), (b) a combination of circuit and computer program products (may include) one or more software and / or firmware instructions stored in computer-readable memory that work together to cause the device to perform one or more functions described herein, and (c) a circuit such as a microprocessor (may include) or a part of a microprocessor (may include) that requires software or firmware for operation even if the software or firmware is not physically present. This definition of “circuit mechanism” applies to all use of the term herein, including in claims. As a further example, as used herein, the term “circuit mechanism” also includes an implementation that includes one or more processors and / or parts thereof, and accompanying software and / or firmware. As another example, as used herein, the term “circuit mechanism” also includes, for example, a baseband integrated circuit or application processor integrated circuit for a mobile phone, or a similar integrated circuit in a server, cellular network device, other network device, and / or other computing device.

[0030] As used herein, “computer-readable storage medium” can be distinguished from “computer-readable transmission medium” which refers to a physical storage medium (e.g., a volatile or non-volatile memory device).

[0031] As used herein, the terms “User,” “Client,” and / or “Request Source” refer to the source of a request for the identification of one or more channels to be used for the distribution of resources and / or related content provided by a predictive control system and / or any other system capable of predicting and / or modeling the likely conditions of the environment in which the resources may be distributed through one or more known channels, and / or the individual or entity associated with the source. For example, a User and / or Client could be an owner and / or entity seeking information about the optimal one or more channels for distributing a particular inventory of used mobile devices and / or the likely conditions under which the inventory of a particular used mobile device can be efficiently distributed.

[0032] The term “client device” refers to computer hardware and / or software configured to access services made available by a server. The server is (often, but not always) on another computer system, in which case the client device accesses the services over a network. Examples of client devices include, but are not limited to, smartphones, tablet computers, laptop computers, wearables, personal computers, and enterprise computers. As described herein, client devices communicate with and access prediction systems and / or resource offer generation systems over one or more networks.

[0033] The term “Offer Control User” refers to a specific user of the Resource Offer Generation System who is authorized to perform one or more actions associated with the Resource Offer Generation System via a client device capable of communicating with the Resource Offer Generation System. An Offer Control User is associated with an Offer Control User account authorized to generate resource offer datasets for specific regional program identifiers and collection period data objects via the Resource Offer Generation System, view them for analysis, adjust resource offer data for specific regional program identifiers and collection period data objects via the Offer Adjustment Interface, and / or submit resource offer sets or adjusted resource offer sets for approval. In some embodiments, an Offer Control User is associated with a corresponding user account authorized to access the Resource Offer Generation System to perform the described actions. An Offer Control User may authenticate user credentials associated with a user account to initiate an authenticated session and perform the described actions via the Resource Offer Generation System.

[0034] The terms "color-neutral name" or "CNN" refer to a system-standardized resource identifier that identifies a resource associated with specific resource attributes. A CNN may map to one or more third-party resource identifiers maintained, for example, by a third-party database and / or device. The term "resource attribute" refers to device specifications, characteristics, or identifying information associated with a particular resource. Resources can be classified by their resource attributes, thereby allowing resources with the same resource attributes to be grouped and identified by combinations of resource attributes. For example, in the context of distributing mobile devices as resources, a mobile device resource may be associated with a manufacturing identifier, model identifier, storage size identifier, and / or carrier identifier. In some embodiments, resource attributes may include similar information associated with the resource's specifications. The corresponding CNN may be associated with multiple country, region, or third-party specific identifiers used to characterize resources for the same device.

[0035] The term "resource set identifier" refers to a unique string, number, or other form of identification information associated with one or more resources that share at least one common attribute. In some embodiments, the resource set identifier is a CNN. In some embodiments, the resource set identifier is an SKU. In other embodiments, the resource set identifier is one or more resource attributes or a combination of several resource attributes.

[0036] The term “digital content item” refers to any electronic media content item intended for use either in electronic format or as a printed output, and which may be received, processed, and / or otherwise accessible by a client device. For example, a digital content item may be in the form of a text file that conveys human-readable information to a user of a client device. Other examples of digital content items include images, audio files, video files, and text files.

[0037] As used herein, the term “data object” refers to a structured arrangement of data. A “request data object” is a data object that includes one or more datasets associated with a user request to identify one or more channels and / or conditions for one or more channels that may be distributed through a resource (such as a mobile device). A “channel context data object” is a data object that includes one or more datasets that, alone or in combination with other datasets, provide information about channels and / or environments in which one or more channels may operate, such that the characteristics of one or more channels may be predicted.

[0038] As used herein, the term “dataset” refers to a collection of data. One or more datasets may be combined, incorporated, and / or otherwise structured as data objects. A “context dataset” is a dataset that contains information about the environments in which a channel and / or one or more channels may operate. A “prediction condition dataset” is a dataset that contains one or more metrics of relevant conditions under which a channel and / or resource (e.g., a mobile device) may be distributed.

[0039] The term “third-party entity” refers to a company, individual, group, etc., associated with the acquisition and / or distribution of resources. Examples of third-party entities include, but are not limited to, competitor entities (indirect or direct competitor entities) and distributed user platform owner entities. Some third-party entities are commercial acquirers and / or resellers of resources. In some embodiments, each third-party entity is associated with a specific channel profile for the distribution and / or acquisition of resources through the third-party entity.

[0040] The term “Regional Program Data Object” refers to an electronically managed, structured arrangement of data associated with a specific offering linked to the acquisition of resources for a particular region. Each Regional Program Data Object may be associated with a specific program for acquiring a set of resources based on the associated approved set of resource offers. Each Regional Program Data Object may be associated with a “Regional Program Identifier” that uniquely identifies the Regional Program Data Object. A region may be associated with one or more Regional Program Data Objects.

[0041] The term "collection period data object" refers to an electronically managed representation of a time interval defined by a collection period start timestamp and a collection period end timestamp. Resource offer sets can be generated in association with collection period data objects, so that resource offer sets can be recognized as valid and associated with regional program data objects only during the time interval represented by the collection period data object. For example, a particular resource offer set may be associated with a particular program in a particular country for a two-week time interval represented by a particular collection period data object.

[0042] The term “data acquisition parameter” refers to one or more parameters associated with the acquisition of resources associated with a particular regional program data object. Data acquisition parameters include business, portfolio-level, and resource acquisition target parameters associated with the acquisition of resources associated with a regional program data object. Non-exclusive examples of data acquisition parameters include distribution channel mix ratio, activity cost, resource volume multiplier, promotional resource list, commission associated with resource offer data object, offer ratio of functional to non-functional resources, desired profit per device, desired volume percentage by grade, time-based resource condition multiplier, and minimum resource offer values ​​for functional and / or non-functional resources. A regional program data object may contain, or be associated with, a “data acquisition parameter set” containing one or more data acquisition parameters for that regional program data object.

[0043] The term “benchmark and portfolio target datasets” refers to the collection of data representing, or associated with, target metrics for resource distribution and / or procurement. In some embodiments, benchmark and portfolio target datasets represent a subset of data collection parameters. In some embodiments, benchmark and portfolio target datasets are associated with regional program data objects. In some embodiments, benchmark and portfolio target datasets define boundary conditions entered by an offer control user or offer approval user, such that generated and / or submitted resource offer sets must satisfy the boundary conditions defined by the benchmark and portfolio target datasets. For example, in some embodiments, benchmark and portfolio target datasets include, at a minimum, assumed profitability based on a resource offer set, or a minimum assumed margin based on a resource offer set. In some embodiments, benchmark and portfolio target datasets include target time intervals for the distribution or acquisition of several resources.

[0044] The term "resource offer data object" refers to an electronically managed, structured collection of data that includes at least a resource offer value for a specific resource set identifier. A resource offer data object may include a resource set identifier to which a resource offer value is associated. Resource offer data objects, such as offer control users, can be modified by users, modifying the resource offer value associated with the resource offer data object. Each resource offer data object may be uniquely associated with a resource offer identifier.

[0045] The term "resource offer set" refers to a group of zero or more resource offer data objects. Each resource offer data object within a resource offer set may be associated with a different resource set identifier.

[0046] The term “adjusted data object” refers to an electronically managed, structured arrangement of data that represents changes in one or more properties associated with one or more resource offer data objects. In some embodiments, an adjusted data object contains the adjusted resource offer values ​​of one or more resource offer data objects. One or more adjusted data objects can be used to update a resource offer set to create an adjusted resource offer set.

[0047] The term “adjusted resource offer set” refers to a resource offer set that includes one or more adjustments made by an offer control user to one or more resource offer data objects. In some embodiments, an adjusted resource offer set is created by updating a resource offer set based on one or more adjustment data objects. An adjusted resource offer set may be further adjusted based on a second set of adjustment data objects to create a new adjusted resource offer set. In some embodiments, a stored resource offer set associated with a regional program identifier and collection period data object is embodied by an adjusted resource offer set after, for example, one or more adjustments are made by an offer control user.

[0048] The term “offer status record” refers to electronically managed data stored in a repository associated with managing the approval of resource offer sets associated with regional program identifiers and collected parameter data objects. In some embodiments, offer status records are stored in an offer approval repository, which may be a sub-repository managed by the resource offer generation system. Offer status records are retrievalable either in association with, based on, or utilizing regional program identifiers and collected parameter data objects. In some embodiments, offer status records include at least an offer status indicator. In some embodiments, offer status records are associated with or otherwise linked to resource offer sets.

[0049] The term “Offer Status Indicator” refers to data or information indicating the processing status for the generation, adjustment, and approval of resource offer sets associated with specific regional program data objects and collection period data objects. In some embodiments, an offer status indicator is represented by one of several possible status indicators. An exemplary offer status indicator is a “Request Status Indicator,” which indicates that resource offer generation processing has been requested for the corresponding regional program identifier and collection period data objects, but the resource offer set has not yet been generated. In some embodiments, another exemplary offer status indicator is a “Pending Adjustment Status Indicator,” which indicates that a resource offer set has been generated for the regional program identifier and collection period data objects, but has not yet been submitted by the offer control user for approval. In some embodiments, another exemplary offer status indicator is a “Pending Approval Status Indicator,” which indicates that the adjusted resource offer set has been submitted by the offer control user for approval or rejection by the offer approval user, but has not yet been approved or rejected by the offer approval user. In some embodiments, another exemplary offer status indicator is an “Approval Status Indicator,” which indicates that the submitted adjusted resource offer set has been analyzed and / or approved by the offer approval user. In some embodiments, another exemplary offer status indicator is an “approval status indicator,” which indicates that the submitted adjusted resource offer set has been analyzed and / or rejected by the offer rejection user.

[0050] In some embodiments, the offer status indicator is stored in or associated with an offer status record corresponding to a regional program identifier and collection period data object. The offer status record may be stored in an offer approval repository. In some embodiments, the offer status record similarly includes or is associated with a stored resource offer set. In other embodiments, the stored resource offer set associated with the offer status record is stored in a separate repository or sub-repository.

[0051] The term “expected resource volume dataset” refers to the collection of data associated with the distribution of resources to expected channels, associated with a specific resource set identifier. In some embodiments, the expected resource volume dataset is output by or parsed from a prediction system. In some embodiments, for example, the expected resource volume dataset includes, or is derived from, at least one resource allocation set generated by a prediction system associated with at least one channel profile. In some embodiments, the expected resource volume dataset is generated by another system associated with the prediction system.

[0052] The term “average distribution request dataset” refers to the collection of data associated with parameters associated with the distribution of resources identified by the assumed resource quantity dataset. In some embodiments, the average distribution request dataset includes at least the average selling price at which the resources are expected to be distributed. In some embodiments, the average distribution request dataset is output by or analyzed from a prediction system.

[0053] The term "market intelligence dataset" refers to the collection of data associated with the acquisition and / or distribution of resources associated with one or more channels by various entities. For example, a market intelligence dataset may include information on the acquisition of resources associated with one or more channels, sentiment information associated with resources, launch information associated with resources, and perceived value of resources for distribution and / or acquisition. A market intelligence dataset or a portion thereof may be extracted from one or more third-party systems, scraped from various data sources (e.g., web scraping), and received from third-party systems (e.g., regularly updated data). In some embodiments, a market intelligence dataset includes one or more subsets, each associated with a specific resource set identifier, such as a CNN. In some embodiments, the market intelligence dataset includes, for one or more specific resource set identifiers, distributed user platform pricing for a specific resource set identifier (e.g., the average selling price for a specific resource set identifier through one or more distributed user platforms such as eBay® or similar channels), other third-party offer values ​​for a specific resource set identifier, social media sentiment for a specific resource set identifier, seasonality information, launch information associated with a specific resource set identifier, and inventory data.

[0054] The term "exception period" refers to an untrusted timestamp interval during which a particular resource characteristic for a specific resource in an untrusted third-party resource characteristic dataset falls outside the expected operating range. In some embodiments, the expected operating range is embodied by the expected deviation of the offset between the untrusted third-party resource characteristic dataset and the distributed resource characteristic dataset. In some embodiments, the exception period begins with a first timestamp where the deviation of the offset for the value of the particular resource characteristic satisfies an exception deviation threshold, and ends with a second timestamp where the deviation of the offset for the value of the particular resource characteristic does not satisfy the exception deviation threshold. In some embodiments, the exception period for a particular untrusted third-party resource characteristic dataset includes one or more records in the untrusted third-party resource characteristic dataset associated with the timestamps within the exception period.

[0055] The term "exception deviation threshold" refers to the normal operating range of offset deviations between the resource characteristics of an unreliable resource characteristics dataset and the resource characteristics of a distributed resource characteristics dataset for a particular resource set identifier. In some embodiments, an exception period is indicated when the exception deviation threshold is met by the offset deviation exceeding the exception deviation threshold.

[0056] The term “exception detection model” refers to one or more machine learning, algorithms, and / or statistical models, or combinations thereof, for generating a trusted resource characteristics dataset based on one or more untrusted third-party resource characteristics datasets applied to the model and a distributed resource characteristics dataset applied to the model. In some embodiments, the exception detection model is configured to identify an exceptional period set for the applied untrusted third-party resource characteristics set based on offset deviations with respect to the distributed resource characteristics dataset, to remove the exceptional period set to create an updated untrusted third-party resource characteristics dataset, and to generate a trusted resource characteristics dataset based on at least the updated untrusted third-party resource characteristics dataset. In some embodiments, the exception detection model is configured to generate a trusted resource characteristics dataset based on a comparison between two or more updated untrusted third-party resource characteristics datasets associated with different third-party entities.

[0057] The term "resource characteristics" refers to specific attributes associated with a resource. One or more resource characteristics of a resource associated with a particular resource set identifier are represented in the records of the dataset associated with the resource set identifier. For example, the terms "pricing characteristics" and "pricing characteristics" refer to the offer values ​​for obtaining or distributing a resource associated with the corresponding resource set identifier.

[0058] The term “untrusted third-party resource characteristics dataset” refers to a collection of one or more resource characteristics associated with a specific third-party entity, and the collection may include one or more resource characteristics associated with an exception period. The untrusted third-party resource characteristics datasets described herein are updated based on comparison with distributed resource characteristics datasets. In some embodiments, the untrusted third-party resource characteristics dataset includes at least price characteristics for a specific resource, such as a used mobile device.

[0059] The term “Third-Party Resource Pricing Dataset” refers to a specific historical dataset representing an untrusted third-party resource characteristics dataset that includes at least pricing characteristics for one or more resources of a resource set identifier. In some embodiments, the Third-Party Resource Pricing Dataset is associated with a third-party entity that provides third-party offers reflected as records in the Third-Party Resource Pricing Dataset. In some embodiments, the Third-Party Resource Pricing Dataset is contained within a Market Intelligence Dataset.

[0060] The term “distributed user platform” refers to a marketplace or other platform configured to allow individual users to generate offers for the purpose of obtaining and / or distributing resources. In some embodiments, a distributed user platform includes one or more distributed third-party entity devices configured to enable access to the distributed user platform. In some embodiments, an offer includes at least price characteristics for a particular resource set identifier. A distributed user platform is associated with a corresponding third-party entity that controls the distributed user platform.

[0061] The term “distributed resource pricing dataset” refers to a specific historical dataset containing at least pricing characteristics for one or more resource or resource set identifiers. In some embodiments, the distributed resource pricing dataset is associated with user-generated offers for resource acquisition available for one or more resource or resource set identifiers via a distributed user platform.

[0062] The term "alignment" refers to the organization and / or sorting of one or more datasets based on one or more characteristics of each record. The term "temporal alignment" refers to a specific organization of one or more datasets based on relevant timestamp characteristics. The term "resource set identifier alignment" refers to a specific organization of one or more datasets based on associated resource set identifiers.

[0063] The term “resource offer generation request” refers to a transmission by a client device associated with an offer control user to a resource offer generation system, indicating a request to generate a resource offer set associated with a regional program identifier and a collection period data object. In some embodiments, an offer request includes at least a regional program identifier and a collection period data object that cause a resource offer set to be generated. The resource offer set may be generated associated with various resource set identifiers determined based on the regional program data object associated with the regional program identifier.

[0064] The term "display" refers to data or information that represents a visual presentation of data, data objects, sets of data, or any portion thereof, to a particular user interface. Examples of metrics include, but are not limited to, text metrics, graphic metrics, chart metrics, image metrics, and encoded metrics. It should be understood that metrics can cause a user interface to display and / or render a visual presentation of data, data objects, sets of data, or any portion thereof. Exemplary system environment Now, looking at the drawings, Figure 1 shows an exemplary system environment 100 in which an implementation form can be realized with efficient prediction and modeling of the conditions and channels through which resources may be distributed. The depiction of environment 100 is not intended to limit or otherwise restrict the embodiments described and conceived herein to any particular element or system of configuration, nor is it intended to exclude any alternative configuration or system of the set of configurations and systems that may be used in connection with embodiments of this disclosure. Rather, Figure 1 and the environment 100 disclosed therein are presented simply to provide an exemplary basis and context to facilitate some of the features, aspects, and uses of the methods, apparatus, and computer program products disclosed and conceived herein. Although many of the aspects and components presented in Figure 1 are shown as discrete, separate elements, it will be understood that other configurations may be used in connection with the methods, apparatus, and computer programs described herein, including configurations that combine, omit, and / or add aspects and components.

[0065] Embodiments implemented in a system environment such as system environment 100 advantageously provide efficient prediction and modeling of conditions and channels through which a resource may be distributed by receiving and parsing a request data object received from a user, retrieving and / or receiving a set of data objects and / or other datasets (e.g., one or more channel context data objects) to present to a machine learning model, retrieving a predicted condition dataset by applying the received data objects to the machine learning model, and generating control signals to display a renderable object associated with the predicted condition dataset on the user interface of a client device associated with the user. Some such implementations conceive of using channel context data objects and / or other datasets associated with distribution channels, and / or a mobile device or other resource that is the subject of a given request data object. Some such embodiments leverage hardware and software arrangements or environments for efficient prediction and modeling of conditions and channels through which a resource may be distributed, and for response message generation actions described herein, conceived, and / or otherwise disclosed.

[0066] As shown in Figure 1, the prediction system 102 includes an online prediction system module 102A configured to receive, process, transform, transmit, communicate with, and evaluate request data objects, channel context data objects, content and other information associated with such data objects, and associated interfaces via a web server such as the prediction system server 102B and / or prediction system device 102D. The prediction system server 102B and / or prediction system device 102D are connected to one of several public and / or private networks, including but not limited to the Internet, public telephone networks, and / or networks associated with a particular communication system or protocol, and may include at least one memory for storing applications and communication programs.

[0067] It will be understood that all components shown in Figure 1 may be configured to communicate over any wired or wireless network, including wired or wireless local area networks (LANs), personal area networks (PANs), metropolitan area networks (MANs), wide area networks (WANs), and interfaces with the accompanying hardware, software, and / or firmware (e.g., network routers and network switches) necessary to implement the above networks. Networks such as mobile phones, 802.11, 802.16, 802.20, and / or WiMAX networks, as well as public networks such as the Internet, private networks such as intranets, or a combination thereof, and currently available or future-developed networking protocols including but not limited to TCP / IP-based networking protocols, may be used in connection with the system environment 100 and embodiments of the present invention that may be implemented therein or involved therein.

[0068] As shown in Figure 1, the prediction system 102 also includes a prediction database 102C which can be used to store information related to the efficient prediction and modeling of conditions and channels that may be distributed through request data objects, users, resources (e.g., used mobile devices, etc.), request data objects, channel context data objects, channels associated with other datasets, interfaces associated with such data objects or datasets, request source systems, channel content systems, and / or resources, and the generation of one or more associated messages and / or digital content item sets. The prediction database 102C can be accessed by the prediction system module 102A, the prediction system server 102B, and / or the prediction system device 102D, and can be accessed by the prediction system 102 and / or components of the prediction system 102, and / or can be used to store any additional information otherwise associated with them. Although Figure 1 depicts the prediction system database 102C as a single structure, it will be understood that the prediction system database 102C may be implemented additionally or alternatively to enable storage in a distributed manner and / or in facilities that are physically distant from each other and / or from other components of the prediction system 102.

[0069] The prediction system 102 is also shown to include a prediction system device 102D, which may take the form of a laptop computer, desktop computer, or mobile device, to provide additional means for interface with other components of the prediction system 102 and / or other components shown in or otherwise conceived in the system environment 100 (other than through the user interface of the prediction system server 102B).

[0070] Request data objects, request data object information associated with one or more request data objects, and / or additional content or other information may originate from a request source system, such as the request source system 104. Users of the request source system 104 may interface with the request source module 104A using a request source device 104B, such as a laptop computer, desktop computer, or mobile device, to create, generate, and / or transmit information to be included in the request data objects, such as request data objects and / or information to be included in the request data objects, such as identification information for one or more resources (e.g., mobile device identification information, inventory information, timing information, and / or other request parameters). The request source system 104 may transmit the request data objects to the forecast system 102 (e.g., through the operation of the request source module 104A and / or the request source device 104B). For the sake of clarity, although only one request source system 104 is depicted in Figure 1, it will be understood that many other such systems can exist in the system environment 100, enabling numerous users and / or other request sources to generate and transmit information associated with request objects and / or request data objects to the prediction system 102.

[0071] As shown in Figure 1, the system environment 100 also includes a content system 106, which includes a content module 106A, a content server 106B, and a content system database 106C. For the sake of clarity, only one content system 106 is depicted in Figure 1, but it will be understood that numerous additional such systems may exist in the system environment 100, allowing numerous sources of channel context content and / or other information related to the efficient prediction and modeling of conditions and channels through which resources may be distributed to communicate with and / or interact with the prediction system 102 and / or one or more request source systems 104. As shown in Figure 1, the content system 106 can communicate with the prediction system 102 to provide information that the prediction system 102 may need when predicting and modeling the conditions and channels through which resources may be distributed. For example, the content system 106 may acquire and provide information associated with, for example, one or more mobile devices, distribution channels, mobile device data, disposal information, market information, macroeconomic data, and / or other data related to a device or channel, for example, through the capabilities and / or actions of the content module 106A, the content system server 106B, and / or the content system 106C.

[0072] The content system 106 is also shown to be capable of optionally communicating with the request source system 104. In some situations, such as when a given content system 106 is associated with content owned and / or otherwise controlled by a user of the request source system, it may be advantageous for the content system 106 to interface with and / or otherwise communicate with the request source system 104, in particular the request source device 104B, in order to capture and / or process such content.

[0073] Overall, as depicted in the system environment 100, the prediction system 102 engages in inter-machine communication with the request source system 104 and the context content system 106 via one or more networks, facilitating the processing of request data objects received from the user, efficient prediction and modeling of conditions and channels that can be distributed through resources, retrieval and / or generation of digital content item sets and / or other datasets based at least partially on the request data objects, and generation and / or transmission of control signals that cause renderable objects associated with predicted channels and / or conditions to be displayed on the user interface of a client device associated with the user. Exemplary apparatus for implementing improved channel prediction and modeling. It will be understood that the prediction system 102 may be embodied by one or more computing systems, such as the device 200 shown in Figure 2. As illustrated in Figure 2, the device 200 may include a processor 202, memory 204, input / output circuitry 206, communication circuitry 208, prediction circuitry 210, and content aggregation circuitry 212. The device 200 may be configured to perform any of the operations described herein.

[0074] Regardless of how the device 200 is embodied, the device of an exemplary embodiment includes a processor 202 and a memory device 204, and optionally an input / output circuitry 206 and / or a communication circuitry 208, or is otherwise configured to communicate. In some embodiments, the processor (and / or coprocessor, or other processing circuitry assisting or otherwise associated with the processor) may communicate with the memory device via a bus for passing information between components of the device. The memory device may be non-transient and may include, for example, one or more volatile and / or non-volatile memories. In other words, for example, the memory device may be an electronic storage device (e.g., a computer-readable storage medium) including gates configured to store data (e.g., bits) that may be retrieved by a machine (e.g., a computing device such as a processor). The memory device may be configured to store information, data, content, applications, instructions, etc., to enable the device to perform various functions, as in the exemplary embodiments of the present disclosure. For example, the memory device may be configured to buffer input data for processing by the processor. Additionally or alternatively, the memory device may be configured to store instructions for execution by the processor.

[0075] As described above, the apparatus 200 may be embodied by a computing device. However, in some embodiments, the apparatus may be embodied as a chip or chipset. In other words, the apparatus may include one or more physical packages (e.g., a chip) including materials, components, and / or wires on a structural assembly (e.g., a baseboard). The structural assembly may provide physical strength, size preservation, and / or limitations on electrical interactions of the component circuitry contained therein. Thus, in some cases, the apparatus may be configured to implement embodiments of the present disclosure on a single chip or as a single "system on a chip". Thus, in some cases, the chip or chipset may construct means for performing one or more operations to provide the functions described herein.

[0076] The processor 202 can be embodied in several different ways. For example, the processor can be embodied as one or more of various hardware processing means, such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), a processing element with or without an associated DSP, or various other processing circuit mechanisms including integrated circuits such as ASICs (Application-Specific Integrated Circuits), FPGAs (Field-Programmable Gate Arrays), microcontroller units (MCUs), hardware accelerators, and dedicated computer chips. Thus, in some embodiments, the processor may include one or more processing cores configured to run independently. A multicore processor can enable multiprocessing within a single physical package. Additionally or alternatively, the processor may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelines, and / or multithreads.

[0077] In exemplary embodiments, the processor 202 may be configured to execute instructions stored in a memory device 204 or otherwise accessible to the processor. Additionally or alternatively, the processor may be configured to execute hardcoded functionality. Thus, whether configured by hardware or software, or a combination thereof, the processor may represent an entity (e.g., physically embodied in a circuit mechanism) that, while configured accordingly, can perform the operations according to embodiments of the present disclosure. For example, if the processor is embodied as an ASIC, FPGA, etc., the processor may be hardware specifically configured to perform the operations described herein. Alternatively, as another example, if the processor is embodied as an executor of software instructions, the instructions may specifically configure the processor to perform the algorithms and / or operations described herein when the instructions are executed. However, in some cases, the processor may be the processor of a specific device (e.g., a pass-through display or a mobile terminal) configured to use embodiments of the present disclosure by further configuration of the processor with instructions for performing the algorithms and / or operations described herein. The processor may include, among other things, a clock, an arithmetic logic unit (ALU), and logic gates configured to support the operation of the processor.

[0078] In some embodiments, the device 200 may optionally include an input / output circuit mechanism 206, such as a user interface, which communicates with the processor 202 to provide output to the user and, in some embodiments, can receive an indicator of user input. Thus, the user interface may include a display and, in some embodiments, a keyboard, mouse, joystick, touchscreen, touch area, soft keys, microphone, speaker, or other input / output mechanism. Alternatively or additionally, the processor may include a user interface circuit mechanism configured to control the display and, in some embodiments, at least some functions of one or more user interface elements such as a speaker, linger, microphone, etc. The processor and / or a user interface circuit mechanism including the processor may be configured to control one or more functions of one or more user interface elements via computer program instructions (e.g., software and / or firmware) stored in memory accessible to the processor (e.g., memory device 204, etc.).

[0079] The device 200 may also optionally include a communication circuit mechanism 208. The communication circuit mechanism 208 may be any means, such as a device or circuit mechanism, embodied either in hardware or a combination of hardware and software, configured to receive and / or transmit data between the device and a network and / or any other device or module in communication. In this regard, the communication interface may include an antenna (or more antennas) and supporting hardware or software to enable communication with a wireless communication network. Additionally or alternatively, the communication interface may include circuit mechanisms to interact with the antenna(s) to cause the transmission of signals through the antenna(s) or to process the reception of signals received through the antenna(s). In some environments, the communication interface may alternatively or further support wired communication. For example, the communication interface may include a communication modem and / or other hardware / software to support communication via cable, digital subscriber line (DSL), universal serial bus (USB), or other mechanisms.

[0080] As shown in Figure 2, the apparatus may also include a predictive circuitry mechanism 210. The predictive circuitry mechanism 210 includes hardware configured to maintain, manage, and provide access to predictive models and / or information used by predictive models for predicting and modeling the conditions and channels through which resources may be distributed. The predictive circuitry mechanism 210 may provide interfaces, such as application programming interfaces (APIs), that enable other components of the system to retrieve information associated with one or more resources and / or channels, and / or information associated with channels through which one or more sets of resources (e.g., mobile devices) may be efficiently distributed. For example, the predictive circuitry mechanism 210 may facilitate access to and / or processing information regarding specific inventory, its characteristics, the associated market environment, and / or other information that can be used to predict and model the conditions and channels through which resources may be distributed, including but not limited to any information available from and / or otherwise associated with the content system 106.

[0081] The prediction circuit mechanism 210 may facilitate access to channel context information and / or other information used by the prediction model through the use of an application or API executed using a processor such as processor 202. However, it should also be understood that in some embodiments, the prediction circuit mechanism 210 may include a separate processor, a specially configured field-programmable gate array (FPGA), or an application-specific interface circuit (ASIC) to manage access to and use of the relevant data. The prediction circuit mechanism 210 may also provide an interface that allows other components of the system to add or delete records to the prediction system database 102C, and may also provide communication with other components of the system and / or external systems via a network interface provided by the communication circuit mechanism 208. Thus, the prediction circuit mechanism 210 may be implemented using hardware components of the device, configured with either hardware or software to implement these planned functions.

[0082] The content aggregation circuit mechanism 212 includes hardware configured to manage, store, process, cleanse, scale, normalize, and analyze channel context data objects, as well as datasets and other information that may be included and / or used to generate channel context data objects. Because the information that may be accessed and used to create channel context data objects may change frequently and / or be subject to control by other systems, it may be desirable to maintain a content aggregation database separate from the prediction database 102C and / or memory 204 described above. However, it should also be understood that in some embodiments, the prediction circuit mechanism 210 and the content aggregation circuit mechanism 212 may have similar and / or overlapping functions. For example, both the prediction circuit mechanism 210 and the content aggregation circuit 212 may interact with one or more data objects associated with the context in which channels reside internally. The content aggregation circuit mechanism 212 may also provide access to other historical information, such as a set of previous information presented to the user with respect to a given set of mobile devices (or other resources) and the channels or multiple channels used to efficiently distribute such devices or other resources. Exemplary Functional Implementations of Embodiments of the Presented Disclosure Figure 3 is a block diagram illustrating the functionality of System 300 according to some embodiments of the present disclosure. As shown in Figure 3, System 300 incorporates three main functional blocks, including a user interface block 302, a data warehouse block 304, and a support system block 306, which are arranged so that each functional block can communicate with other functional blocks within System 300.

[0083] As shown in Figure 3, the user interface block 300 includes one or more interface modules 302A to 302N. In some exemplary implementations, the system 300 is designed to interact with a set of internal and / or external (or, for example, third-party) users. In the context of a system designed to predictively identify one or more channels through which used mobile devices should be efficiently distributed, system 300 may be used by one or more internal users (users associated with entities responsible for distributing used mobile devices to appropriate channels and / or to one or more external entities, such as aggregators responsible for collecting inventory for redistribution by system 300) and / or to one or more external entities. In such exemplary implementations, one interface module, such as interface module 302A, may provide user interface functions, access controls, and / or other aspects necessary for internal users to operate and / or otherwise predictively identify the appropriate channels to which mobile devices and conditions (such as capacity, pricing, and / or other factors) applicable to one or more identified channels should be directed. Similarly, the user interface may use another module, such as interface module 302N, to provide user interface functions, access controls, and / or other aspects necessary for external users (e.g., aggregators) to interact with system 300.

[0084] Similar to the user interface 302, the data warehouse block 304 and the support system block 306 each incorporate one or more functional modules, indicated as warehouse modules 304A-304N and support modules 306A-306N, respectively. In some exemplary implementations, one of the modules provides functionality associated with planning and forecasting resource demand, which may involve optimizing one or more disposal channels based on information about the inventory levels of available resources, the demand for such resources, strategic parameters, and / or other business rules, and other information associated with inventory and / or inventory visibility. In some such exemplary implementations, one or more modules associated with the data warehouse block 304 and / or the support system block 306 may generate a hypothetical device list that includes information about the likely inventory of mobile devices held by the system 300 and information associated with channels to which such inventory may be disposed.

[0085] In some exemplary implementations, one of the modules provides functionality associated with aggregator management, which may include, but is not limited to, the management of aggregator-related applications, account profiles, purchase history, hierarchical and / or other ranking, bidding, negotiation functions, purchase orders, financial transaction tracking, and / or billing. In some such exemplary implementations, one or more modules associated with data warehouse block 304 and / or support system block 306 may enable onboarding of potential aggregators, ranking of aggregators, acceptance and processing of bids received from aggregators, acceptance and processing of purchase orders, and / or billing functions.

[0086] In some exemplary implementations, one of the modules provides functionality associated with the recovery and disposal of resources and / or other assets, which may include, but is not limited to, the management of datasets and / or other information necessary to discover and document inventory and to manage pricing and / or other aspects of inventory allocation. In some such exemplary implementations, one or more modules associated with data warehouse block 304 and / or support system block 306 may facilitate the generation of periodic inventory updates, the initiation of pricing and allocation assignments for use by aggregators, the analysis of aggregator bids, and / or the analysis and approval of pricing and / or other offer conditions associated with aggregators.

[0087] In some implementations, one of the modules may provide functionality associated with material management, including, but not limited to, managing inventory sorting operations, repairing bulk materials, aggregator kid reports, and / or material shipments. In some such exemplary implementations, one or more modules associated with the data warehouse block 304 and / or the support system block 306 may facilitate the progress, reception, and / or transmission of inventory sorting orders (e.g., orders associated with inventory clearing), uploading and / or processing of aggregator kid reports, and / or processing associated with the shipment of resources (e.g., mobile devices and / or other goods).

[0088] In some exemplary implementations, one of the modules provides functionality associated with accounting and / or financial operations, which may include, but is not limited to, the management of cost, pricing, and / or other terms and conditions associated with invoice generation. In some such exemplary implementations, one or more modules associated with data warehouse block 304 and / or support system block 306 may facilitate the generation of entries for use in aggregator resource allocation, invoice logging, and / or other accounting operations.

[0089] In some exemplary implementations, one of the modules provides functionality associated with enterprise sourcing operations, which may include, but is not limited to, managing relationships between a system operator and associated aggregators. In some such exemplary implementations, one or more modules associated with data warehouse block 304 and / or support system block 306 facilitate the creation and management of documentation used in relation to relationships between entities operating the system and one or more aggregators or other third-party users. Exemplary data flow diagram of embodiments of this disclosure Figure 4 is a block diagram illustrating an exemplary data flow through System 400, which may be used in connection with exemplary implementations of embodiments of the present invention. As shown in Figure 4, System 400 includes a portal user interface service module 402 configured to send and receive information from internal users 404A and / or external users 404B, such as request data objects associated with requests for channel identification and / or allocation, which can be efficiently distributed via mobile devices. The portal user interface service module 402 is also configured to send and receive information from one or more data repositories 410A-410N, some of which may be configured to interact with a disposal database 406 and / or inventory system 408.

[0090] In some exemplary implementations, users such as internal user 404A and / or external user 404B transmit a request data object and / or other information associated with a request for identification information of one or more channels through which a resource (such as a mobile device) may be disposed of, pricing and / or other conditions associated with directing the resource through one or more channels. Upon receiving such a request, the portal user interface service module 402 may interact with one or more of the data repositories 410A-410N to send and receive information used in relation to fulfilling the parameters of the request data object.

[0091] For example, the portal user interface service module 402 may interact with a data warehouse, such as a data repository 410A, which contains information associated with planned and projected resource demands. In some such exemplary implementations, the portal user interface service module 402 and the associated data repository may create, exchange, and / or modify material lists and details associated with relevant resources. In some such exemplary implementations, the data repository 410A may also interact with a disposal database 406 to obtain lists and / or related information about assumed resource inventory (e.g., identification information of mobile devices assumed to be in inventory at a given time).

[0092] In some exemplary implementations, the portal user interface service module 402 may interact with a data repository, such as a data repository 410B, which contains information associated with asset distribution. In some such exemplary implementations, the portal user interface service module 402 and the associated data repository may create, exchange, and / or modify inventory lists and / or sales information associated with the distributed resources.

[0093] In some exemplary implementations, the portal user interface service module 402 may interact with a data repository, such as a data repository 410C, which contains information associated with repurchase pricing and / or other repurchase parameters. In some situations occurring in the context of used mobile devices, one source of mobile device inventory may include a repurchase system and / or other arrangements in which an entity purchases mobile devices from a user in accordance with the terms of an insurance coverage agreement, a repurchase program, and / or other approaches to acquiring used devices. In some such exemplary implementations, the portal user interface service module 402 and associated data repositories may create, exchange, and / or modify bids and / or other negotiation information to facilitate the acquisition of inventory.

[0094] In some exemplary implementations, the portal user interface service module 402 may interact with a data repository, such as a data repository 410D, which contains information associated with the material management functions. In some such exemplary implementations, the portal user interface service module 402 and the associated data repository may create, exchange, and / or modify information associated with prices, costs, and / or other conditions imposed on a given set of materials and / or other resources, including but not limited to invoices. In some such exemplary implementations, the associated data repository may also interact with the inventory system 408 to exchange information associated with the grading and / or sorting of allocated materials, lot skid reports, and / or lot shipment releases.

[0095] In some exemplary implementations, the portal user interface service module 402 may interact with a data repository, such as a data repository 410N, which contains information associated with aggregator management functions. In some such exemplary implementations, the portal user interface service module 402 and the associated data repository may create, exchange, and / or modify information associated with the submission of aggregator applications, the management of aggregator profiles and / or accounts, and the submission of purchase orders.

[0096] Overall, as shown in Figure 4, the system 400 can leverage a wide variety of datasets and data sources to obtain and process the information necessary to identify one or more channels through which resources can be efficiently distributed over a given time, and manage the functions necessary to ensure the efficient movement of resource inventory according to the predicted and modeled channels. Exemplary processing of channel prediction and modeling. Figure 5 is a block diagram illustrating an exemplary data flow 500 that may be used in relation to the efficient prediction and modeling of the conditions and channels through which resources may be distributed. In Figure 5, the prediction modeler 508 is configured to receive a request data object from a user, for example, through the interface shown and described in relation to Figures 2, 3, and 4. In some exemplary implementations, upon receiving the request data object, the prediction modeler 508 may leverage datasets from a wide range of sources, indicated as data repositories 502A to 502N, for example, in relation to the master data aggregation manager 504.

[0097] One such repository from which the prediction modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relating to the efficient prediction and modeling of the distribution of resources, such as mobile devices, through one or more channels, is an asset disposal data repository, which may contain, for example, information on how one or more sets of particular resources were efficiently distributed in the past. Such a repository may contain (or otherwise access) information scraped, extracted, and / or otherwise obtained from one or more records of past resource allocations, and / or information on the results of such allocations.

[0098] Another repository from which the prediction modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relating to the efficient prediction and modeling of the distribution of resources through one or more channels is, for example, a data repository that may contain information on seasonal variations and / or other time-related factors that affect the demand, availability, usefulness, and / or perceived value of one or more sets of resources. Such a repository may contain (or otherwise access) information scraped, extracted, and / or otherwise obtained from one or more records of historical resource allocations, and / or information on the results of such allocations, and / or studies of such seasonal and / or other time-based impacts.

[0099] Another repository from which the forecast modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information related to the efficient forecasting and modeling of resource distribution across one or more channels is, for example, a data repository that may contain information about historical sales and / or other distributions of resources. Such a repository may contain (or be otherwise accessed) information scraped, extracted, and / or otherwise obtained from one or more records of historical inter-company and / or company-to-customer sales.

[0100] Another repository from which the Predictive Modeler 508 and / or Master Data Aggregation Manager 504 may receive channel context data and / or other information relating to the efficient prediction and modeling of the distribution of resources through one or more channels is, for example, a data repository that may contain information about resource attributes. Such a repository may contain (or otherwise access) information about the structure, function, operation, use, age, features, and / or other characteristics of used mobile devices in inventory, as well as / or also contain information relating to determining whether, and to what extent, a mobile device can fulfill the functional assumptions of one or more sets of potential customers.

[0101] Another repository from which the forecast modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relating to the efficient forecasting and modeling of the distribution of resources through one or more channels is, for example, a data repository that may contain information about markets and / or other environments in which specific relevant channels may reside. Such a repository may contain (or be otherwise accessed) information scraped, extracted, and / or otherwise obtained from one or more records of activities and / or analyses of such activities carried out by competitors and / or other stakeholders in the market.

[0102] Another repository from which the Predictive Modeler 508 and / or Master Data Aggregation Manager 504 may receive channel context data and / or other information related to the efficient prediction and modeling of the distribution of resources through one or more channels is a data repository that may contain information about claims made in relation to one or more resources, such as mobile devices. In a context in which all or part of the inventory of mobile devices to be distributed is obtained in relation to insurance coverage agreements and / or related programs, information about claims made on an individual and / or aggregated basis may be useful in capturing changes in the usefulness and value of mobile devices over time. Such a repository may contain (or be otherwise accessed) information scraped, extracted, and / or otherwise obtained from one or more records of claims made for one or more devices. This information may include, for example, troubleshooting data, device data, customer service data, and / or repair data used in relation to determining whether a device is covered by a particular insurance coverage and / or buyback.

[0103] Another repository from which the forecast modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relating to the efficient forecasting and modeling of the distribution of resources through one or more channels is, for example, a data repository that may contain social media information and / or information relating to macroeconomic indicators. Such a repository may contain (or be otherwise accessed) information scraped, extracted, and / or otherwise obtained from social media sites, economic analyses, and / or other sources designed to capture individual and / or aggregated views of the overall economy, specific devices, and / or other factors that may influence the perception of value held by one or more potential customers.

[0104] As shown in Figure 5, the predictive modeler 508 and / or the master data aggregation manager 504 can interact with a wide range of datasets from a wide range of sources. In some exemplary implementations, such as when datasets are available in multiple different formats, the master data aggregation manager 504 can work in conjunction with the data filtering manager 506 to scale, cleanse, normalize, and / or otherwise format the various datasets so that they can be processed by the predictive modeler 508. Upon receiving aggregated data from the master data aggregation manager 504, the predictive modeler applies a predictive model to produce one or more model outputs, shown in Figure 5 as model outputs 510A to 510N. For example, in a scenario where a particular inventory incorporates mobile devices from multiple different manufacturers, each of the model outputs 510A to 510N may provide identification information for a specific channel in either or both inter-firm and / or firm-to-customer contexts through which a given portion of the inventory may be distributed, along with indices for applicable pricing and / or other conditions.

[0105] In some exemplary implementations of dataflow 500, the predictive modeler 508 may use a MARS model and / or another machine learning model or trainable model such that, over time, the predictive modeler 508 can improve its determination of one or more channels and / or conditions through which resources can be efficiently distributed.

[0106] In some such embodiments, the predictive modeler 508 may use machine learning or equivalent techniques to improve the prediction and modeling of channels and conditions through which resources can be efficiently distributed. In some examples, the predictive modeler 508 may provide a model to be trained, generally configured to provide outputs such as scores (e.g., confidence scores), recommendations, etc., given a set of input features. In some embodiments, the model to be trained can be generated using supervised or unsupervised learning. In some examples, such training may occur offline during the startup phase of the system or in real time or near real time during the execution of the methods shown in the diagrams described (e.g., predicting and modeling the best channels for resource distribution). The model to be trained may include the result of clustering algorithms, classifiers, neural networks, or ensembles of trees, in that the model to be trained is configured to map input values ​​or input features to one of a set of predefined output scores or recommendations, and to modify or fit the mapping in response to historical data returned from previous iterations (e.g., measured distributions, such as those derived from available data), or is otherwise trained.

[0107] Alternatively or additionally, the model to be trained may be trained to extract one or more features from historical data using pattern recognition, based on unsupervised learning, supervised learning, semi-supervised learning, reinforcement learning, association rule learning, Bayesian learning, and solutions of probabilistic graphical models, among other computational intelligence algorithms that can extract patterns from data using interactive processing. In some examples, historical data may include data generated using user input, crowd-based input, etc. (e.g., user confirmation).

[0108] In some examples, the predictive modeler 508 may be configured to apply the model being trained to one or more inputs to identify a set of confidence scores. For example, if the input features are competitive sales information that may be obtained from one or more data sources, the predictive modeler 508 may apply such data to the model being trained to determine whether the resulting predicted channels and / or pricing are accurate. In some examples, the trained model outputs a proposed confidence score based on other predictions and / or measurements using the same data.

[0109] Regardless of the exact configuration of the forecast modeler 508, upon receiving a request data object (and the necessary extraction or analysis of the data contained therein and / or other data related to the request), the forecast modeler 508 retrieves and / or otherwise receives one or more data objects from the repositories 502A-502N to determine the channels, pricing, and / or other conditions that apply to the predicted disposal of the inventory referenced in the request data object.

[0110] Figure 6 is a flowchart of an exemplary process 600 for predicting and modeling one or more channels and / or conditions that enable the efficient distribution of resources in a given environment. As shown in block 602, process 600 begins by receiving a request data object from a user. The request data object can be expressed in any format that incorporates a wide range of information and allows the request data object from a system associated with the user, such as a request source system 104, to be transmitted to a machine learning model and / or a system associated with such a model. Generally, the request data object incorporates enough information to identify inventory and / or other resources associated with the request and may further identify time and / or other conditions that will affect the likely disposal of future inventory. In some exemplary implementations of block 602, the request data may also include authenticated indicators of the user's identity.

[0111] As shown in block 604, process 600 continues to extract a request dataset for the relevant inventory from the request data object. As described herein, the request dataset may contain enough information to identify the relevant inventory, such as the number of mobile devices and / or the number of such devices to be distributed. In some exemplary implementations, the request dataset may include additional set information, such as information that may be available from any of the data warehouses or other repositories described herein and / or other information related to the request itself.

[0112] In block 606, process 600 involves the reception of a set of context data objects. The context objects received in block 606 may include any of the datasets described herein and / or otherwise conceived, including but not limited to datasets that can be stored in one or more memory, data warehouses, and / or other data repositories. As illustrated in process 600, an exemplary implementation of block 606 involves context data objects and datasets associated with resources and channels through which such resources may be delivered and / or otherwise distributed. This data is used to drive predictive models used to identify and model channels and conditions that will enable the efficient distribution of relevant inventory and / or other resources at future times.

[0113] As shown in block 608, process 600 also includes generating and / or otherwise extracting predicted channels and / or condition sets using a machine learning model (e.g., through the application of received context data objects and datasets). In some exemplary implementations, the model can be a MARS model, and when the relevant dataset is applied to the model, one or more channels and associated conditions (e.g., pricing, capacity, etc.) are predicted and modeled to identify channels and conditions that enable the efficient distribution of the relevant resources.

[0114] As shown in block 610, the process 600 also includes displaying a renderable object on the user device that has a predicted channel and condition dataset. In some exemplary implementations, the renderable object may be sent to the user device and presented to the user in a manner that allows the user to view and interact with the channel information, condition information, and / or other content contained in the predicted channel and condition dataset. Exemplary implementations in the context of channel prediction and modeling As noted herein, several exemplary implementations arise in the context of the resale of mobile devices received in connection with the performance of insurance programs and / or other service contracts. In some such scenarios, mobile devices are directed to one or more aggregators that can distribute mobile devices through various commercial channels. In connection with identifying and selecting the aggregators (or other channels) to which one or more sets of mobile devices are directed, heterogeneous data of numerous categories are captured, scaled, and / or otherwise processed to enable algorithmic hierarchical structuring of aggregators and the direction of resources to those aggregators.

[0115] In some exemplary implementations, several processes are involved in identifying available inventory to be distributed, receiving bids from aggregators for portions of that inventory, algorithmically tiering aggregators, creating and applying decay curves to offers associated with aggregator bids, determining the optimal offer and profit calculation from among the offers from aggregators, and allocating inventory across available channels. These processes tend to occur in regular cycles (weekly, monthly, and / or other regular schedules, etc.). Figure 7 is a flowchart illustrating exemplary processes 700 that reflect these and other operations in some exemplary implementations that may be used for allocating resources to aggregators.

[0116] As shown in block 702, an exemplary process 700 includes obtaining resource inventory and one or more offers from aggregators. In a given cycle, upon receiving a list of available inventory and / or inventory expected to be distributed, the system shares all or part of the available inventory information with the relevant group of aggregators. Based on this available inventory information, each aggregator prepares an offer, which may take the form of a request data object containing multiple request parameters, such as, for example, a bid price for one or more SKUs, expected margin information, the quantity of various inventory elements requested by the aggregator, and / or other information requested as part of the bidding process. In some exemplary implementations, additional information about aggregators may be provided by the aggregators and / or determined by the system to construct a channel profile that reflects a set of properties associated with a given aggregator.

[0117] As shown in block 704, exemplary processing 700 includes updating relevant attenuation parameters and associated tiering parameters. In addition to soliciting bids and / or other resource requests from the aggregator, the system updates the bid attenuation parameters and tiering parameters before calculating the tier to which the aggregator is assigned and the attenuation curve applied to the collected bids. In some exemplary implementations, the set of tiering parameters and / or the set of attenuation parameters may be received by the system as a data object from which relevant parameters can be extracted for use by the system.

[0118] Because the heterogeneous data categories used in relation to exemplary implementations may arise from multiple independent sources and / or reflect quantities, values, and / or other metrics set on multiple different scales, one of the data processing steps used in relation to the algorithmic hierarchy may more easily combine and process data scaling, which may result in transformed numbers, such as a limited set of integers or values ​​within a scaled range.

[0119] One of the factors that may be used in relation to the tiering of one or more aggregators is the volume at the portfolio level offered by a given aggregator. In some exemplary implementations, the relevant volume is the sum of all volumes offered by the aggregator across all relevant SKUs that can be distributed using the aggregator. It will be understood that such a volume metric can provide a gauge to the overall volume of mobile devices and / or other resources that the aggregator is looking to purchase and can further indicate the scale of business that the aggregator can offer. Since the information underlying the volume calculation is usually expressed as the actual number of units for each relevant SKU, the scaled value can be achieved using a scoring algorithm that ranks each aggregator based on the sum of the expressed volumes, assigning the highest score to the aggregator with the highest rank and assigning progressively lower scores to other aggregators based on the aggregator's rank.

[0120] Another factor that may be used in relation to tiering one or more aggregators is the portfolio-level profit margin expected by one or more aggregators. In some exemplary implementations, the portfolio-level profit margin is calculated by summing the profit margins across all SKUs identified by a given aggregator. This aggregated portfolio-level profit margin will be understood to represent the total profit margin that may be available through a given aggregator. Since the information underlying the portfolio-level profit margin is usually expressed as a monetary value, a scaled value may be achieved using a scoring algorithm that ranks aggregators based on their respective profit margins, assigning the highest score to the aggregator with the highest expected margin and assigning progressively lower scores to the other aggregators based on their rank.

[0121] Another factor that can be used in relation to tiering one or more aggregators is entropy, or a measure of diversity associated with a given aggregator. In some exemplary implementations, the entropy measure reflects the variability offered by an aggregator across the various unique SKUs associated with it. This information provides insight into how many different types of devices an aggregator is looking to purchase and indicates the scale of business the aggregator can offer. In one exemplary implementation, the entropy measure is determined and scaled by sorting the associated CNNs according to their respective revenue potential by multiplying their CNN volumes by their predicted average selling prices. The sorted devices are then joined or binned into categories (e.g., 10 categories) according to their rank. The aggregator-level entropy measure can then be obtained using the formula E = Σn * log n, where n is the volume of devices bid in a given bid divided by the total volume of devices bid. The entropy score is then assigned an integer score based on the inverse ranking of the entropy values. Therefore, a higher entropy score for an aggregator tends to mean that the aggregator is bidding on a large number of CNNs and, from a variability-focused perspective, has potentially better customers for mobile device providers.

[0122] Another factor that can be used in relation to tiering one or more aggregators is the aggregator's specialization. In some exemplary implementations, identifying information about the geographical markets in which an aggregator concentrates its efforts is relevant to determining the degree to which an aggregator competes in a given market. For example, if specialization in a domestic market tends to be overly competitive, an aggregator's geographical focus can be assigned on a point scale that incorporates positive and negative numbers, such as integers from -2 to 2, with domestic-only aggregators receiving -2, mostly domestic aggregators receiving -1, aggregators with equal domestic and international footprints receiving 0, mostly international aggregators receiving 1, and fully international aggregators receiving 2.

[0123] Another factor that may be used in relation to tiering one or more aggregators is the length of the relationship between the aggregator and the source of mobile devices and / or other resources. In some situations, the length of the relationship tends to correlate with the stability of the business relationship. To convert temporal measurements into scaled values, a scoring algorithm may be used that calculates the length of the relevant relationship in days and then provides an inverse ranking to ensure that the longest relationship receives the most points.

[0124] Another factor that may be used in relation to tiering one or more aggregators is determining whether an aggregator failed a relevant audit. In some situations, failing an audit indicates that the aggregator should undergo additional scrutiny and / or penalties before being allocated mobile devices and / or other resources to it. Since failing an audit is a binary condition, a scoring algorithm may be used to apply a binary score to a given aggregator, for example, a score of -1 for aggregators that failed the audit and a score of zero for aggregators that did not fail.

[0125] Another factor that may be used in relation to tiering one or more aggregators is the invoice amount each inter-company aggregator has provided in previous offer cycles. In some situations, previous invoice amounts are an indicator of the actual business volume provided by a given aggregator, as opposed to the forecast level reflected in the offer or bid. Since invoice amounts are typically expressed as monetary value in their native form, invoice values ​​can be scaled by applying an algorithm that identifies the highest total invoice amount among a set of aggregators, gives that aggregator the highest score, and then progressively lowers the score applied to lower-ranked aggregators.

[0126] Other factors that may be used in relation to tiering one or more aggregators include, for example, rankings based on the D&B Paydex score, the degree to which an aggregator has an exclusive relationship with a source of mobile devices and / or other resources, the value and / or volume of return authorizations requested by the aggregator over time, the timeliness of bids, and the timeliness of payments.

[0127] As shown in block 706, exemplary process 700 includes applying hierarchical parameters to the relevant aggregators. Regardless of the exact factors used to generate the scaled scores used to hierarchize the group of aggregators, at the time of score compilation, the aggregators may be automatically divided into multiple hierarchies. For example, based on scores built over four or more (or, for example, another number) bidding cycles, one set of aggregators may be assigned to the top hierarchy, while lower-ranked aggregators may be assigned to lower hierarchies. For example, the top 40% of aggregators may be assigned to hierarchy 1, the next 30% may be assigned to hierarchy 2, and the remaining 30% may be assigned to a lower third hierarchy. Regardless of the specific thresholds applied, the aggregators and associated channel profiles are assigned to hierarchies based at least in part on the application of one or more of the hierarchical parameters described herein and / or additional information to the hierarchical algorithm received in the bids from the aggregators. In some exemplary implementations, the hierarchy assigned to a given aggregator is used in relation to further algorithmic evaluation of bids or multiple bids provided by the given aggregator, and / or allocation of inventory across a set of eligible aggregators.

[0128] One of the technical challenges that arise in exemplary implementations handling resource distribution is the potential for high volatility in market and spot prices, which is further exacerbated by the possibility of errors in third-party datasets and other data sources. Because machine learning algorithms tend to be sensitive to the range and distribution of attribute values, dealing with outlier data can be important in avoiding situations where the training process is overextended or altered due to outlier data. In some situations, such as when multiple data points are captured relatively close together in time, it may be advantageous to remove outlier data points (such as pricing values ​​and / or rate of change values) that are outside the expected range. In some situations, such as when data points are sparse, it may be advantageous to replace outliers with interpolation, weighted averages, and / or moving averages between two or more adjacent data points.

[0129] As shown in block 708, exemplary processing 700 includes applying a decay curve to offers received from one or more aggregators. In addition to assigning one or more aggregators to a given hierarchy based on specific scaled parameters, as noted herein, exemplary implementations further conceive of applying decay curves to bids and / or multiple bids associated with a given aggregator. As noted herein, some aspects of aggregator evaluation, such as comparing bids received from aggregators and allocating resources to various channels, involve the use of multiple datasets obtained over time. To prevent the data over time from obscuring current trends and / or impairing the predictive power of the associated model or multiple models, some exemplary implementations conceive of using decay coefficients applied to bids and / or data over time to reduce the impact of the data over time and ensure that the model retains its ability to predict future pricing information and / or other information relating to the ability to efficiently distribute inventory through one or more channels. One approach to generating damping coefficients and / or processing related data in other ways involves using MARS (Multivariate Adaptive Regression Spline) models. MARS is a non-parametric regression technique (sometimes considered an extension of linear models) that automatically models nonlinearity and interactions between variables. Generally, MARS constructs models of the following form:

[0130]

number

[0131] In some scenarios, applying a MARS-based model to establish a decay function allows pricing information provided by aggregators and / or obtained in other ways (e.g., through analysis of sales on distributed user platforms, such as eBay® and / or other channels where mobile devices can be sold directly to consumers) to be fed into a decay model that can model the price at which customers are likely to purchase mobile devices at a given time in the future. For example, pricing estimates and market pricing information obtained from aggregators, along with other scaled data streams (e.g., those received in relation to aggregator evaluations, those included in bids, and / or additional market data), can be given as input to a MARS-based model to create a pricing curve that predicts the likely decay of pricing for a given mobile device SKU over time. Using a combination of aggregator hierarchical ranking and a predicted decay price curve, mobile device inventory can be directed to the aggregator most likely to be able to distribute the mobile devices when they actually become available.

[0132] As specifically noted herein, several exemplary implementations arise in situations where used mobile devices and / or other resources are acquired through buyback programs, insurance contracts, and / or other arrangements that prevent a central actor from having complete control over the content and volume of acquired inventory. However, information used to stratify aggregators (e.g., bids, assumed pricing, assumed profit margin information, etc.), coupled with a predicted price decay curve obtained using a MARS-based model, can be combined with and applied to a logistic regression model to determine the price and / or price range at which inventory can be adequately acquired. This allows inventory that is not effectively distributed through one channel to be redirected to an alternative channel with capacity.

[0133] For example, a MARS-based model can produce a pricing decay function that outputs predicted prices for all relevant mobile devices and / or other resources within a given future time frame. This pricing information can then be combined with tiering information and a list of all devices to be allocated. For instance, pricing information provided in bids from aggregators, additional market data, data defining internal margin guidelines, etc., can be combined with expected future prices to calculate the price at which each available item in inventory is likely to sell during a future time period.

[0134] After a price decay function is applied to the bids received from the aggregator, the system generally retains three categories of information that can be combined with a model to identify the best offer(s) and profit(s) for available inventory, and can be applied to this in other ways. This information, which includes but is not limited to the results of stratification and the application of decay curves to the associated offers, as shown in block 710 of Figure 7, can be retained in memory.

[0135] As shown in blocks 712 and 714, the exemplary process 700 includes determining one or more optimal offers, determining resource allocations, and applying resource allocations. It will be understood that not all aggregators, other channels, and their respective bids are created equally. Several different data points are combined in relation to assigning tiers to aggregators, as specifically noted herein. In addition to the tiered approach, the system and / or other central actors may be involved in different relationships bounded by different rules and / or other thresholds governing at least a portion of the inventory allocation. For example, one or more aggregators may be internal partners with a central actor and / or have a whole or partial exclusive agreement that grants the aggregator the right to have at least a portion of the inventory, regardless of the competitiveness of its bid and / or the tier to which the aggregator is assigned. In some exemplary scenarios, such particular relationships may be sufficient to allocate all or most of the available inventory.

[0136] In situations where inventory remains available after rules associated with a specific relationship have been fulfilled, bids from aggregators are ranked. In some exemplary implementations, ranking may be performed across all aggregators for a given set of items in inventory. In other exemplary implementations, bids may be further subdivided based on the quantities requested in relation to the bids prior to ranking. After bids have been ranked, some exemplary implementations apply one or more thresholds to limit the number of bids under consideration. For example, the threshold may be set to three bids (or any other number of bids) so that the top three (and / or groups of aggregators submitting the three highest bids) are considered to meet the threshold. In some such exemplary implementations, the hierarchy to which high-bid aggregators are assigned is considered to exclude bidders from unfavorable tiers and / or include bidders from preferred tiers.

[0137] Once the three (or more) aggregators with the highest bids are identified, the relevant resource inventory is allocated to the channel profiles. Based on the decay pricing curve, the generated probabilities, and the calculated profitability associated with the highest bid that otherwise satisfies the relevant thresholds, an offer price is generated for each relevant item in the inventory. This offer price is then used to calculate the profit margin from the perspective of the central actor, and if the margin is positive, the inventory items can be algorithmically allocated based on the calculated margin, which may be further indicated by a given aggregator and / or by an amount requested by any intermediate calculation (such as probability calculation) as referred herein. It will be understood that other factors may be used in the allocation of resources, particularly in some situations where considerations such as participation in the channel profile, perception of fairness, and / or other factors are permitted to influence the allocation. For example, the allocation frequency attribute may be calculated by determining the ratio between the number of times a particular channel profile has submitted a bid and the number of times the channel profile has received an allocation. In other exemplary situations, cloud and / or oracles may be referred to to coordinate the allocation.

[0138] Additional steps may be performed. For example, after inventory is initially allocated according to the aggregator's tiering and the predicted decay pricing curve, requests from aggregators for additional inventory for distribution (along with bids for that inventory) are received and considered. Demand for a given SKU and / or other inventory items is identified and scaled, and bid pricing received from aggregators is extracted for the available additional inventory. Based on the bid pricing and the requested inventory for the bids, the aggregator's bids are re-ranked, thereby determining the best bid for the additional inventory (which may differ from the initial ranking obtained through the tiering process described above). In some exemplary implementations, the bids are applied to another model that generates a set of probabilities that a given aggregator can distribute a given allocation, and further multiplies the generated probabilities by the profitability associated with the best bid.

[0139] In some exemplary implementations, various parameters associated with one or more channel profiles may vary, making a direct comparison of one parameter with another inappropriate in situations where such a comparison is desired. For example, one channel profile may contain bids or other offers configured to be valid for 30 days or more, while a second channel profile may contain bids or other offers configured to be open for only one week. In such situations, it may be necessary to selectively apply decay curves and / or consider timing to ensure that bids at different times decay so that bids can be compared over similar timeframes. For example, if one channel profile offers bids that are valid for a full month, the first weekly bids may decay over a month while the second channel profile offers a series of bids on a weekly basis, allowing for an accurate comparison with the month-long bids. In such an example, the second weekly bids may decay over three weeks, the third weekly bids over two weeks, and the fourth weekly bids over one week.

[0140] Based on available inventory and underlying aggregator information, the probability that a given aggregator will accept an updated item associated with additional inventory is calculated and used to set the offer price when the additional inventory becomes available on the market and / or can be bought back from aggregators with slower inventory movement. Thus, based on the initial tiering and price decay models, mismatches between calculated device allocations can be addressed through inventory rerouting and / or acquisition of additional inventory to meet the demand for a given channel beyond the initial allocation. Exemplary system environment for resource offer generation. Figure 8 shows another exemplary system environment 800 in which an implementation form with improved resource offer generation may be realized. The depiction of environment 800 is not intended to limit or otherwise restrict the embodiments described and conceived herein to any particular configuration element or system, nor is it intended to exclude any alternative configuration or system of the set of configurations and systems that may be used in connection with embodiments of the present disclosure. Rather, Figure 8 and the environment 800 disclosed therein are presented simply to provide an exemplary basis and context to facilitate some of the features, aspects, and uses of the methods, apparatus, and computer program products disclosed and conceived herein. Although many of the aspects and components presented in Figure 8 are shown as discrete, separate elements, it will be understood that other configurations may be used in connection with the methods, apparatus, and computer programs disclosed herein, including configurations that combine, omit, and / or add aspects and components. For example, in some embodiments, the resource offer generation system 802 may be combined partially or completely with the prediction system 102 to form a single component configured to perform the operations disclosed herein with respect to both systems.

[0141] Embodiments implemented in a system environment such as system environment 800, as described above, advantageously provide improved resource offer generation associated with a given regional program identifier by preparing and / or retrieving one or more resource offer generation input datasets, and / or assumed resource volume datasets, average distribution request amount datasets, and market intelligence datasets, generating a suitable market offer set using an exception detection model based on the retrieved datasets, receiving benchmark and portfolio target datasets, and generating a resource offer set by applying one or more of the retrieved and generated datasets to a resource offer generation model and / or submodels therein. Some such implementations conceive of rendering an offer adjustment interface to a client device associated with an offer control user, the offer adjustment interface is configured to receive manual adjustments to the generated resource offer set for updating to create an adjusted resource offer set. Furthermore, some such embodiments result in the rendering of an approval interface to an approval device associated with the offer approval user, the interface configured for improved analysis of the adjusted or generated resource offer set and for approval or rejection of the adjusted or generated resource offer set. Some such embodiments leverage hardware and software configurations or environments for improved resource offer generation through actions and behaviors described herein, conceived, and / or otherwise disclosed.

[0142] As shown in Figure 8, the system 800 may include a prediction system 102, a request source system 104, and a content system 106. Each of these components may function similarly to perform the operations described above with respect to Figure 1. For example, the prediction system 102 is configured to store information associated with a channel and other information related to the efficient prediction and modeling of the conditions and channels through which resources can be distributed and the generation of one or more associated messages and / or digital content item sets, including a prediction system server 102B or a prediction system device 102D, request data objects, users, resources (e.g., used mobile devices), and / or request data objects, channel context data objects, other datasets, interfaces associated with such data objects or datasets, a request source system, a channel content system, and / or information associated with a channel and other information related to the efficient prediction and modeling of the conditions and channels through which resources can be distributed and the generation of one or more associated messages and / or digital content item sets. The system may include a prediction system module 102A configured to receive, process, transform, transmit, communicate with, and evaluate request data objects, channel context data objects, such data objects, other datasets, and content and other information associated with the associated interface, via a server such as a prediction system device 102D (other than via the user interface of the prediction system server 102B), which is configured to provide additional means for interface with the system database 102C, other components of the prediction system 102, and / or other components shown in or otherwise conceived in the system environment 100. The prediction system server 102B and / or prediction system device 102D may be able to connect to the prediction system via any of several public and / or private networks, including but not limited to the Internet, public telephone networks, and / or networks associated with a particular communication system or protocol, and may include at least one memory for storing applications and communication programs.

[0143] Similarly, the system environment 800 also includes a content system 106, which includes a content module 106A, a content server 106B, and a content system database 106C, and the content system 106 is configured to communicate with the prediction system 102 to provide information that the prediction system 102 may need when predicting and modeling the conditions and channels through which resources may be distributed. Additionally, the system environment 800 includes a request source system 104, which may transmit one or more request data objects, request data object information, and / or additional content or other information associated with one or more request data objects.

[0144] The system environment 800 further includes a resource offer generation system 802. The resource offer generation system 802 includes a resource offer generation system module 802A, a resource offer generation system server 802B, and a resource offer generation system database 802C. The resource offer generation system module 802A may be configured to receive, process, transform, transmit, communicate with, and evaluate offer requests, resource offer data objects, such data objects, other datasets, and content and other information associated with related interfaces, in order to generate resource offer sets, facilitate the coordination of resource offer sets, and / or manage the approval of submitted resource offer sets. The resource offer generation system module 802A may perform these operations, and / or additional or alternative operations, via a server, a resource offer generation system server 802B, or a corresponding device. The resource offer generation system server 802B is connected to any number of public and / or private networks, including but not limited to the Internet, public telephone networks, and / or networks associated with specific communication systems or protocols, and may include at least one memory for storing at least applications and communication programs.

[0145] The resource offer generation system 802 also includes a resource offer generation database 802C which may be used to store offer requests, users, information associated with resources (e.g., used mobile devices), and / or corresponding information associated with offer requests, regional program data objects or corresponding information, resource offer sets, coordinated resource offer sets, other datasets, interfaces associated with offer requests, and / or other information related to the improved generation of resource offer sets. The resource offer generation system database 802C may be accessed by resource offer system modules 802A and / or resource offer systems 802B. In some embodiments, the resource offer generation system database 802C may be accessed by prediction system modules 102A, prediction system servers 102B, and / or prediction system devices 102D to store information received, generated, or accessed by components of the prediction system 102. While Figure 8 depicts the resource offer generation system database 802C as a single structure, it will be understood that the generation system database 802C may be implemented, additionally or alternatively, to enable storage in a distributed manner and / or in facilities that are physically distant from each other and / or other components of the offer generation system 802. Additionally or alternatively, in some embodiments, some or all of the prediction system database 102C and the resource offer generation system database 802C may be embodied as a single collaborative database or distributed repository.

[0146] It will be understood that all components shown in Figure 8 may be configured to communicate over any wired or wireless network, including wired or wireless local area networks (LANs), personal area networks (PANs), metropolitan area networks (MANs), wide area networks (WANs), and interfaces with the accompanying hardware, software, and / or firmware (e.g., network routers and network switches) necessary to implement the above networks. Networks such as, for example, mobile phones, 802.11, 802.16, 802.20, and / or WiMAX networks, as well as public networks such as the Internet, private networks such as intranets, or a combination thereof, and currently available or future-developed networking protocols including but not limited to TCP / IP-based networking protocols, may be used in connection with the system environment 100 and embodiments of the present invention that may be implemented therein or involved therein.

[0147] Overall, as depicted in System Environment 800, in addition to the processes and operations simplified and described with respect to Systems 102-106, the Resource Offer Generation System 802 engages in inter-machine communication with Request Source System 104, Prediction System 102, and Context Content System 106 via one or more networks to facilitate the processing of offer requests received from users, improved generation and management of resource offer sets and corresponding resource offer data objects, and the generation and / or transmission of control signals to result in rendering interfaces for viewing resource offer sets and / or offer analysis datasets and / or market information, adjusting resource offer sets, and / or approving submitted adjusted resource offer sets. Exemplary apparatus for implementing improved resource offer generation. It will be understood that the resource offer generation system 802 may be embodied by one or more computing systems, such as the device 900 shown in Figure 9. As illustrated in Figure 9, the device 900 may include a processor 902, memory 904, input / output circuitry 906, communication circuitry 908, data management circuitry 910, and model performance circuitry 912. The device 900 may be configured to perform any of the operations described herein.

[0148] Regardless of how the apparatus 900 is embodied, the apparatus of an exemplary embodiment includes a processor 902 and a memory device 904, and optionally an input / output circuitry 906 and / or a communication circuitry 908, or is otherwise configured to communicate. In some embodiments, the processor (and / or coprocessor, or other processing circuitry assisting or otherwise associated with the processor) may communicate with the memory device via a bus for passing information between components of the apparatus. The memory device 904 may be non-transient and may include, for example, one or more volatile and / or non-volatile memories. In other words, for example, the memory device may be an electronic storage device (e.g., a computer-readable storage medium) including gates configured to store data (e.g., bits) that may be retrieved by a machine (e.g., a computing device such as a processor). The memory device may be configured to store information, data, content, applications, instructions, etc., to enable the apparatus to perform various functions, as in the exemplary embodiments of the present disclosure. For example, the memory device may be configured to buffer input data for processing by the processor. Additionally or alternatively, memory devices may be configured to store instructions for execution by the processor.

[0149] As described above, the apparatus 900 may be embodied by a computing device. However, in some embodiments, the apparatus may be embodied as a chip or chipset. In other words, the apparatus may include one or more physical packages (e.g., a chip) including materials, components, and / or wires on a structural assembly (e.g., a baseboard). The structural assembly may provide physical strength, size preservation, and / or limitations on electrical interactions of the component circuitry contained therein. Thus, in some cases, the apparatus may be configured to implement embodiments of the present disclosure on a single chip or as a single "system on a chip". Thus, in some cases, the chip or chipset may construct means for performing one or more operations to provide the functions described herein.

[0150] The processor 902 can be embodied in several different ways. For example, the processor can be embodied as one or more of various hardware processing means, such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), a processing element with or without an associated DSP, or various other processing circuit mechanisms including integrated circuits such as ASICs (Application-Specific Integrated Circuits), FPGAs (Field-Programmable Gate Arrays), microcontroller units (MCUs), hardware accelerators, and dedicated computer chips. Thus, in some embodiments, the processor may include one or more processing cores configured to run independently. A multicore processor can enable multiprocessing within a single physical package. Additionally or alternatively, the processor may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelines, and / or multithreads.

[0151] In exemplary embodiments, the processor 902 may be configured to execute instructions stored in a memory device 904 or otherwise accessible to the processor. Additionally or alternatively, the processor may be configured to execute hardcoded functionality. Thus, whether configured by hardware or software, or a combination thereof, the processor may represent an entity (e.g., physically embodied in a circuit mechanism) that, while configured accordingly, can perform the operations according to embodiments of the present disclosure. For example, if the processor is embodied as an ASIC, FPGA, etc., the processor may be hardware specifically configured to perform the operations described herein. Alternatively, as another example, if the processor is embodied as an executor of software instructions, the instructions may specifically configure the processor to perform the algorithms and / or operations described herein when the instructions are executed. However, in some cases, the processor may be the processor of a specific device (e.g., a pass-through display or a mobile terminal) configured to use embodiments of the present disclosure by further configuration of the processor with instructions for performing the algorithms and / or operations described herein. The processor may include, among other things, a clock, an arithmetic logic unit (ALU), and logic gates configured to support the operation of the processor.

[0152] In some embodiments, the device 900 may optionally include an input / output circuit mechanism 906, such as a user interface, which communicates with the processor 902 to provide output to the user and, in some embodiments, can receive an indicator of user input. Thus, the user interface may include a display and, in some embodiments, a keyboard, mouse, joystick, touchscreen, touch area, soft keys, microphone, speaker, or other input / output mechanism. Alternatively or additionally, the processor may include a user interface circuit mechanism configured to control the display and, in some embodiments, at least some functions of one or more user interface elements such as a speaker, linger, microphone, etc. The processor and / or a user interface circuit mechanism including the processor may be configured to control one or more functions of one or more user interface elements via computer program instructions (e.g., software and / or firmware) stored in memory accessible to the processor (e.g., memory device 904, etc.).

[0153] The device 900 may also optionally include a communication circuit mechanism 908. The communication circuit mechanism 908 may be any means, such as a device or circuit mechanism, embodied either in hardware or a combination of hardware and software, configured to receive and / or transmit data between the device and a network and / or any other device or module in communication. In this regard, the communication interface may include an antenna (or more antennas) and supporting hardware or software to enable communication with wired and / or wireless communication networks. Additionally or alternatively, the communication interface may include circuit mechanisms to interact with the antenna(s) to cause the transmission of signals through the antenna(s) or to process the reception of signals received through the antenna(s). In some environments, the communication interface may alternatively or further support wired communication. For example, the communication interface may include a communication modem and / or other hardware / software to support communication via cable, digital subscriber line (DSL), universal serial bus (USB), or other mechanisms.

[0154] As shown in Figure 9, the device may also include a data management circuitry 910. The data management circuitry 910 includes hardware configured to retrieve, receive, generate, or otherwise access information and data for use in generating appropriate market offer sets, generating resource offer sets, and / or optimizing resource offer sets. For example, the data management circuitry 910 may access one or more local remote databases and / or remote databases to create, retrieve, or otherwise prepare base tables for use by one or more models. The base tables may be associated with one or more stored tables, datasets, etc., which contain inputs to one or more models, such as resource offer generation models. In some embodiments, the data management circuitry 910 is configured to prepare one or more resource offer generation input datasets, such as via base tables associated with one or more databases, and the resource offer generation input datasets may include historical offer datasets, resource list datasets, market intelligence datasets, and resource mapping datasets.

[0155] The data management circuit mechanism 910 may be configured to retrieve, access, or create mappings of various resource identifiers associated with various third-party entities, aggregators, etc., to standardized resource set identifiers such as CNNs. For example, using the example of used mobile phones as resources, used mobile phones having the same attributes or specifications (e.g., carrier, memory size, model, manufacturer) may be associated with different resource identifiers for a first third-party entity and a second third-party entity. Resource mapping may be performed automatically, manually, or a combination of both automatic and manual steps to map third-party resource identifiers to standardized resource set identifiers such as CNNs. The mappings may be stored in a database or repository as a resource mapping dataset.

[0156] In some embodiments, the data management circuitry 910 may receive, acquire, and / or prepare market intelligence data from various third parties. The received market intelligence datasets may be associated with third-party systems and may require standardization and / or sanitization for use by one or more data models using resource mapping datasets. The data management circuitry 910 may include means configured to execute one or more processing algorithms on the received market intelligence datasets before storing the market intelligence datasets for use by one or more models.

[0157] In some embodiments, the data management circuitry 910 may receive, acquire, prepare, and / or otherwise access a hypothetical resource volume dataset. The hypothetical resource volume dataset may include stored channel profiles, where resources are distributed when allocated by another system, such as the prediction system 102. The hypothetical resource volume dataset may be generated by another system, such as the prediction system 102, and stored in a database accessible via the data management circuitry 910. For example, the hypothetical resource volume dataset may be part of the data output by the prediction system 102.

[0158] In some embodiments, the data management circuitry 910 may receive, retrieve, prepare, and / or otherwise access an average distribution request dataset. The average distribution request dataset may include at least the average selling price of various resources associated with various resource set identifiers. In some embodiments, the average distribution request dataset may be generated by another system, such as a forecasting system 102, or another system configured to generate the average distribution dataset based on the output of the forecasting system 102, and stored in a database accessible via the data management circuitry 910.

[0159] The data management circuitry 910 may provide an interface, such as an application programming interface (API), that enables other components of the system to acquire, generate, or otherwise access various datasets. In some embodiments, the data management circuitry 910 may acquire information about one or more resources or economic factors associated with the distribution of resources. For example, the data management circuitry 910 may retrieve and / or standardize data associated with the distribution of resources, including, but not limited to, any of the following: previous distribution of similar resources by the system; distribution of resources by one or more third-party entities (e.g., competitors); neutral competitor entities (e.g., enterprise-versus-consumer competitors); macroeconomic factors associated with the resources; promotional periods associated with the distribution of resources; and / or other information that can be used to generate improved resource offer generation, obtained from and / or otherwise associated with the content system 106.

[0160] The data management circuitry 910 may facilitate access to information for use by one or more models for improved resource offer generation through the use of applications or APIs executed using a processor such as processor 902. However, it should also be understood that in some embodiments, the data management circuitry 910 may include a separate processor, a specially configured field-programmable gate array (FPGA), or an application-specific interface circuit (ASIC) to manage the retrieval, access, and / or use of the relevant data. The data management circuitry 910 may also provide an interface that allows other components of the system to add, delete, or otherwise manage records to the resource offer generation system database 802C, and may also provide communication with other components of the system and / or external systems (e.g., prediction system database 102C) via a network interface provided by communication circuitry 908. Thus, the data management circuitry 910 may be implemented using hardware components of a device configured by hardware, software, or a combination of both hardware and software to implement these planned functions.

[0161] The device further includes a model performance circuit 912. The model performance circuit 912 includes hardware, software, or a combination thereof, configured to perform data validation for use in one or more models for improved resource offer generation, and to maintain, utilize, and apply one or more models, such as machine learning models, for improving algorithms and / or resource offer generation. The model performance circuit 912 may validate and / or receive and validate collection period data objects, data collection parameter value sets, and pre-required data record sets retrieved from associated databases and / or accessed in other ways, such as by utilizing the data management circuit 910, received by a client device (e.g., a request source system 104). The model performance circuit 912 may additionally or alternatively initiate a resource offer generation model and / or apply one or more relevant datasets to the resource offer generation model. In some embodiments, the model performance circuit may communicate with external systems and / or servers (e.g., cloud servers), either alone or in combination with one or more other components of the device configured to manage and run resource offer generation models and / or associated models and submodels. Exemplary process for generating and adjusting resource offers Figure 10 illustrates an exemplary data flow diagram 1000 for generating an optimal resource offer set via a resource offer generation system. The data flow diagram 1000 includes data flow steps between components such as subsystems of system 800, including a client device 1001, a resource offer generation system 1003, and an approval device 1005. The client device 1001 and the management device 1001 can each be embodied by a request source system, such as a request source system 104. The client device 1001 may be associated with an offer control user, such as an authenticated user, who authenticates and accesses the resource offer generation system 1003 with authorization to submit offer requests and / or adjust the generated resource offer set. Similarly, the approval device 1005 may be associated with an offer approval user, such as an authenticated user, who authenticates and accesses the resource offer generation system 1003 with authorization to review the submitted adjusted resource offer set. The resource offer generation system 1003 can be embodied by a resource offer generation system, for example, a resource offer generation system 802 embodied by device 900.

[0162] In dataflow 1000, some of the illustrated steps may be optional. Optional steps are illustrated with dashed lines in Figures 10 and 11. In some embodiments, one or more of the optional steps may be performed. In some embodiments, all of the optional steps may be performed.

[0163] In an optional step 1002, the client device 1001 may create and / or configure a regional program data object. In some embodiments, an offer control user (e.g., an analyst) may create a new regional program data object by accessing the interface via the client device 1001. Each regional program data object may be associated with at least a regional identifier (e.g., identifying a specific country or sub-region within a country) and a program identifier (e.g., identifying a specific set of offerings within a country). The offer control user may input one or more parameter values ​​associated with the regional program data object via the client device 1001, for example. For example, financial target parameters, pricing parameters, and / or business analysis associated with a particular regional program data object may be provided by the offer control user. In some embodiments, the offer control user may identify and manage existing regional program data objects by, for example, editing one or more parameter values ​​of an existing regional program data object.

[0164] In an optional step 1004, the resource offer generation system 1003 may store the configured regional program data object. The regional program data object was configured by the offer control user in step 1002 and may be received by the resource offer generation system 1003 when submitted by the offer control user via the client device 1001 (for example, when the offer control user activates a save or submit button associated with the interface for configuring the regional program data object). The regional program data object may be stored associated with a corresponding regional program identifier. The regional program identifier is capable of uniquely identifying the regional program data object and can be generated and / or determined by the resource offer generation system 1003.

[0165] In step 1006, the client device 1001 may initiate resource offer generation. In some embodiments, the client device 1001 initiates resource offer generation when the offer control user selects an existing regional program data object via the client device 1001 for which the offer control user wishes to generate a resource offer set. In some embodiments, the resource offer generation system 1003 may cause the rendering to the client device 1001 of an interface for the offer control user to select a regional program data object for which the offer control user wishes to generate a resource offer set. For example, the resource offer generation system 1003 may generate and / or transmit one or more control signals that produce a renderable object containing an interface rendered for selecting a regional program data object from a list of existing regional program data objects.

[0166] In step 1008, the client device 1001 may submit a collection period data object, or a corresponding collection period timestamp for defining the collection period data object, associated with the resource offer set to be generated. In some embodiments, the collection period data object is defined by or includes a collection period start timestamp and a collection period end timestamp. The collection period data object may represent a time interval over which the offer control user is attempting to provide resource offers based on the generated resource offer set. In some embodiments, the offer control user may input a collection start timestamp and a collection end timestamp to generate the corresponding collection period data object via an interface rendered to the client device 1001 (for example, via a user interface component such as a dropdown component for inputting the collection start timestamp and the collection end timestamp).

[0167] In step 1010, the resource offer generation system 1003 may receive a resource offer generation start request. The resource offer generation request may be received by an offer control user via a client device 1001 in response to an engagement, after inputting a collection period start timestamp and a collection period end timestamp to an interface component configured to transmit the resource offer generation start request. The resource offer generation start request may result in the preparation of one or more resource offer generation input datasets for use by one or more models, such as a resource offer generation model and / or an exception detection model. In some embodiments, the resource offer generation start request includes at least a collection period start timestamp and a collection period end timestamp selected by the offer control user, which may be used by the resource offer generation system when creating and / or determining a collection period data object. Alternatively, in some embodiments, the resource offer generation start request includes a collection period data object created and / or transmitted from a client device, e.g., client device 1001.

[0168] In step 1012, the resource offer generation system 1003 may validate the collection period data object. The resource offer generation system 1003 may validate that the collection period start timestamp associated with the collection period data object represents a future timestamp (e.g., today or later). The resource offer generation system 1003 may also validate that the collection period end timestamp associated with the collection period data object represents another future timestamp with respect to the collection period start timestamp (e.g., the collection period end timestamp is on or after the same date and / or time as the collection start timestamp). In this regard, the resource offer generation system 1003 is configured to validate that the collection period represents a valid range of future timestamps defined by the collection period start timestamp and the collection period end timestamp.

[0169] Additionally or alternatively, the resource offer generation system 1003 may verify that the time interval represented by the collection period data object does not overlap with another collection period data object for an existing request or stored resource offer set. For example, the resource offer generation system 1003 can query a repository, such as an offer approval repository, for all offer status records associated with a specific regional program identifier, and each offer status record is associated with a collection period data object, and each collection period data object for a stored offer status record is determined to not overlap with the input collection period. The resource offer generation system 1003 prevents multiple conflicts. If the collection period data object is not validated in step 1014, the resource offer generation system 1003 may provide an error message to the client device 1001. The error message may indicate that the selected collection period start timestamp and the selected collection period end timestamp are invalid (for example, the timestamps do not form a valid date timestamp range, or the interval embodied by the timestamps overlaps with another collection period for a pending or existing resource offer set). The error message may additionally or alternatively prompt the offer control user on the client device 1001 to enter a new collection period start timestamp and / or a new collection period end timestamp. The error message may be configured by the client device 1001 to render to the corresponding interface. If the collection period data object is validated in step 1014, the flow proceeds to step 1016.

[0170] In step 1016, the resource offer generation system 1003 may validate one or more resource offer generation input datasets. The resource offer generation input datasets may be retrieved from a repository or a set of repositories maintained by and / or accessible to the resource offer generation system 1003. The resource offer generation input datasets may include data extracted from or associated with multiple heterogeneous resources and / or repositories, and / or data retrieved by various data extraction and / or retrieval processes. For example, in some embodiments, the resource offer generation system 1003 and / or associated systems generate and / or prepare one or more resource offer generation input datasets through various data extraction and / or retrieval processes. In some embodiments, for example, one or more of the resource offer generation input datasets may be obtained through scraping of one or more tracked web resources, retrieval from public data repositories, or retrieval from private data repositories, which are derived and / or tracked through the resource offer generation system 1003 and / or associated systems.

[0171] In some embodiments, one or more resource offer generation input datasets are updated by the resource offer generation system (or associated system) at one or more predefined intervals. For example, resource offer generation input datasets may be updated daily, weekly, etc., or some resource offer generation input datasets may be updated at a first interval and some resource offer generation input datasets may be updated at a second interval. Each resource offer generation input dataset may be associated with a specific regional program identifier and / or collection period data object.

[0172] Additionally or alternatively, one or more of the resource offer generation input datasets may be updated in real time. In some embodiments, one or more of the resource offer generation input datasets are automatically updated in real time immediately before validation. In other embodiments, one or more of the resource offer generation input datasets are updated in real time when validation fails for one or more of the resource offer generation input datasets.

[0173] In some embodiments, each of the one or more resource offer generation input datasets is validated using one or more data sufficiency models. The data sufficiency models may determine whether the resource offer generation input datasets meet one or more predetermined requirements. For example, a data sufficiency check may determine whether one or more of the resource offer generation input datasets have been updated within a predetermined time interval (e.g., updated the previous day, the previous week, or another time interval). In some such embodiments, each of the resource offer generation input datasets may be associated with a timestamp of its last update. Additionally or alternatively, in some embodiments, a data sufficiency check may determine whether one or more of the resource offer generation input datasets meet an assumed precision threshold. For example, one or more data precision models may be used to determine the precision value for each of the resource offer generation input datasets based on assumed data format, missing data, etc. It should be understood that in other embodiments, additional or alternative data sufficiency checks may be performed in any combination to validate the resource offer generation input datasets.

[0174] The resource offer generation input dataset may be applied to one or more models, such as algorithmic models or machine learning models, for use in generating resource offer sets. The resource offer generation input dataset may be input to and / or otherwise utilized by one or more models for use in generating resource offer sets. For example, the resource offer generation input dataset may include one or more datasets for application to an exception detection model to generate a reliable resource characteristics dataset, e.g., a fair market offer set that may be applied by a resource offer generation model or otherwise utilized. Additionally or alternatively, the resource offer generation input dataset may include one or more datasets for application to a resource offer generation model to generate resource offer sets.

[0175] The resource offer generation input dataset may include a historical offer dataset, a resource list dataset, a market intelligence dataset, and a resource mapping dataset. Each of the resource offer generation input datasets may be obtained from a subsystem or device associated with the resource offer generation system 1003. In some embodiments, the resource offer generation system 1003 may communicate with one or more subsystems and / or other associated devices to obtain the resource offer generation input dataset via a database accessible to the resource offer generation system 1003. Each of the resource offer generation input datasets may be stored in a separate table in a database accessible to the resource offer generation system 1003, and / or may be stored in association with a base table linked to the table corresponding to the resource offer generation input dataset.

[0176] The resource offer generation input dataset may include a historical offer dataset. The historical offer dataset may include, at a minimum, information associated with previously generated offer data objects, resource acquisition information associated with previously generated offer data objects, and sales information associated with the aforementioned resources. Using the historical offer dataset, it is possible to extract and / or generate a hypothetical resource volume dataset, which may be associated with a specific resource set identifier for a specific regional program identifier.

[0177] The resource offer generation input dataset may include a resource list dataset. The resource list dataset may include a specific regional program identifier, a grade level for each resource set identifier associated with the resource, and the resources present in the inventory for that resource. The resource list dataset may also include warehouse details that may contain resource attributes mapped to each resource set identifier for the resource. For example, resource manufacturing identifiers and model identifiers may be mapped to resource set identifiers and assigned resource identifiers. The resource list dataset may also indicate whether a resource offer data object should be generated for the resources within the resource list dataset. For example, the resource list dataset may flag each resource that should generate a resource offer data object, for instance, using bit flags.

[0178] A mapping dataset may contain correlation information to link various resource identifiers associated with various third-party entities, aggregators, etc., with standardized resource set identifiers used to analyze other resource offer generation input datasets that contain data records extracted from or associated with third-party systems. Mapping datasets can be created manually and / or algorithmically to map third-party resource identifiers to standardized resource set identifiers for each region and / or third party. For example, third-party resource identifier information may be extracted in association with a specific third-party system for a particular region. Third-party resource identifier information may include one or more resource attribute values ​​(e.g., manufacturer identifier, model identifier, storage size identifier, etc.). The system may algorithmically provide mappings between third-party resource identifier information and standardized resource set identifiers and generate a mapping score indicating the likelihood of the generated mapping being correct. The mapping score is obtained based on matching known resource attribute values ​​associated with resource set identifiers with resource attribute values ​​parsed from third-party resource identifier information. The mapping score can then be compared to a mapping verification threshold, and a mapping score that satisfies the mapping verification threshold (e.g., by exceeding the threshold) is considered to be accurately mapped. If third-party resource identifier information is mapped and a mapping score is assigned that does not meet the mapping confirmation threshold, the third-party resource identifier information may be marked for manual mapping and / or reconsidered. The mapping dataset may include completed algorithmic and manual mappings.

[0179] The resource offer generation input dataset may include a market intelligence dataset. The market intelligence dataset may be collected, acquired, and / or retrieved from one or more third-party systems. In some embodiments, the market intelligence data system may include information and / or data stored by the resource offer generation system 1003, for example, in a corresponding database. The resource offer generation system 1003 may be configured to modify the market intelligence dataset using one or more processing algorithms to ensure the sufficiency and / or validity of various records within the market intelligence dataset. For example, one or more processing algorithms may be used to identify and delete data records that do not contain the information necessary to map the market intelligence data to resource set identifiers, or to flag them for manual adjustment. The market intelligence data may be mapped as being associated with a specific resource set identifier and / or a specific resource, based on the mapping dataset. For example, a particular subset of the market intelligence dataset may include, or otherwise associate with, the resource set identifier to which that subset of market intelligence data applies.

[0180] Additionally or alternatively, the resource offer generation input dataset may include one or more datasets derived and / or generated from a forecasting system such as those described herein. For example, the resource offer generation input dataset may include an assumed resource volume dataset and an average distribution request amount dataset. The resource offer generation input dataset may include an assumed resource volume set, an average distribution request amount, an average distribution request amount dataset, and / or an expected receipts dataset derived from other data objects or datasets derived or generated from a forecasting system. The expected receipts dataset may represent expected resource volumes for a given regional program identifier and / or include assumed or predicted price characteristics for each resource set identifier distributed in association with a particular channel profile.

[0181] If one or more resource offer generation input datasets are not validated in step 1018, an error message may be provided to the client device 1001. The error message may indicate that one or more of the resource offer generation input datasets do not exist in the associated database, such as the resource offer generation system database 802C. For example, if one or more of the required data record sets have not been generated in advance for the regional program identifier for which the resource offer generation process was initiated in step 1006, the resource offer generation input datasets may not be validated. In some embodiments, the resource offer generation system 1003 may query the database, for example, embodied by the resource offer generation system database 802C, using the regional program identifier selected by the offer control user, to determine whether all required resource offer generation input datasets exist and / or are updated as described above. If the resource offer generation input datasets are validated in step 1018, the flow may proceed to step 1020.

[0182] In step 1020, the resource offer generation system 1003 may provide data collection parameters to the client device 1001. The resource offer generation system 1003 may identify data collection parameters provided based on regional program data objects configured by the offer control user and stored in a previous step. For example, collection parameters may include specific financial analysis metrics, targets, costs, or other parameters associated with regional program data objects. Some, zero, or all of the collection parameters may be associated with default values ​​configured by the offer control user in a previous step. Examples of collection parameters include the channel mix of distribution channels, one or more activity costs, fees, minimum offer requirements, minimum offer profit requirements, minimum margin requirements, resource volume mix, and / or resource multipliers and / or adjustment indices based on one or more resource attributes and / or conditions (e.g., resource time multiplier, resource functionality multiplier, resource lock status multiplier, etc.).

[0183] The resource offer generation system 1003 is capable of generating and / or transmitting one or more control signals to the client device 1001, the control signal(s) which generate a renderable data object including an interface displayed on one or more client devices, including the client device 1001. The interface may include components for rendering data acquisition parameters for input by a user, such as an offer control user associated with the client device 1001, or may be configured in other ways for rendering. For example, the interface may include input components associated with each data acquisition parameter to receive data acquisition parameter values ​​for the corresponding data acquisition parameters.

[0184] In step 1022, the client device 1001 may render data acquisition parameters for input by the offer control user. In some embodiments, each of the data acquisition parameters provided in step 1020 is rendered to an interface provided via the client device 1001 in response to receiving the provided data acquisition parameters. For example, a renderable data object can be rendered by the client device 1001, where the renderable data object includes an interface component for each data acquisition parameter. Each data acquisition parameter may be rendered in association with an interface component for changing the value associated with the corresponding data acquisition parameter. If provided, each data acquisition parameter may be rendered in association with a corresponding default value configured by the offer control user based on the associated regional program data object. The user may interact with the interface component associated with the data acquisition parameter to input a new data acquisition parameter value associated with that data acquisition parameter.

[0185] In step 1024, the client device 1001 submits the values ​​of the data collection parameters. In some embodiments, the offer control user may activate an interface component, such as a submit button, rendered on the interface, to submit the currently entered values ​​of the data collection parameters. The submitted values ​​may include a variety of values ​​manually entered and / or loaded by the offer control user via the client device 1001. In some embodiments, the submitted values ​​may include one or more default values ​​that the offer control user has not changed. The client device 1001 can transmit an electronic data transmission containing the data collection parameter values ​​to the resource offer generation system 1003, which can receive the electronic data transmission, parse the electronic data transmission, and extract the data collection parameter values.

[0186] In step 1026, the resource offer generation system 1003 receives the submitted data collection parameter values, which in some embodiments may be validated. The data collection parameter values ​​may be validated using a set of validation rules stored by and / or retrieved by the resource offer generation system 1003. The set of validation rules may ensure that one or more of the data collection parameter values ​​satisfy a predetermined rule, either individually or in combination with other data collection parameter values. For example, in some embodiments, the set of validation rules may include business rules associated with the profitability and / or distribution allocation of resources.

[0187] If the data collection parameter value is not validated in the optional step 1028, an error message may be provided to the client device 1001. The error message may indicate that one or more validation rules of the validation rule set were not met. Additionally or alternatively, the error message may specifically indicate that a particular validation rule was not met and / or suggest that the collection parameter value be modified to satisfy the validation rule set. If the data collection parameter value is validated in the optional step 1028, the data collection parameter value may be stored in association with the regional program identifier and / or collection period data object submitted by the offer control user. In some embodiments, the data collection parameter value may be stored as a benchmark and portfolio target dataset associated with the regional program data object. In some embodiments, the data collection parameter value may be stored in a temporary or staging table in a database such as the resource offer generation system repository 802C. The flow then proceeds to step 1030.

[0188] In step 1030, the offer control user requests resource offer generation via the client device 1001. In some embodiments, the offer control user may automatically request resource offer generation in response to submitting collection parameter values. In other embodiments, upon submission and verification of data collection parameter values, the offer control user may be prompted via the client device 1001 to provide and submit additional datasets (e.g., values ​​for one or more additional data collection parameters based on the initially submitted collection parameter values).

[0189] To request the generation of a resource offer, the client device 1001 may transmit a resource offer generation request to the resource offer generation system 1003. The resource offer generation request may include, or may be otherwise associated with, a regional program identifier associated with a regional program data object initiated by the offer control user in an earlier step, and a collection period data object. Additionally, in some embodiments, the resource offer generation request may include data collection parameter values ​​for various data collection parameters.

[0190] In step 1032, the resource offer generation system 1003 may receive a resource offer generation request transmitted by, for example, a client device 1001. The resource offer generation system 1003 may receive a regional program data object and / or a corresponding regional program identifier, and a collection period data object. The resource offer generation request indicates that the offer control user has confirmed and submitted all parameter value inputs. In some embodiments, upon receiving a resource offer generation request from the client device 1001, the resource offer generation system 1003 may transfer the data collection parameter values ​​from a temporary or staging table to an implementation table accessible by one or more models for resource offer generation. For example, in some embodiments, the data collection parameter values ​​may be transferred to an attribute table accessible for application to the resource offer generation model and / or exception detection model.

[0191] In some embodiments, the resource offer generation system 1003 may maintain one or more repositories, databases, etc., to manage offer status records associated with resource offer sets generated for specific regional program identifiers and collection period data objects. For example, in some embodiments, the resource offer generation system may maintain an offer approval repository containing offer status records for each regional program identifier and collection parameter data object for which resource offer generation has been requested. Each offer status record may be retrievable in association with a regional program identifier and collection parameter data object.

[0192] An offer status record may be created when a resource offer generation request is received. Once generated, the offer status record may be associated with a request status indicator. At a given time, an offer status record for a particular regional program identifier and collection period data object may be associated with only a single resource offer set. An offer status record may first be associated with a resource offer set generated in a later step. It is then possible to update or otherwise adjust the resource offer set to create an adjusted resource offer set, which may then be stored in association with the offer status record. Furthermore, adjustments may be made to the stored resource offer set associated with the offer status record so that the adjusted resource offer set can be further updated.

[0193] In step 1034, the resource offer generation system 1003 generates a resource offer set using a resource offer generation model. In some embodiments, the resource offer generation model may be embodied by one or more algorithms for generating one or more resource offer data objects having a specific resource offer value. In other embodiments, the resource offer generation model may be an algorithmic model configured to generate a resource offer set based on one or more input parameter sets. For example, the resource offer generation model may be based on a resource offer generation input dataset. In other embodiments, the resource offer generation model may be a machine learning model configured to predict a resource offer set.

[0194] A resource offer generation model may be configured and / or trained to generate resource offer sets based on one or more of the resource offer generation input datasets. Additionally or alternatively, the resource offer generation input datasets may include one or more datasets received or output from a prediction system, or other datasets derived from datasets received or output from a prediction system. For example, a resource offer generation model may generate resource offer sets based at least in part on assumed resource volume datasets for various channel profiles allocated by a prediction system. In the specific example of acquiring and distributing used mobile devices, the assumed resource volume dataset may include a set of assumed or predicted resources that are distributed in association with an efficient channel allocation of resources (e.g., several resources associated with various resource set identifiers). Additionally or alternatively, a resource offer generation model may generate resource offer sets based at least in part on an average distribution request dataset. In the specific example of acquiring and distributing used mobile devices, the average distribution request dataset may include assumed selling prices at which resources are distributed through an efficient channel allocation. The average distribution request dataset may, for example, include price characteristics for various resource set identifiers and / or be based on, or include, a decay parameter data object associated with decay curves for estimating changes in assumed price characteristics for various resource set identifiers due to assumed time intervals for distribution. In some embodiments, the resource offer generation model may extract, receive, or otherwise obtain a decay parameter data object used to determine the assumed price characteristics of distributions of resources associated with one or more resource set identifiers, based on distribution time delay input parameters included in benchmark and portfolio target datasets. For example, the average distribution request dataset may be adjusted based on decay curves and distribution time delay input parameters.In some embodiments, a predicted revenue dataset for the distribution of a hypothetical resource, such as a used mobile device, can be derived using a hypothetical resource volume dataset and an average distribution request dataset, a combination of these sets, or parts or combinations thereof, and / or a market intelligence dataset and / or a portion of the market intelligence dataset, through an efficient channel allocation associated with conditions or characteristics such as price characteristics, as predicted by a forecasting system. In some embodiments, a resource offer generation model may be configured to generate resource offer sets based at least in part on a predicted revenue dataset applied to the resource offer generation model.

[0195] The resource offer generation system 1003 may be configured to access a database, for example, embodied by the resource offer generation system database 802C, to retrieve and / or utilize one or more resource offer generation input datasets. In some embodiments, the database may be updated at least partially by the prediction system. Alternatively, in some embodiments, the resource offer generation system 1003 may be configured to retrieve at least a portion of the resource offer input datasets from the prediction system and / or an associated database, such as the prediction system database 102C.

[0196] The resource offer generation model can be configured to generate resource offer sets, where the resource offer set contains resource offer data objects for various resource set identifiers that satisfy desired benchmark and portfolio target datasets. The benchmark and portfolio target datasets may contain some or all of the data collection parameters entered by the offer control user in earlier steps. For example, in some embodiments, a specific regional program data object having an input regional program identifier may be associated with one or more specific data collection parameters that define the benchmark and portfolio target datasets (e.g., financial target parameters that the resource offer set must satisfy). Additionally, in some embodiments, one or more of the data collection parameters may be associated with default parameter values ​​that can be modified via input by the offer control user, for example, provided in step 1024.

[0197] In some embodiments, a resource offer generation model may utilize or otherwise associate with one or more submodels for generating resource offer sets. For example, a resource offer generation model may include at least an offer optimization model configured to optimize resource offer sets or generate optimized resource offer sets based on one or more boundary conditions, such as benchmark and portfolio target datasets and / or other applicable datasets. Additionally or alternatively, for example, a resource offer generation model may be associated with or utilized with an exception detection model configured to generate good market offer sets for various resources, such as those obtained based on a resource list dataset and / or assumed resource volume dataset. In some embodiments, a market intelligence dataset, and / or one or more subsets thereof, may be utilized together with the good market offer sets generated by the exception detection model to generate resource offer sets. For example, a market intelligence dataset may include a set of average third-party offer data objects, which includes a maximum third-party offer data object associated with each resource set identifier for one or more third-party entities, and / or an average third-party offer data object associated with each resource set identifier for one or more third-party entities. Each average third-party offer data object contains and / or may otherwise represent the average price characteristics associated with a specific third-party entity for a resource set identifier.

[0198] In some embodiments, one or more datasets are applied to a resource offer generation model to generate a resource offer set. For example, in some embodiments, these might include a maximum third-party offer data object set, an average third-party offer data object set, a fair market offer set, benchmark and portfolio target datasets, and / or one or more resource offer generation input datasets. Various applicable datasets may be applied so that the resource offer generation model generates a resource offer set containing one or more resource offer data objects associated with price characteristics such as resource offer values, such that the resource offer set satisfies the benchmark and portfolio target datasets.

[0199] A resource offer generation model can generate an optimal resource offer set based on various applicable datasets. For example, a resource offer set may be generated to best satisfy benchmark and portfolio target datasets. In this regard, a resource offer generation model may be configured to utilize one or more algorithms, statistical models, and / or machine learning models to generate resource offer sets. In some embodiments, a resource offer generation model may utilize assumed resource volume datasets and / or average distribution request datasets to generate resource offer sets. For example, in some embodiments, a resource offer generation model includes at least a linear optimization model configured to generate resource offer sets to best satisfy benchmark and portfolio target datasets based on various input datasets. For example, based on assumed channel profile allocation and pricing characteristics for distributed resource set identifiers (e.g., as identified in the input assumed resource volume datasets and average distribution request datasets), a resource offer generation model may generate resource offer sets to maximize satisfaction with benchmark and portfolio target datasets. For example, in some embodiments, the benchmark and portfolio target datasets may include only the minimum resource margin for resource offer data objects in the generated resource offer set. In other embodiments, benchmark and portfolio target datasets may include boundary conditions for the acquisition and distribution of specific resources, for example, by maximizing the pricing characteristics of resource offer data objects associated with a subset of resources (e.g., resources associated with a specific resource set identifier).It should be understood that benchmark and portfolio target datasets can act as boundary conditions of any number and any type for optimizing resource offer sets, such as minimum profit for the resource offer dataset, desired margin per resource, resource offer data objects associated with a specific subset of resources (e.g., resources associated with sales promotions), combinations of distribution channel profiles, and / or minimum profit based on maximizing other financial analysis targets.

[0200] In some embodiments, some or all of the resource offer generation model is managed by the resource offer generation system 1003 and maintained and executed via subservers and / or second servers otherwise associated therewith. For example, a second server that is communicable and / or controlled by the resource offer generation system 1003 may be maintained to generate resource offer sets and / or optimize resource offer sets. The server managing the resource offer generation model may be configured to use any number of programming implementation forms to implement the model. For example, in some embodiments, the resource offer generation model may be configured using the R programming language, where the second server or subserver is configured with an environment for interface-connecting to the model.

[0201] The resource offer generation system 1003 may initiate a resource offer generation model, or one or more operations performed by the resource offer generation model, on the second server or subserver via one or more APIs and / or services for communicating with the second server or subserver. In some embodiments, the resource offer generation system 1003 may transmit one or more requests to the resource offer generation model on the second server or subserver to initiate and / or apply one or more of the input datasets. For example, in some embodiments, the resource offer generation system 1003 manages a database environment, such as a SQL environment, for managing various data warehouse modules containing input datasets, and uses one or more SQL Server Integration Services (SSIS) to push resource offer generation input datasets and / or generated datasets to the second server or subserver for application to the resource offer generation model. When a resource offer is output by the resource offer generation model, the generated resource offer set (or corresponding data) may be pushed back from a second server or subserver to, for example, the resource offer generation system 1003, for storage in a database environment (e.g., the SQL environment) that uses one or more APIs and / or services such as SSIS associated with the SQL environment.

[0202] In some embodiments, the resource offer generation system 1003 directly controls and / or accesses the resource offer generation model to generate resource offer sets. For example, the resource offer generation system 1003 may perform all the operations described above on the same system (e.g., a server or a group of servers) as separate systems.

[0203] In some embodiments, the generated resource offer set is stored associated with an offer status record for the regional program identifier and collection period data object. Additionally or alternatively, offer status indicators included in or associated with the offer status record may be updated to embody or represent pending adjustment status indicators. For example, the offer status record may be maintained in the resource offer generation system 1003 by querying the offer approval repository based on the regional program identifier and collection period data object and receiving the offer status record as result data, or it may be retrieved from an offer approval repository that it can access.

[0204] In step 1036, the resource offer generation system 1003 notifies the offer control user that the resource offer generation model has completed generating and / or optimizing the resource offer set and has pushed the generated resource offer set to the database for retrieval. In some embodiments, the notification may be transmitted in association with the offer control user's user account, which is used to access the resource offer generation system 1003 and to perform the resource offer generation process. In some embodiments, the offer control user may be notified via an application, interface, or other service associated with the resource offer generation system 1003. In other embodiments, the offer control user may be notified via a third-party application, interface, or other service such as email transmitted to an email account associated with the offer control user (e.g., email associated with the user account associated with the offer control user).

[0205] Figure 11 illustrates an exemplary data flow diagram 1100 for rendering a resource offer set, adjusting a resource offer set, submitting an adjusted resource offer set for approval, and approving or rejecting an adjusted resource offer set. These operations are performed through a number of specific interfaces that correspond to and are configured to enable such operations. The data flow diagram 1100 includes data flow steps between components such as subsystems of system 800, including a client device 1001, a resource offer generation system 1003, and an approval device 1005. The data flow diagram 1100 may be performed after some or all of the steps described above with respect to the data flow diagram 1000.

[0206] In data flow 1100, some of the illustrated steps may be optional. Optional steps are illustrated with dashed lines in Figures 10 and 11. In some embodiments, one or more of the optional steps may be performed. In some embodiments, all of the optional steps may be performed.

[0207] In step 1102, the offer control user may access a resource offer generation system, such as the resource offer generation system 1003. The offer control user may access the resource offer generation system 1003, client device 1001, or another of several client devices. Upon re-accessing the resource offer generation system 1003, the offer control user may re-authenticate and / or otherwise start a new authenticated session, or continue an existing authenticated session.

[0208] In step 1104, the resource offer generation system 1103 generates and / or transmits control signals that produce a renderable object including an offer adjustment interface displayed on one or more client devices, such as client device 1001. In some embodiments, the control signals may be transmitted to a second client device accessed by an offer control user associated with client device 1001 (e.g., a second computer or mobile device on which the offer control user accesses the resource offer generation system 1003 and initiates an authenticated session). The offer adjustment interface includes indicators of the resource offer set. For example, the offer adjustment interface may include resource offer values ​​for one or more resource offer data objects within the resource offer set (e.g., a portion of the resource offer set may be visible). In some embodiments, the resource offer set is retrieved from storage or a database. For example, the resource offer set may be a resource offer set generated and / or optimized from an earlier step, stored in association with a regional program identifier.

[0209] The offer adjustment interface may be configured to allow adjustment of a resource offer set. For example, the offer adjustment interface may be configured to allow an offer control user to adjust the resource offer value associated with each resource offer data object in the resource offer set. In some embodiments, the offer control user may select a resource offer data object to adjust and enter the adjusted resource offer value for the selected resource offer data object, for example, through user engagement. After adjusting a resource offer data object, the offer control user may continue to adjust other resource offer data objects or adjust the same resource offer data object again. The offer adjustment interface may be dynamically rendered to reflect updates based on adjustments made by the offer control user.

[0210] The control signal causes at least the client device 1001 to render an offer adjustment interface which includes at least metrics of the resource offer set. In some embodiments, the offer adjustment interface further includes metrics of data from or derived from the resource offer generation input dataset. For example, in some embodiments, the offer adjustment interface includes market intelligence data or a representation of market intelligence data for each resource offer data object in the resource offer set. For example, the market intelligence data rendered to the offer adjustment interface may include one or more third-party offers, such as competitor offers. The offer adjustment interface may further include metrics of an offer analysis dataset associated with the resource offer set. For example, the offer analysis dataset may include expected profit per resource, resource margin information, and / or summary information about the resource offer set (e.g., the number of resources associated with the resource offer data object currently associated with a resource offer value). In some embodiments, the resource offer generation system 1103 may calculate or otherwise determine the offer analysis dataset based on the resource offer set and one or more resource offer generation input datasets, such as the market intelligence dataset. Alternatively, the resource offer generation model and / or exception detection model may be configured to generate an offer analysis dataset associated with the resource offer set.

[0211] In some embodiments, the offer adjustment interface additionally includes a dashboard for accessing and / or rendering various separate analysis interfaces for analyzing resource offer sets, and any adjustments. One or more of the analysis interfaces may provide metrics for data to analyze the adjusted resource offer set with respect to one or more third-party offers. For example, an analysis interface may provide data derived based on the currently adjusted resource offer dataset and one or more portions of the resource offer generation input dataset.

[0212] In step 1106, the client device 1001 renders an offer adjustment interface. The offer adjustment interface may be rendered so that the offer control user can view offer data objects associated with various resources. The offer adjustment interface may be configured to allow adjustment of each resource offer data object in a resource offer set in response to user engagement with the offer adjustment interface to change the offer value, for example.

[0213] In step 1108, the client device 1001, and / or an offer control user via the client device 1001, may analyze the rendered resource offer set. In some embodiments, the offer control user may view the resource offer value associated with each offer data object in the resource offer set. The offer control user may additionally or alternatively analyze one or more metrics of the offer analysis dataset rendered via the offer adjustment interface. For example, the price adjustment interface may include a dashboard for accessing various analysis interfaces, such as those illustrated by Figures 14 and 15, and metrics of the offer analysis dataset that can be analyzed to determine whether the resource offer value of one or more resource offer data objects in the resource offer set should be adjusted. In some embodiments, the client device 1001 may be configured to automatically analyze the resource offer set. For example, the client device 1001 may be configured to run one or more analysis algorithms based on the resource offer set and / or the offer analysis dataset to determine whether one or more resource offer data objects should be adjusted.

[0214] In step 1110, the client device 1001, and / or an offer control user via the client device 1001, can adjust the resource offer set. In some embodiments, the offer control user can adjust the resource offer values ​​of one or more resource offer data objects. For example, the offer control user can input adjusted resource offer values ​​of one or more resource offer data objects through user engagement with the price adjustment interface. Adjustments to the resource offer set can be performed based on an analysis of the information rendered to the offer adjustment interface.

[0215] In some embodiments, an offer control user may, after adjusting at least one resource offer data object via a client device 1001, save the adjustment to the resource offer generation system 1003. For example, the offer adjustment interface may include an offer storage component configured to generate and / or transmit one or more control signals to the resource offer generation system 1003 in response to user engagement, the control signal(s) containing at least one adjustment data object for each adjusted resource offer data object. The resource offer generation system 1003 may then update the stored resource offer set based on the received adjustment data object to create a new adjusted offer set. In other embodiments, one or more control signals may be automatically generated and / or transmitted in response to input by an offer control user to adjust a resource offer data object, for example, in response to input of an adjusted resource offer value for a particular resource offer data object.

[0216] In some embodiments, the updated stored resource offer set is retrieved in association with a regional program identifier and collection period data object. For example, the stored resource offer set may be retrieved from an offer approval repository and associated with a corresponding offer status record from another repository or sub-repository based on the regional program identifier and collection period data object. If no adjustments have been previously stored, the stored resource offer set may be a resource offer set generated by the resource offer generation model. Alternatively, if one or more adjustments have been stored, the stored resource offer set may be an adjusted resource offer set created based on one or more previously stored adjusted data objects.

[0217] The newly created, adjusted resource offer set may then be stored, for example, associated with regional program identifiers and collection period data objects, to replace previously stored resource offer sets. The new adjusted resource offer set may be retrieved and updated when subsequent updates are performed by the offer control user.

[0218] In some embodiments, components of the offer adjustment interface may be dynamically updated in response to adjustments. For example, an adjusted resource offer set may include one or more offer resource data objects associated with adjusted offer values ​​that can be dynamically updated via the offer adjustment interface. Additionally, it is possible to recalculate or determine the offer analysis dataset and update the metrics of the offer analysis dataset to render the updated offer analysis dataset to the interface. For example, one or more offer analysis algorithms for determining, identifying, or otherwise calculating the offer analysis dataset may be executed based on adjustments to one or more of the resource offer data objects, and the metrics of the offer analysis dataset rendered to the offer adjustment interface may be dynamically updated in real time to reflect the output from the algorithm(s) described above. In some embodiments, one or more analysis interfaces accessible via the rendered dashboard may be dynamically updated when one or more of the resource offer data objects are adjusted. By dynamically updating the rendering of the offer adjustment interface, offer control users can instantly visualize the effect of adjusting one or more offer data objects and continue to adjust resource offer sets in real time.

[0219] In step 1112, the client device 1001 submits the completion of the adjusted resource offer set. In some embodiments, the client device 1001 generates and / or transmits a completion control signal to the resource offer generation system 1003 indicating that the adjusted resource offer set has been confirmed for submission for approval from the offer approval user. In other embodiments, the completion control signal includes one or more adjustment data objects for updating the resource offer dataset to create the adjusted resource offer set. In other embodiments, the completion control signal includes, for example, the adjusted resource offer set itself, created by the user device 1001. The adjusted resource offer set may reflect all adjustments made to the resource offer data objects within the resource offer set. In some embodiments, the offer adjustment interface additionally includes interface components, such as an offer submission component, which the offer control user may be authorized to generate and / or transmit the completion control signal.

[0220] In step 1114, the resource offer generation system 1003 may receive a completion control signal from the user device 1001. In some embodiments, in response to the completion control signal, the resource offer generation system 1003 may update and / or store a coordinated resource offer set. In some embodiments, the resource offer generation system 1003 retrieves, for example, an offer status record associated with a regional program identifier and a collection period data object from the offer approval repository and updates the associated offer status indicator to represent a pending approval status indicator. In some embodiments, the resource offer generation system 1003 creates a coordinated resource offer by, for example, updating a previously stored resource offer set based on one or more coordinated data objects. Alternatively, in some embodiments, for example, a resource offer set stored in the offer approval repository or another repository, associated with a regional program identifier and a collection period data object, may be updated based on a coordinated resource offer set parsed and / or extracted from the completion control signal.

[0221] In an optional step 1116, the resource offer generation module 1003 notifies the offer approver user that the coordinated resource offer set has been submitted and stored. In some embodiments, the notification may be transmitted to the offer approver user's user account so that the offer approver user can access it to retrieve the notification by accessing the resource offer generation system 1003. In some embodiments, the offer approver user may be notified via an application, interface, or other service associated with the resource offer generation system 1003. In other embodiments, the offer approver user may be notified via a third-party application, interface, or other service, such as via email transmitted to an email account associated with the offer approver user (e.g., email associated with the user account).

[0222] In step 1118, the offer approval user accesses a resource offer generation system, such as the resource offer generation system 1003. The offer approval user may access the resource generation system 1003 via an approval device 1005. The approval device may be a second client device that communicates with the resource offer generation system 1003. For example, the second client device may be embodied by a second request source system 104. The approval device 1005 may be configured to run an application, interface, web / browser application, etc., for accessing the resource offer generation system 1003. The application, interface, web / browser application, etc., for accessing the resource offer generation system 1003 as an offer approval user may differ from the application, interface, web / browser application, etc., for accessing the resource offer generation system 1003 as an offer control user. Alternatively, the application, interface, web / browser application, etc., for accessing the resource offer generation system 1003 may be the same for both the offer approval user and the offer control user. An offer control user may be associated with a user account that has permissions to create and / or edit regional program data objects, request resource offer generation, access the offer adjustment interface, and submit adjusted offer sets.

[0223] An offer approval user may be associated with a user account that has permission to access a submitted adjusted resource offer set, access the corresponding offer adjustment interface, and respond to the submitted adjusted resource offer set (e.g., approving or rejecting the submitted adjusted resource offer set). For example, the resource offer generation system 1003 may provide the management device 1005 with one or more adjusted resource offer sets stored in association with one or more offer status records that include or are associated with a pending approval status indicator, where each adjusted offer set and offer status record is associated with a specific regional program identifier and collection period data object. The offer approval user may then select an adjusted resource offer set for a specific regional program identifier and collection period data object that the offer approval user wishes to view, analyze, and / or approve or reject.

[0224] In step 1120, the resource offer generation system 1003 may generate and / or transmit an approval request control signal to produce a second renderable object which includes an approval interface that is displayed on another of one or more client devices, such as the approval device 1003. The approval request control signal may be generated and / or transmitted in response to the selection of a tailored resource offer set for a specific regional program identifier and collection period data object. The approval interface includes an index of the tailored resource offer set. The tailored resource offer set may be retrieved from storage upon access by an offer approval user, for example, via the management device 1003. For example, an offer approval user may choose to view a tailored resource offer set submitted in association with a specific regional program data object having a specific regional program identifier.

[0225] In some embodiments, the approval interface includes additional metrics for the data. The approval interface may include the same metrics for the data rendered to the offer adjustment interface provided to the offer control user via the client device 1001. For example, additionally or alternatively, the approval interface may further include metrics for data from, or data derived therefrom, the resource offer generation input dataset. In some embodiments, the approval interface may further include market intelligence data, or a representation of market intelligence data, for each resource data object in the resource offer set. For example, the market intelligence data rendered to the approval interface may include one or more third-party offers, such as competitor offers. The approval interface may further include metrics for an offer analysis dataset associated with the adjusted resource offer set. For example, the offer analysis dataset may include expected profit per resource, resource margin information, summary information about the resource offer set, etc. The offer analysis dataset may be calculated based on the submitted adjusted resource offer set and one or more resource offer generation input datasets, or may be determined in other ways. It is therefore not modifiable by the offer approval user.

[0226] Additionally, the approval interface may include the same dashboard rendered in the offer adjustment interface. Thus, in such embodiments, the approval interface allows the offer approval user to analyze the submitted adjusted resource offer set based on the same data metrics and visualizations of the data used by the offer control user to perform adjustments on the adjusted resource offer set.

[0227] In step 1122, the management device 1005, and / or the offer approval user via the management device 1005, may analyze the adjusted resource offer set. In some embodiments, the offer approval user may view the resource offer value associated with each resource offer data object in the adjusted resource offer set. The offer approval user may, additionally or alternatively, analyze metrics of the offer analysis dataset rendered via the approval interface. For example, the approval interface may include metrics of the offer analysis dataset (e.g., margin, resource profit, offer summary data, or other financial target information) that can be analyzed to decide whether to accept or reject the adjusted resource offer set. Additionally or alternatively, the approval interface may include a dashboard for accessing various analysis interfaces for analyzing the adjusted resource offer set, for example, taking into account benchmark and portfolio target datasets. For example, the analysis interface may include one or more interfaces for visualizing the offer strength of the adjusted resource offer set, the price trends associated with the adjusted resource offer set, market comparisons associated with the adjusted resource offer set, etc.

[0228] Offer approval users can analyze a tailored resource offer set based on identified, received, or offline benchmark and portfolio target datasets through various interfaces and metrics. The benchmark and portfolio target datasets may include one or more profitability, margin, or other financial targets for regional program identifiers associated with the tailored resource offer set. In some embodiments, the approval device 1005 may be configured to automatically analyze the tailored resource offer set. For example, the approval device 1005 may be configured to run one or more offer approval algorithms based on the tailored resource offer set and / or offer analysis dataset to determine whether the tailored resource offer set should be approved or rejected.

[0229] In step 1124, the offer approval user may activate the approval interface via the management device 1005 to approve or reject the adjusted resource offer set. For example, in some embodiments, the offer approval user may activate a first interface component for approving the resource offer set, or a second interface component for rejecting the resource offer set. The resource offer set may be approved or rejected based on the analysis performed in step 1122.

[0230] In step 1126, the management device 1005 may determine whether the offer approval user has approved or rejected the adjusted resource offer set. In some embodiments, the determination depends on the user interface component engaged by the offer approval user in step 1124. In other embodiments, an offer approval control signal is transmitted to the resource offer generation system 1003 after step 1124, and the determination is based on a control signal received from the resource offer generation system 1003 in response to the offer approval control signal.

[0231] In situations where an offer approver user rejects a tailored resource offer set, the flow may proceed to step 1128 at the discretion of the offer approver user. At step 1128 at the discretion of the offer approver user, the management device 1005, and / or the offer approver user via the management device 1005, may create an offer rejection message associated with the tailored resource offer set. In some embodiments, a user interface, or user interface component, is rendered so that the offer approver user can input and submit an offer message to create it. In some embodiments, the interface may provide a free-text input to allow input of one or more predetermined offer rejection messages and / or a custom offer rejection message. The offer rejection message may be created after the offer approver user has rejected or indicated a desire to reject a resource offer set, for example, by engaging a user interface component for rejecting the resource offer set. The offer rejection message may reflect an analysis of the tailored resource offer set, and / or a decision on the tailored resource offer set, an explanation defining why the tailored resource offer set is rejected, and / or adjustment steps taken to improve the tailored resource offer set for approval. Alternatively, in some embodiments, an offer rejection message may be created and / or submitted by the offer-approving user before rejecting the coordinated resource offer set. In some embodiments, a user interface component is provided for rejecting the coordinated resource offer set and submitting the offer rejection message.

[0232] The management device 1005 may transmit an offer approval response to the resource offer generation system 1003 in response to the submission of an approval or rejection. For example, an offer approval response may be generated and / or transmitted in response to an engagement with an approval interface for approving or rejecting a coordinated resource offer set, or, in some embodiments, in response to an engagement with a user interface component for submitting an offer rejection message. The offer approval response may include at least an offer approval status indicating approval or rejection of the coordinated resource offer set. In some embodiments, if the offer approval status is a rejection status (for example, if an offer approval user rejects a coordinated resource offer set), the offer approval response may additionally include an offer rejection message created by the offer approval user.

[0233] In step 1130, the resource offer generation system 1003 may receive an offer approval control signal that includes at least an offer status indicator, where the offer status indicator is represented by a rejection status indicator or otherwise embodied. Additionally or alternatively, in some embodiments, the offer approval control signal may include an offer rejection message created by the offer approval user. Upon receiving the offer approval control signal, the resource offer generation system 1003 may parse the control signal to identify the offer status indicator.

[0234] The resource offer generation system 1003 may additionally store a coordinated set of resource offers associated with a regional program identifier, a collection period data object, and an offer status indicator (e.g., a rejection status indicator). In some embodiments, the resource offer generation system 1003 may update the corresponding offer status record in an offer approval repository, a subrepository, or a table. For example, the resource offer generation system 1003 may update the offer status record associated with the coordinated set of resource offers to include a rejection status indicator. For example, the resource offer generation system 1003 may retrieve an offer status record from a repository, such as an offer approval repository, based on the regional program identifier and the collection period data object. An offer status indicator associated with or contained within an offer status record may be updated to represent, for example, a rejection status indicator, based on the received and / or identified offer status indicator.

[0235] In step 1132, the resource offer generation system 1003 may provide a rejection notice to the offer control user. The resource offer generation system 1003 may generate, retrieve, and / or otherwise configure the rejection notice. The rejection notice may include an offer rejection message received from the offer approval user via the approval device 1005. The rejection notice may be stored in association with the offer control user's user account so that the offer control user can access the rejection notice when accessing the resource generation system later via their user account.

[0236] The resource offer generation system 1103 may generate and / or configure one or more control signals to cause the rendering of a rejection notice to the client device 1001. The control signals may be generated or configured to include a renderable data object associated with, or containing, the rejection notice. The control signals may be transmitted to the client device 1001 to cause the rendering of an interface or interface component, including the rejection notice. In some embodiments, the control signals may be transmitted after subsequent access to the resource offer generation system 1003 by the offer control user, such as via the client device 1001 or another client device.

[0237] In step 1134, the offer control user may access a resource offer generation system, such as the resource offer generation system 1003. The offer control user may access the resource offer generation system 1003 via a client device, such as the client device 1001. The offer control user may access the resource offer generation system 1003 again via the client device 1001 after a certain period of time has passed since submitting the adjusted resource offer set for approval. In some embodiments, the offer control user may not have terminated the authenticated session associated with accessing the resource offer generation system after initiating the resource offer generation process or submitting the adjusted resource offer set for approval, and therefore may re-access the resource offer generation system 1003 without further authentication. In other embodiments, the offer control user may re-authenticate themselves via the client device 1001 to start another authenticated session to access the resource offer generation system 1003.

[0238] In step 1136, the client device 1001 may render a rejection notice. In some embodiments, the rejection notice may be rendered to an interface associated with a regional program data identifier and collection period data object, for example, an interface in which an offer control user can view rejection notices for one or more rejected adjusted resource offer sets for each regional program data object and / or associated information, each collection period data object in which resource offer generation is simulated, associated offer status indicators, and / or, if available, for a specific regional program identifier and collection period data object (e.g., based on an offer status record associated with it, including a rejection status indicator).

[0239] The offer control user can then access the rejected adjusted resource offer set and make further adjustments to resubmit the newly adjusted resource offer set for approval. The flow can then return to step 1106, where an offer adjustment interface is rendered on client device 1001 for access by the offer control user via the client device. The offer control user can activate the offer adjustment interface to adjust the adjusted resource offer set and resubmit it for approval. In some embodiments, the cycle defined by steps 1106-1136 may be repeated once, twice, or more times until the adjusted resource offer is approved by the offer approval user.

[0240] Returning to step 1126, in a situation where the offer-approving user has rejected the adjusted resource offer set, the flow may proceed to step 1138. In step 1138, the resource offer generation system 1003 may receive an offer approval control signal that includes at least an offer status indicator, where the offer status indicator is represented by an approval status indicator or otherwise embodied. Upon receiving the offer approval control signal, the resource offer generation system 1003 may parse the control signal to identify the offer status indicator.

[0241] The resource offer generation system 1003 may additionally store a coordinated set of resource offers associated with a regional program identifier, a collection period data object, and an offer status indicator (e.g., an approval status indicator). In some embodiments, the resource offer generation system 1003 may update the corresponding offer status record in an offer approval repository, subrepository, or table. For example, the resource offer generation system 1003 may update the offer status record associated with the coordinated set of resource offers to include an approval status indicator. For example, the resource offer generation system 1003 may retrieve an offer status record from a repository, such as an offer approval repository, based on the regional program identifier and the collection period data object. The offer status indicator associated with or contained within the offer status record may be updated to represent, for example, an approval status indicator, based on the received and / or identified offer status indicator.

[0242] In step 1140, when the offer status record is updated based on the approval status indicator, the resource offer generation system 1003 may generate and provide an approval notification to one or more users of the resource offer generation system 1003. In some embodiments, for example, the regional program identifier associated with the approved adjusted resource offer set may also be associated with one or more user accounts, such as the user account of the offer control user who submitted the adjusted resource offer set, the user account associated with the executive leader for the regional program data object, and / or one or more user accounts associated with the selling or distributing user for the regional program data object. In some embodiments, the approval notification includes the approval status indicator and / or an indicator of the adjusted resource offer set as approved.

[0243] Approval notifications can be generated and / or transmitted in countless ways. In some embodiments, an approval notification may be embodied by a message stored by the resource offer generation system 1003 and accessible via a client device during an authenticated session (e.g., via a messenger or notification system accessible via the resource offer generation system 1003). In other embodiments, an approval notification may be an email data object generated by the resource offer generation system 1003 and / or transmitted to one or more associated email services associated with one or more email recipients of the approval notification.

[0244] After step 1140 is completed, the adjusted resource offer set may be distributed to one or more entities, such as one or more third-party entities associated with various resource acquisition and / or distribution channels within a region associated with the regional component of a regional program identifier, by one or more of the resource offer generation system 1003 and / or notified users. The adjusted resource offer set may then be used for resource acquisition within that region, for example, by offering to acquire resources associated with a particular resource set identifier at predefined pricing characteristics defined by the resource offer value of the resource offer data object in the adjusted resource offer dataset associated with a particular resource set identifier.

[0245] Figure 12A is a flowchart of an exemplary process 1200, according to some embodiments of the present disclosure, for generating a resource offer set, adjusting the resource offer set, and receiving an offer approval status for the adjusted resource offer set. The operations exemplified with respect to exemplary process 1200 may be performed by a resource offer generation system, embodied, for example, by apparatus 900.

[0246] In an optional block 1202, the device 900 includes means such as a model performance circuit 912, an input / output circuit 906, a communication circuit 908, a processor 902, or a combination thereof, for receiving a regional program identifier and a collection period data object. The regional program identifier is received from a client device and may initiate the generation of a resource offer associated with a regional program data object having the regional program identifier. The collection period data object is received from a client device and may include a timestamp for the start date of the collection period and a timestamp for the end date of the collection period.

[0247] In an optional block 1204, the device 900 includes means such as a data management circuit 910, a model performance circuit 912, a processor 902, or a combination thereof, for determining that a regional program identifier and a collection period data object are not associated with a pending resource offer generation process. In some embodiments, the device may query a repository, such as an offer approval repository embodied by the resource offer generation system database 802C, based on the regional program identifier and the collection period data object. If an offer status record is retrieved, for example, as response data to the query, then a resource offer generation process has been started and / or completed for the regional program identifier and the corresponding collection period. If a record is retrieved, a second resource offer generation process should not be started and the flow may terminate.

[0248] In block 1206, the apparatus 900 includes means such as a data management circuit mechanism 910, a communication circuit mechanism 908, a processor 902, or a combination thereof, for retrieving at least one resource offer generation input dataset. In some embodiments, the resource offer generation input dataset may be retrieved from a repository, for example, by retrieving a base table linked to a plurality of data tables representing each resource offer generation input dataset in a particular database. In some embodiments, the resource offer generation input dataset includes a historical offer dataset, a resource list dataset, a market intelligence dataset, a resource mapping dataset, an assumed resource volume dataset, an average distribution request dataset, and / or an expected receipt dataset. The assumed resource volume dataset may include a subset of the predicted channel and condition datasets output by the forecasting system, or may be derived therefrom in other ways. For example, the assumed resource volume dataset may include predicted volume condition data from the predicted channel and condition datasets output by the forecasting system for various channel profiles. The average distribution request dataset may include a subset of the predicted channel and condition datasets output by the forecasting system, or may be derived therefrom in other ways. For example, the average distribution request dataset may include predicted pricing characteristic condition data from predicted channel and condition datasets output by the prediction system. In some embodiments, combinations of these various datasets are retrieved from one or more repositories and / or databases that are directly accessible by the device 900 or accessible via communication with one or more other systems (e.g., via communication with the prediction system).

[0249] In some embodiments, when generating resource offer sets, the resource offer generation model may utilize a reliable resource characteristics dataset generated by an exception detection model. In one such example, the reliable resource characteristics dataset may include characteristics associated with the acquisition and / or distribution of resources, e.g., the acquisition and distribution of used mobile phones. A non-limiting example may include generating reliable pricing characteristics for resource set identifiers in a fair market offer set based on one or more unreliable third-party resource pricing datasets and one or more distributed resource pricing datasets. In this regard, in block 1212, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, etc., or a combination thereof, for generating a fair market offer set using an exception detection model. It should be understood that in some embodiments, a fair market offer set may not be generated.

[0250] Using the example of acquiring used mobile devices, one or more unreliable third-party resource pricing datasets and a distributed resource pricing dataset can be applied to an exception detection model to generate a reliable resource characteristics dataset, e.g., a fair market offer set. A fair market offer set can contain fair market offer data objects for various resource set identifiers, each fair market offer data object having a pricing characteristic (e.g., a fair market offer value) for each of the resource set identifiers. For example, each third-party resource pricing dataset may contain records for the average pricing characteristic (e.g., the weekly pricing value at which third-party entities purchase and / or distribute resource set identifiers) for each resource set identifier offered by a set of third-party entities over a specific time interval, associated with a particular third-party entity, e.g., a competing entity. A distributed resource pricing dataset may contain the average offer value (e.g., the weekly value at which a resource associated with a resource set identifier can be purchased from individual users via a distributed user platform) for each resource set identifier offered by users via a distributed user platform. The exception detection model can generate a reliable resource characteristics dataset embodied by the appropriate market offer set through the process described below with respect to Figure 12B.

[0251] In block 1214, the device 900 includes means for receiving benchmark and portfolio target datasets, such as a data management circuit 910, a model performance circuit 912, a communication circuit 908, a processor 902, or a combination thereof. The benchmark and portfolio target datasets may be received from a client device, for example, in response to user input and submission by an offer control user, or from an approval device, for example, in response to input submission by an offer approval user. Alternatively, in some embodiments, the benchmark and portfolio target datasets may be retrieved from a database, such as a resource offer generation system database 802C.

[0252] In some embodiments, the benchmark and portfolio target datasets may include one or more data collection parameter values ​​for various data collection parameters. In some embodiments, additionally or alternatively, the benchmark and portfolio target datasets may include default values ​​associated with regional program data objects having regional program identifiers entered in earlier blocks. The benchmark and portfolio target datasets may include various data objects representing boundary conditions used to generate resource offer sets, for example. For example, in one exemplary context of acquiring and distributing used mobile devices, the benchmark and portfolio target datasets may include portfolio-level financial targets such that resource offer sets are generated such that resource offer values ​​for various resource offer data objects satisfy the boundary conditions represented by the benchmark and portfolio target datasets.

[0253] In block 1216, the apparatus 900 includes means such as a data management circuitry 910, a model performance circuitry 912, a processor 902, or a combination thereof, for generating resource offer sets using a resource offer generation model. In some embodiments, a resource offer set is generated by applying at least one of the resource offer generation input datasets to the resource offer generation model. Additionally or alternatively, benchmark and portfolio target datasets may be applied to the resource offer generation model, for example, so that the generated resource offer set must satisfy the applied benchmark and portfolio target datasets. A resource offer set may include resource offer data objects associated with one or more resources obtained in association with regional program data objects. The resource offer value for the above resource offer data object may represent the price at which a particular resource is offered for acquisition from a resource owner through one or more device acquisition channel profiles. In some embodiments, the resource offer generation model includes an algorithmic model configured to generate an output using the applied datasets. In other embodiments, the resource offer generation model includes one or more configured and trained machine learning models for generating an output using the applied datasets.

[0254] In some embodiments, the resource offer generation model may include one or more algorithms and / or machine learning models for optimizing resource offer data objects for various resource set identifiers to generate an optimal resource offer set to satisfy benchmark and portfolio target datasets. The benchmark and portfolio target datasets may act as boundary conditions for optimizing the generated resource offer set. For example, in some embodiments, the benchmark and portfolio target datasets may include minimum profit, margin or profit per resource, and / or other financial analysis targets. The resource offer generation model may include a linear optimization model configured to maximize the resource offer set according to the benchmark and portfolio target datasets. In some embodiments, the linear optimization model may be embodied by or configured to run on a second device, system, or server. Thus, the device 900 may include means for transmitting optimization requests to a server, for example, via one or more APIs, and receiving the optimized resource offer set in response.

[0255] As another example, using the acquisition of used mobile devices, the resource offer set may contain resource data objects with price characteristics for various resource set identifiers generated to optimally satisfy the applied benchmark and portfolio target datasets. The resource offer generation model may generate device offer values ​​for various user mobile devices associated with various resource set identifiers, e.g., CNNs, so that the entire device offer set for all devices satisfies user input values ​​and / or default values ​​for parameters associated with the benchmark and portfolio target datasets (e.g., desired profit margin, channel profile combination, device resource set identifier, or CNN offered as a promotion). To generate optimal resource offer data objects for various resource set identifiers, the resource offer generation model may consider efficient resource allocation for a particular resource set identifier, for example, generated by a prediction system, for one or more channel profiles and / or corresponding predicted price characteristics associated with distribution.

[0256] The resource offer generation model may use one or more other applicable datasets, such as one or more other resource offer generation input datasets (e.g., an offer history dataset and / or a market intelligence dataset) and / or one or more datasets derived by an exception detection model, to identify price characteristic targets to be exceeded when generating resource offer data objects to be included in a resource offer set, while satisfying boundary conditions represented by benchmark and portfolio target datasets. For example, in some embodiments, the resource offer generation model may, firstly, attempt to generate a resource offer set to include resource offer data objects associated with price characteristics (e.g., resource offer values) that are satisfied by exceeding the maximum price characteristic for each resource set identifier or one or more promotional resource set identifiers. If the resource offer generation model determines that it cannot generate a resource offer set to satisfy the maximum price characteristic for each resource set identifier or one or more promotional resource set identifiers, the resource offer generation model may, secondly, attempt to generate a resource offer set to include resource offer data objects associated with price characteristics that are satisfied by exceeding the average price characteristic for each resource set identifier or one or more promotional resource set identifiers. If the resource offer generation model determines that it cannot generate a resource offer set to satisfy the average price characteristics for each resource set identifier or one or more promotional resource set identifiers, the resource offer generation model may, thirdly, attempt to generate a resource offer set to include resource offer data objects associated with price characteristics that are satisfied, such as exceeding the average price characteristics for resource set identifiers associated with a fair market offer set.

[0257] In block 1218, the apparatus 900 includes means such as a data management circuit 910, a model performance circuit 912, a processor 902, or a combination thereof, for generating control signals that produce a renderable object containing an offer adjustment interface displayed on a first of one or more client devices. The client device may be a specific client device associated with an offer control user authenticated by the apparatus 900 for an authenticated session. The control signals may produce the rendering of the offer adjustment interface.

[0258] The offer adjustment interface may include each resource offer value for each resource offer data object within the resource offer set. Additionally, the offer adjustment interface may include metrics of the offer analysis dataset, such as portfolio-level financial values ​​based on the adjusted resource offer set and market intelligence data. Furthermore, in some embodiments, the offer adjustment interface includes a dashboard for accessing one or more analysis interfaces, each analysis including one or more metrics of data based on or derived from various parts of the resource offer set and / or market intelligence data. The device may render the offer adjustment interface by transmitting a renderable data object that embodies the offer adjustment interface.

[0259] In block 1220, the device 900 includes means such as a data management circuit mechanism 910, a communication circuit mechanism 908, a processor 902, or a combination thereof, for updating a resource offer set to a tuned resource offer set. The tuned resource offer set may include one or more resource offer data objects having tuned offer values ​​entered by an offer control user.

[0260] In some embodiments, the device 900 is capable of receiving one or more control signals from one or more client devices, the control signals including one or more adjustment data objects for use when updating a resource offer set. The resource offer set may be updated to create an adjusted resource offer set based on one or more adjustment data objects. For example, one or more adjustment data objects may embody, represent, or otherwise include one or more adjusted resource offer values ​​for one or more resource offer data objects in the resource offer set.

[0261] In other embodiments, the adjusted resource offer set may be received from a client device. For example, the client device may update the resource offer set to create an adjusted resource offer set based on one or more adjustment data objects, where the device 900 may receive the adjusted resource offer set from the client device after it has been saved and / or saved and submitted by the offer control user via the client device.

[0262] In block 1222, the device 900 includes means such as a communication circuit mechanism 908, an input / output circuit mechanism 906, and a processor 902 for generating control signals or multiple control signals that produce a renderable object including an authorization interface displayed on a second of one or more client devices. The second of one or more client devices may be an authorization device associated with an offer authorization user authenticated by the device 900 for an authenticated session. The control signals may be transmitted, for example, over a network to produce the rendering of the authorization interface.

[0263] The approval interface may include a coordinated resource offer set received and submitted from a client device associated with the offer control user, and / or additional information (such as a dashboard) for analyzing the coordinated resource offer set. For example, the approval interface may additionally include metrics for an offer analysis dataset calculated and / or otherwise determined based on the coordinated resource offer set. Additionally or alternatively, in some embodiments, the approval interface may include a dashboard for accessing one or more analysis interfaces based on the coordinated resource offer set. In some embodiments, the offer analysis dataset dashboard and metrics(s) of the approval interface may include the same elements rendered in the offer adjustment interface. The device may cause rendering to occur on the approval device when an offer approval user accesses the device via the approval device.

[0264] In block 1224, the device 900 includes means such as a communication circuit mechanism 908, a processor 902, or a combination thereof, for receiving an offer approval control signal, including an offer status indicator, from an approval device. The offer approval control signal may be received from the approval device in response to user engagement with the approval interface. The offer status indicator may represent an approval status indicator (e.g., when an offer approval user analyzes and / or approves a coordinated resource offer set) or a rejection status indicator (e.g., when an offer approval user analyzes and / or rejects a coordinated resource offer set). The offer status indicator may be received in response to user engagement with the approval interface, for example, in response to user engagement with the offer approval component or offer rejection component of the approval interface.

[0265] In block 1226, the device 900 includes means such as a data management circuit mechanism 910, a communication circuit mechanism 908, a processor 902, or a combination thereof, for storing coordinated resource offer sets associated with regional program identifiers, collection period data objects, and offer status indicators. In some embodiments, the device is capable of storing coordinated resource offer sets and / or offer approval statuses associated with the coordinated resource offer sets, so that each can be retrieved using the regional program identifier and collection period data object. The device may store the coordinated resource offer sets and / or offer approval statuses in a database, for example, embodied by the resource offer generation system database 802C.

[0266] If the offer approval status is approved, the flow may terminate. If the offer approval status is rejected, the flow may return to block 1218 for adjustment by the offer control user via the client device. This cycle may continue until the offer control user approves the adjusted resource offer set. Using the accepted resource offer set, one or more offers may be made to various third-party entities for the purchase of such resources.

[0267] Figure 12B shows a flowchart of an exemplary process 1200B for generating a trusted resource characteristics dataset based on applying one or more untrusted third-party resource characteristics datasets and one or more characteristics data objects from a distributed user platform to an exception detection model according to some embodiments of the present disclosure. The operations exemplified with respect to exemplary process 1200 may be performed, for example, by a resource offer generation system embodied by device 900.

[0268] One non-exclusive exemplary use for generating a trustworthy resource characteristics dataset based on one or more untrustworthy third-party resource datasets and distributed resource characteristics datasets is to generate a fair market offer set for acquiring used mobile devices. Each untrustworthy third-party resource characteristics dataset may contain price characteristics for various used mobile devices associated with various resource set identifiers, where each untrustworthy third-party resource characteristics dataset is associated with a different third-party entity. The untrustworthy third-party resource characteristics dataset may contain historical prices at which the third-party entity purchases used mobile devices for various resource set identifiers. However, the untrustworthy third-party resource characteristics dataset is unreliable as a fair price characteristic for each resource because the price characteristics may be associated with exceptional periods (e.g., a third-party entity may offer a promotion that causes the price of a particular used mobile device to rise despite the device's depreciation).

[0269] In this regard, since pricing characteristics relate to offers made by individual users of a distributed user platform for acquiring and / or distributing resources, the distributed resource characteristics dataset is not affected by promotions. Unlike third-party entities that are commercial resellers, individuals do not apply exceptional periods (such as promotional periods for specific resources) to their pricing characteristics for various resources. However, since a trustworthy seller of used mobile devices generally receives a higher price for a particular resource, the distributed resource characteristics dataset is not accurate for the purpose of generating a fair market offer set. Generating a trustworthy resource characteristics dataset via an exception detection model eliminates the flaw of trusting either a dataset associated with one or more third-party entities, or a dataset associated with the distributed resource characteristics dataset.

[0270] In block 1252, the device 900 includes means such as a data management circuitry 910, a communication circuitry 908, a processor 902, or a combination thereof, for retrieving an untrusted third-party resource characteristics dataset. The untrusted third-party resource characteristics dataset may include one or more records associated with one or more third-party offerings of a resource by a third-party entity. For example, in some embodiments, the untrusted third-party resource characteristics dataset includes a third-party resource pricing dataset. The third-party resource pricing dataset may include one or more records, each record including or otherwise associated with an offer price, a resource set identifier, and / or a timestamp. Each record may represent an offer price for a particular resource set identifier offered by a third-party entity on a specific date. In some embodiments, the resource may be a used mobile device.

[0271] In some embodiments, an untrusted third-party characteristics dataset may be scraped from one or more web services accessible via communication with a third-party device, such as a server, associated with a third-party entity. The device 900 includes means for performing the scraping and / or is associated with one or more systems for performing the scraping, and can retrieve the untrusted third-party characteristics dataset from an updated repository upon completion of the scraping. In some embodiments, an untrusted third-party resource characteristics dataset may be retrieved from a third-party device associated with a third-party entity. For example, via one or more APIs, the device 900 can retrieve an untrusted third-party resource characteristics dataset by communicating with a server and / or an accessible repository associated with a third-party entity. In other embodiments, an untrusted third-party resource characteristics dataset may be retrieved from a different third-party entity, such as a third-party device associated with a data aggregator.

[0272] In block 1254, the device 900 includes means such as a data management circuit mechanism 910, a communication circuit mechanism 908, a processor 902, or a combination thereof, for retrieving a distributed resource characteristics dataset associated with a distributed user platform. The distributed resource characteristics dataset may include one or more records associated with offerings generated by one or more distributed users of resources provided through the distributed user platform. In some embodiments, the distributed user platform may allow users to offer to other users of the distributed user platform to buy and / or sell resources at any price desired by the user. Examples of distributed user platforms include, but are not limited to, eBay®, Craigslist®, Amazon Marketplace®, and Facebook Marketplace®. Each record may represent the price of a used mobile device offered by a user on a particular day through a particular distributed user platform. Each record may include, for example, an offer price, a resource set identifier, and / or a timestamp, or may be otherwise associated.

[0273] In some embodiments, the distributed resource dataset may be scraped from one or more web services accessible via communication with devices associated with a distributed user platform, such as servers. The device 900 includes means for performing the scraping and / or is associated with one or more systems for performing the scraping, and can retrieve the distributed resource characteristics dataset from an updated repository upon completion of the scraping. In some embodiments, the distributed resource characteristics dataset may be retrieved from devices associated with a distributed user platform. For example, via one or more APIs, the device 900 may retrieve the distributed resource characteristics dataset by communicating with servers and / or accessible repositories associated with the distributed user platform. In other embodiments, the distributed resource characteristics dataset may be retrieved from devices associated with different third-party entities, such as data aggregators.

[0274] The device may generate a trusted resource characteristics dataset by applying at least an untrusted third-party resource characteristics dataset (or multiple untrusted third-party resource characteristics datasets) and a distributed resource characteristics dataset to an exception detection model. The exception detection model may be designed, configured, and / or trained to detect outliers and / or other exceptions associated with specific characteristics. In some embodiments, the exception detection model may be embodied by one or more algorithms or machine learning models. In this regard, applying at least an untrusted third-party resource characteristics dataset and a distributed resource characteristics dataset to the exception detection model may include one or more of blocks 1256-1278.

[0275] In block 1256, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for integrating an untrusted third-party resource characteristics dataset with a distributed resource characteristics dataset. Integrating an untrusted third-party resource characteristics dataset with a distributed resource characteristics dataset may include one or more preprocessing steps for aligning, organizing, and / or otherwise constructing the datasets for comparison.

[0276] In some embodiments, untrusted third-party resource characteristics datasets and distributed resource characteristics datasets are aligned based on temporal alignment. When a third-party resource pricing dataset is used as an untrusted third-party resource characteristics dataset and a distributed resource pricing dataset is used as a distributed resource characteristics dataset, for example, the third-party resource pricing dataset may include at least multiple records, each containing a resource price offered by the third party and an associated timestamp (e.g., representing the date the price was offered by the third party). Similarly, the distributed resource pricing dataset may include at least multiple records, each containing a resource price offered through a distributed user platform and an associated timestamp (e.g., representing the date the price was offered through the distributed user platform). An exemplary temporal alignment may align the third-party resource pricing datasets and distributed resource pricing datasets based on a timestamp for each record, for example, so that records associated with the same date can be compared.

[0277] In some embodiments, untrusted third - party resource characteristic data sets and distributed resource characteristic data sets are aligned based on time alignment and resource set identifier alignment. Continuing with the example of third - party resource pricing data sets and distributed resource pricing data sets, each record within the third - party resource pricing data set and the distributed resource pricing data set may also include a specific resource set identifier or be associated with it in some other way. Based on the resource set identifier within or associated with each record, the untrusted third - party resource data set and the distributed resource pricing data set can be aligned so that records associated with the same date and the same resource set identifier can be compared.

[0278] In block 1258, the apparatus 900 includes means such as the model performance circuit mechanism 912, the processor 902, or a combination thereof, to identify an offset between an untrusted third - party resource characteristic data set and a distributed resource characteristic data set. In some embodiments, the apparatus includes means to identify an offset by comparing a first characteristic of a first resource within an untrusted third - party resource characteristic data set with a first characteristic of the first resource within a distributed resource characteristic data set from a distributed user platform. In some embodiments, the first characteristic can be, for example, the resource price if the untrusted third - party resource data set includes a third - party resource pricing data set and the distributed resource characteristic data set includes a distributed resource pricing data set. In some such embodiments, the offset can represent the price difference for a given time interval (e.g., daily, weekly, etc.) between the untrusted third - party resource characteristic data set and the distributed resource characteristic data set for a particular resource set identifier.

[0279] In block 1260, the device 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for identifying a set of exception periods that include at least one exception period in an unreliable third-party resource characteristics dataset, based on a deviation of offset. For example, the deviation may be a change in offset from the assumed level, the decision level, or the mean level. In some embodiments, for example, each exception period may represent a time interval in which a particular resource set identifier is offered by a third-party entity at an increased price (e.g., a promotional price). In this regard, each exception period may be defined by a first timestamp (e.g., an interval start timestamp) and a second timestamp (e.g., an interval end timestamp), where the exception period is flagged for all records associated with an intermediate timestamp between the first and second timestamps.

[0280] In some embodiments, an exception period may be identified when an offset deviation meets an exception deviation threshold. In some embodiments, the apparatus 900 may identify, determine, retrieve, or otherwise associate with an exception deviation threshold. In some embodiments, for example, the apparatus 900 may include means for identifying a first timestamp when an offset deviation meets the exception deviation threshold. For example, in some embodiments, an offset deviation meets the exception deviation threshold when the deviation is greater than or equal to the exception deviation threshold. Using price characteristics as an example, an exception deviation threshold may be met when an offset deviation exceeds a certain value or percentage and a resource price associated with an unreliable third-party resource characteristic dataset is greater than a set amount or set percentage of a resource price associated with a distributed resource characteristic dataset. The apparatus 900 may include means for identifying a second timestamp when an offset deviation does not meet the exception deviation threshold. In some embodiments, for example, the deviation may be a desired standard deviation amount from an assumed deviation or average deviation based on historical price setting characteristics over a predetermined non-exception time interval (e.g., 15 weeks not including the exception period).

[0281] Additionally, for example, in some embodiments, an offset deviation does not meet the exception deviation threshold when the deviation is less than or equal to the exception deviation threshold. Returning to the price characteristic example, an exception deviation threshold may not be met when an offset deviation returns to or falls below a certain value or percentage, such as when a resource price associated with an unreliable third-party resource characteristic dataset returns to the standard operating range from a resource price associated with a distributed characteristic dataset. A price characteristic returning to the standard operating range indicates the end of an exception period, such as a sales promotion period.

[0282] In block 1262, the device 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for removing at least one exception period from an untrusted third-party resource characteristics dataset to generate an updated untrusted third-party resource characteristics dataset. In some embodiments, removing an untrusted third-party resource characteristics dataset includes marking each record associated with an exception period as an exception so that these records can be ignored. By marking the exception periods, the untrusted third-party resource characteristics dataset can be used for data analysis, for example, by rendering the metrics of the untrusted third-party resource characteristics dataset into one or more interfaces provided to offer control users and / or approval users. In other embodiments, records associated with an exception period can be erased from the untrusted third-party resource characteristics dataset.

[0283] In block 1264, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for generating a trusted resource characteristics dataset based on at least an updated untrusted third-party resource characteristics dataset. In some embodiments, for example, the trusted resource characteristics dataset may include an updated set of untrusted third-party resource characteristics. In other embodiments, the trusted resource characteristics dataset may include at least the average resource price characteristics for a given resource set identifier by averaging the remaining price characteristics for each record associated with the resource set identifier. The trusted resource characteristics dataset may include, for example, maximum price characteristics and / or average price characteristics for various resources or resource set identifiers associated with offers by a third-party entity associated with the updated untrusted third-party resource characteristics dataset.

[0284] In some embodiments, multiple untrusted third-party resource characteristic datasets may be updated and compared so that generating a trusted resource characteristic dataset is based on a comparison of multiple untrusted third-party resource characteristic datasets. In this regard, in block 1266, the device 900 includes means for retrieving a second untrusted third-party resource characteristic data, such as a data management circuit mechanism 910, a communication circuit mechanism 908, a processor 902, or a combination thereof. The second untrusted third-party resource characteristic dataset may include one or more records associated with one or more third-party offerings of a resource by a second third-party entity. For example, in some embodiments, the second entity may be a second commercial entity that purchases used mobile devices.

[0285] In some embodiments, the second untrusted third-party characteristics dataset may be scraped from one or more web services accessible via communication with another third-party device, such as a second server, associated with the second third-party entity. The device 900 includes means for performing the scraping and / or is associated with one or more systems for performing the scraping, and can retrieve the second untrusted third-party characteristics dataset from an updated repository upon completion of the scraping. In some embodiments, the second untrusted third-party resource characteristics dataset may be retrieved from a second third-party device associated with the second third-party entity. For example, via one or more APIs, the device 900 can retrieve the second untrusted third-party resource characteristics dataset by communicating with a second server and / or an accessible second repository associated with the second third-party entity. In other embodiments, the second untrusted third-party resource characteristics dataset may be retrieved from a different third-party entity, such as a second third-party device associated with a data aggregator. In some embodiments, a second untrusted third-party characteristics dataset may be retrieved in the same manner as the first untrusted third-party characteristics dataset retrieved earlier. In block 1270, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for identifying a second offset between the untrusted third-party resource characteristics dataset and the distributed resource characteristics dataset.

[0286] In block 1272, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for identifying a second set of exception periods that include at least one exception period in a second unreliable third-party resource characteristics dataset, based on a second deviation of a second offset. For example, the second deviation may be a change in the offset from an assumed level, a determined level, or a mean level based on the distributed resource characteristics dataset.

[0287] In some embodiments, an exception period in a second untrusted third-party resource characteristics dataset is identified when the second deviation of the second offset satisfies an exception deviation threshold, or a second exception deviation threshold associated with the second untrusted third-party resource characteristics dataset. It should be understood that the offset and deviation may define the expected operating range of a characteristic, for example, the price range of a price characteristic associated with a particular resource set identifier.

[0288] In block 1274, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for removing an exception period set from a second untrusted third-party resource characteristics dataset to generate an updated second untrusted third-party resource characteristics dataset. In some embodiments, removing an exception period set from the second untrusted third-party resource characteristics dataset includes marking each record within or associated with each exception period as an exception so that these records can be ignored. By marking the exception periods, the second untrusted third-party resource characteristics dataset can be used for data analysis. In other embodiments, records within or associated with an exception period can be erased from the untrusted second third-party resource characteristics dataset.

[0289] In block 1276, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for comparing an updated untrusted third-party resource characteristics dataset with an updated second untrusted third-party resource characteristics dataset. In some embodiments, comparing the updated untrusted third-party resource characteristics dataset with an updated second untrusted third-party resource characteristics dataset may determine greater characteristics, such as greater price characteristics, for a particular resource set identifier between the two datasets. In other embodiments, multiple untrusted third-party resource characteristics datasets may be compared.

[0290] In block 1278, the apparatus 900 includes means such as a model performance circuit mechanism 912, a processor 902, or a combination thereof, for generating a trusted resource characteristics dataset based on a comparison between an updated untrusted third-party resource characteristics dataset and an updated second untrusted third-party resource characteristics dataset. In some embodiments, the trusted resource characteristics dataset may be generated to include specific resource characteristics from each of the datasets based on the comparison. For example, if a dataset includes pricing characteristics for resources, the trusted resource characteristics dataset may include the highest pricing characteristics for each resource set identifier based on a comparison between two or more updated untrusted third-party resource datasets.

[0291] For example, in some embodiments, a trusted resource characteristics dataset includes a fair market offer data object for various resource set identifiers. The fair market offer data object may include pricing characteristics for each resource set identifier, such as a fair market offer value, where the pricing characteristics are generated based on comparisons. For example, the pricing characteristics for a particular resource set identifier could be the maximum pricing characteristics across various updated untrusted third-party resource characteristics datasets for that resource set identifier. The updated untrusted third-party resource characteristics datasets may include the maximum pricing characteristics for a particular resource set identifier associated with various third-party entities. For example, the average pricing characteristics could be determined by calculating the average pricing characteristics for a resource set identifier over a predetermined time interval (e.g., 15 weeks) with exception periods removed, for a particular third-party entity and a particular resource set identifier. The average pricing characteristics for a distributed user platform could then be determined, for example, based on a distributed resource characteristics dataset. Subsequently, the maximum pricing characteristics for a particular resource set identifier and for a particular third-party entity can be determined by multiplying the average pricing characteristics for resource set identifiers associated with the distributed user platform by the average pricing characteristics for resource set identifiers associated with the third-party entity as a percentage of the average pricing characteristics for resource set identifiers associated with the distributed user platform (for example, the average pricing characteristics for resource set identifiers associated with the third-party entity divided by the average pricing characteristics for resource set identifiers associated with the distributed user platform).

[0292] Next, it is possible to calculate a fair market offer value for a resource set identifier using the maximum pricing characteristics for each resource set identifier and each third-party entity represented in each of the updated unreliable resource characteristics datasets. The fair market offer value may be embodied by a fair market offer data object or contained in a reliable resource characteristics dataset associated with a particular resource set identifier. For example, the fair market offer value (e.g., a reliable pricing characteristic) may be determined as the maximum pricing characteristic for each third-party entity. Continuing with the example of acquiring a used mobile device, if a first updated untrusted third-party resource characteristics dataset for third-party entity A is associated with a pricing characteristic of 90 units (e.g., dollars) for a particular resource set identifier, a second updated untrusted third-party resource characteristics dataset for third-party entity B is associated with a pricing characteristic of 85 units for a particular resource set identifier, a third updated untrusted third-party resource characteristics dataset for third-party entity C is associated with a pricing characteristic of 87 units for a particular resource set identifier, and a fourth updated untrusted third-party resource characteristics dataset for third-party entity D is associated with a pricing characteristic of 93 units for a particular resource set identifier, then the trusted resource characteristics dataset may include a pricing characteristic of 93 units for a particular resource set identifier as the maximum value among all updated untrusted third-party resource characteristics datasets. This pricing characteristic can be embodied as a fair market offer data object for a particular resource set identifier, representing the fair market offer value of the resource associated with that particular resource set identifier during a non-exceptional (e.g., non-promotional) period.

[0293] Process 1250B for generating a trusted resource characteristics dataset also enables the generation of trusted characteristics sets for other non-resource datasets from one or more untrusted datasets. For example, if an untrusted characteristics set is associated with an untrusted third-party entity, the untrusted characteristics dataset can be extracted. A distributed characteristics dataset can then be collected from or associated with a distributed user platform. An offset between the untrusted third-party characteristics dataset and the distributed characteristics dataset can then be identified. Exception periods can be identified based on the deviation of the offset, and these exception periods can be removed from the untrusted characteristics dataset to generate an updated untrusted resource characteristics dataset. It is then possible to generate a trusted characteristics dataset using the updated untrusted resource characteristics dataset, and / or generate multiple updated untrusted resource characteristics datasets so that a trusted characteristics dataset can be generated based on a comparison between multiple updated untrusted resource characteristics datasets. The use of resource pricing in the above description should not be considered to limit the scope and intent of the disclosures herein. Exemplary User Interface Figures 13–15 illustrate user interfaces of exemplary embodiments. For example, several systems, methods, and computer program products may be configured to render one or more of the exemplary interfaces, or otherwise produce these renderings. It should be understood that in some embodiments, the various components illustrated in each interface may be embodied by several known interface components configured to receive countless types of user input. All interface components, individually and in combination, are illustrative and do not limit the scope and intent of the disclosure herein.

[0294] In some embodiments, each interface may be rendered by a client device in response to receiving a control signal containing a renderable data object. The control signal may be generated and / or configured by the resource offer generation system for transmission to, for example, one or more client devices. In some embodiments, the renderable data object may be generated and / or configured by the resource offer generation system to contain, for example, an interface to be rendered.

[0295] Figure 13 illustrates an exemplary offer adjustment interface 1300 according to an embodiment of the present disclosure. The offer adjustment interface 1300 is rendered to a client device associated with an offer control user and may be generated, for example, by a resource offer generation system when a resource offer set is generated. The offer adjustment interface 1300 includes an offer analysis table 1322. The offer analysis table 1322 may include a row for each resource offer data object in the generated resource offer set. The offer analysis table 1322 includes several columns of information associated with and including the generated resource offer set. The offer analysis table includes a resource offer value column 1302 which includes the resource offer value for each resource offer data object in the generated resource offer set. Each row in the resource offer column 1302 is configured to receive user input for adjusting the corresponding resource offer value of the resource offer data object. For example, an offer control user may drag a particular row to input a new resource offer value for a particular resource offer data object.

[0296] The offer analysis table may further include one or more additional columns of information associated with analyzing the resource offer set. For example, the offer analysis table 1322 includes a resource attribute data column 1306, market intelligence data 1308, and a system-generated data column 1310. System-generated data columns, such as system-generated data column 1310, include data generated and output by one or more forecasting systems, such as forecasting system 102 embodied by device 200, and / or resource offer generation systems, such as resource offer generation system 802 embodied by device 900. In some embodiments, the system-generated data column may include, in combination with market intelligence data, such as assumed margins associated with each resource offer data object, data generated and output by one or more forecasting systems, such as forecasting system 102 embodied by device 200, and / or resource offer generation systems, such as resource offer generation system 802 embodied by device 900, and / or information derived and / or calculated based on the resource offers.

[0297] The offer adjustment interface 1300 includes an offer analysis dataset 1304, specifically, metrics from at least a portion of the offer analysis dataset rendered as text. The metrics from the offer analysis dataset are rendered non-repeatingly from the offer analysis table 1322 and dashboard 1320, enabling dynamic and efficient visualization and analysis while navigating the offer analysis table 1322 and / or performing adjustments. The offer analysis dataset may include various pieces of information associated with the generated resource offer set and / or the adjusted resource offer set currently being adjusted. For example, the offer analysis dataset may include profit per resource derived from the generated resource offer set. Additionally or alternatively, in some embodiments, the offer analysis dataset further includes profit margins for the adjusted resource offer set currently being adjusted. Additionally or alternatively, the offer analysis dataset may include a resource loss indicator representing the number of resource offer data objects currently associated with negative margin values ​​(e.g., associated with assumed selling prices not exceeding resource offer values). In some embodiments, at least a portion of the offer analysis dataset is dynamically updated when an offer control user adjusts one or more resource offer values ​​for various resource offer data objects within a resource offer set. The metrics in the offer analysis dataset may also be updated to reflect the updated offer analysis dataset.

[0298] The offer analysis interface 1300 includes an analysis table management component 1314. Each of the analysis table management components 1314 may be configured to filter, adjust, or otherwise influence the data rendered through the offer analysis table 1322. For example, one or more analysis table management components may be provided to filter rows based on specific values ​​in specific columns, such as based on a resource set identifier or other resource attributes (e.g., carrier, manufacturing, model / category type).

[0299] The offer analysis interface includes an offer storage component 1316. The offer storage component 1316 may be configured to allow the storage of a coordinated resource offer set without requiring it to be submitted for approval. For example, the offer storage component 1316 may be configured to cause the transmission of a request to store a coordinated resource offer set accessible by the offer control user, for example, to the resource offer generation system 802. Once stored, the coordinated resource offer set can be retrieved later and used when rendering the offer coordination interface (for example, in a different session).

[0300] The offer analysis interface includes an offer submission component 1318. The offer submission component 1318 may be configured to enable the submission of an adjusted resource offer set for approval by an offer approval user. The adjusted resource offer set may include a resource offer data object adjusted by an offer control user via an offer adjustment interface. The adjusted offer set may include one or more resource offer data objects having adjusted resource offer values. To enable the submission of the adjusted resource offer set, the offer submission component 1318 may be configured to cause, for example, the transmission of the adjusted resource offer set to a resource offer generation system 802. The adjusted resource offer set may be transmitted as part of a request to store the submitted adjusted resource offer set or otherwise associated therewith.

[0301] The offer analysis interface includes an external management component 1324. The external management component may be configured to generate and / or manage one or more files representing changes to an offer analysis table 1322. For example, the external management component 1324 may include one or more components for uploading a file including a resource offer set, such as Microsoft Excel (trademark), for rendering via the offer analysis table. The external management component 1324 may additionally or alternatively include one or more components for downloading the offer analysis table 1322 or a portion thereof to a file. For example, the offer analysis table 1322 may be converted to an external file type (e.g., Microsoft Excel (trademark)) and downloaded as needed.

[0302] The offer adjustment interface 1300 further includes a dashboard section 1320. The dashboard section 1320 may be rendered non-redundantly from the metrics of the offer analysis dataset 1304, as well as from the offer analysis table 1322 and the dashboard 1320, enabling efficient visualization and analysis while navigating the interfaces offered by the dashboard section 1320. The dashboard section 1320 may include one or more components for accessing one or more other interfaces associated with resource offer sets and / or market intelligence data. Specifically, the dashboard section 1320 includes user interface components for accessing the offer intensity interface, market comparison interface, and price intensity interface, or for causing renderings of these in other ways.

[0303] Figure 14 illustrates an exemplary offer approval interface 1400 according to an embodiment of the present disclosure. The offer approval interface 1400 is rendered to an approval device associated with an offer approval user and may be generated by a resource offer generation system, for example, when an offer control user submits a coordinated resource offer set. The offer approval interface 1400 includes an offer analysis table 1322, which includes a resource offer value column 1302 and the remaining columns 1306-1312. The resource offer value column 1302 may be rendered in such a way that it is not adjustable. For example, the resource offer value column 1302 may not be configured to accept user input. The offer approval interface 1400 may additionally include a dashboard section 1320 for accessing one or more of the various other interfaces described, and price analysis information 1304 based on the coordinated resource offer set.

[0304] The offer approval interface 1400 includes an offer approval component 1402 and an offer rejection component 1404. The offer approval component 1402 enables the approval of a coordinated set of resource offers. For example, in response to a user engagement by an offer approval user with the offer approval component 1402, the approval device may transmit an offer approval response that includes an offer approval status representing an approved status. The offer rejection component 1404 enables the rejection of a coordinated set of resource offers. For example, in response to a user engagement by an offer approval user with the offer rejection component 1404, the approval device may transmit an offer approval response that includes an offer approval status representing a rejected status. In some embodiments, in response to a user engagement by an offer approval user with the offer rejection component 1404, the approval device may cause the rendering of an interface component (not shown) configured to create and submit an offer rejection message. For example, a text box configured to allow an offer-approving user to compose an offer rejection message, and a message submission button, wherein, upon user engagement with the message submission button, the management device transmits an offer approval response that includes at least an offer approval status representing a rejected status and the created offer rejection message.

[0305] Figure 15 illustrates an exemplary market comparison interface 1500 according to an embodiment of the present disclosure. The market comparison interface 1500 is rendered on a user device or authorization device upon engagement with an interface component associated with the dashboard portion 1320, and may be generated, for example, by a resource offer generation system. The market comparison interface 1500 includes the dashboard portion 1320 for accessing one or more of the various other interfaces described.

[0306] The market comparison interface 1500 includes a competitor selection component 1502. The competitor selection component may be configured to compare against resource set identifiers marked as being in a promotion period, against resource set identifier markets that are not in a promotion period, or to switch summary market data based on all resource set identifiers. Each component status of the competitor selection component 1502 may filter the market intelligence data used to generate the market summary visualization component 1506 and the market summary table 1508.

[0307] The market comparison interface 1500 includes a data management component 1504. The data management component 1504 may include one or more interface components for receiving user input for one or more resource attributes. The input resource attribute values ​​may be used to filter, or further filter, the market intelligence data used to generate the market overview visualization component 1506 and the market overview table 1508.

[0308] The market comparison interface 1500 includes a market overview visualization component 1506. The market overview visualization component 1506 may provide an overview of resource offer values ​​for resource offer data objects of a particular adjusted resource offer set. For example, market overview visualization component 1506A may provide an overview of all resource offer values ​​compared to the market average for the corresponding resource set identifier, based on market intelligence data for all competitor entities. Market overview visualization component 1506B may provide an overview of all resource offer values ​​compared to the market maximum for the corresponding resource set identifier (for example, for a particular resource offer data object having resource offer values ​​for a particular resource set identifier, the best offer value associated with the competitor entities for that resource set identifier), based on market intelligence data for the visualization components of all competitor entities.

[0309] The market comparison interface 1500 includes a market overview table 1508. The market overview table 1508 may contain an aggregated overview of market intelligence data associated with all competitor entities. For example, the market overview table 1508 may include the number of resources within a predefined bandwidth compared to a reference metric. For instance, it may display the number of resources associated with a resource offer data object that has a resource offer value within a predefined range, represented by the predefined bandwidth. The bandwidth may be determined based on the regional program identifier for a selected regional program data object.

[0310] Dashboards such as Dashboard 1320 in Figures 13, 14, and 15 may also provide access to a price trend interface. The price trend interface may include various visual indicators, such as graphs, associated with third-party offer values, compared to the average selling price for a specific channel profile associated with a distributed user platform, such as eBay®. The price trend interface may include such indicators for any number of third parties (e.g., one or more third parties, one or more competitors, etc.). Furthermore, the price trend interface may render indicators about promotional periods. Additional implementation details An exemplary processing system is shown in Figure 2, but the subject matter and functional operations described herein may be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, or a combination of one or more thereof, including the structures disclosed herein and their structural equivalents.

[0311] The subjects and embodiments of operation described herein may be implemented in digital electronic circuit mechanisms, or in computer software, firmware, or hardware, or a combination of one or more thereof, including the structures disclosed herein and their structural equivalents. Embodiments of the subjects described herein may be implemented as one or more modules of computer programs, i.e., computer program instructions encoded on a computer storage medium for execution by an information / data processing device or for controlling its operation. Alternatively, or in addition, program instructions may be encoded in artificially generated propagating signals, for example, machine-generated electrical, optical, or electromagnetic signals generated to encode information / data for transmission to a receiver device suitable for execution by an information / data processing device. The computer storage medium may be or include computer-readable storage devices, computer-readable storage boards, random or serial access memory arrays or devices, or a combination of one or more thereof. Furthermore, although the computer storage medium is not a propagating signal, the computer storage medium may be a source or destination for computer program instructions encoded in artificially generated propagating signals. Computer storage media can also be, or be comprised of, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0312] The operations described herein may be implemented as operations performed by an information / data processing device on information / data stored in one or more computer-readable storage devices or received from other sources.

[0313] The term “data processing device” encompasses all kinds of devices, machines, and equipment for processing data, including, for example, programmable processors, computers, systems on a chip, or multiple or a combination of the aforementioned. This device may include dedicated logic circuit mechanisms, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, the device may also include code that creates the execution environment for the computer program in question, such as processor ...

Claims

1. A method for allocating a constrained set of resources in a dynamic environment, At least one processor receives a request data object from a client device associated with a channel profile, The at least one processor receives a hierarchical parameter data object, The at least one processor receives an attenuation parameter data object, The at least one processor extracts a resource request set from the request data object, wherein the resource request set includes a plurality of request parameters. The at least one processor extracts multiple hierarchical parameters from the hierarchical parameter data object, The at least one processor extracts multiple attenuation parameters from the attenuation parameter data object, The at least one processor assigns the channel profile to a first tier from among a plurality of tiers, and the assignment of the channel profile to the first tier includes applying the plurality of tiering parameters and a first request parameter from the plurality of request parameters to a first model. The at least one processor generates a user-associated, adjusted resource request set by applying a decay curve to a second request parameter from the plurality of request parameters, wherein the decay curve is at least partially based on the plurality of decay parameters. The at least one processor determines, based on the first hierarchy and the adjusted resource request set, whether the channel profile satisfies each of a plurality of threshold conditions, In response to determining that the channel profile satisfies each of the plurality of threshold conditions, the at least one processor applies the adjusted resource request set and the first hierarchy to the second model to generate a resource allocation set for the channel profile, A method comprising: the at least one processor generating a control signal causing a renderable object including an index of the resource allocation set to be displayed in a user interface.

2. The aforementioned multiple hierarchical parameters include portfolio-level volumes associated with the Channel profile, The method according to claim 1, further comprising the at least one processor scaling the portfolio-level volume associated with the channel profile, at least in part, on the basis of assigning the portfolio-level volume associated with the channel profile to a position in a ranked list of portfolio-level volumes.

3. The aforementioned multiple hierarchical parameters include the expected portfolio-level profit margin associated with the channel profile, The method according to claim 1, further comprising the at least one processor scaling the expected portfolio-level profit margin associated with the channel profile, at least in part, on the basis of assigning the expected portfolio-level profit margin associated with the channel profile to a position in a ranked list of expected portfolio-level profit margins.

4. (i) The plurality of hierarchical parameters include an entropy parameter associated with the channel profile, (ii) The entropy parameter associated with the channel profile is expressed by the formula E = Σn * log n, where E is the entropy parameter and n is the volume of devices bid on in a given bid divided by the total volume of devices bid on. The method according to claim 1, further comprising the at least one processor scaling the entropy parameter associated with the channel profile, at least in part on assigning the entropy parameter associated with the channel profile to a position in a ranked list of entropy parameters.

5. The method according to claim 1, wherein the plurality of hierarchical parameters include an index of geographical location associated with the channel profile.

6. The aforementioned hierarchical parameters include timing parameters associated with the relationship between the channel profile and the first entity. The method according to claim 1, further comprising the at least one processor scaling the timing parameter, at least in part, on the basis of calculating the number of days to be reflected by the timing parameter and assigning the number of days to a position in a ranked list of the timing parameter.

7. The aforementioned multiple hierarchical parameters include indicators of the audit status of the channel profile, The method according to claim 1, further comprising the at least one processor scaling the index of the audit status of the channel profile by converting the index of the audit status of the channel profile to a single-digit binary value.

8. The aforementioned hierarchical parameters include an indicator of the channel profile's exclusivity status, The method according to claim 1, further comprising the at least one processor scaling the index of the exclusive status of the channel profile by converting the index of the exclusive status of the channel profile to a single-digit binary value.

9. The method according to claim 1, wherein the plurality of attenuation parameters include (i) a set of pricing history information associated with a plurality of channel profiles and (ii) a set of pricing history information associated with a public auction market.

10. The method according to claim 1, wherein the plurality of request parameters include at least one requested quantity of an inventory element.

11. The method according to claim 1, wherein the plurality of requirement parameters include a list of SKU identifiers associated with a plurality of inventory elements.

12. The method according to claim 1, wherein the plurality of requirement parameters include a first bid price for a first inventory element.

13. The method according to claim 1, wherein the plurality of requirement parameters include a plurality of bids associated with a plurality of inventory elements.

14. The method according to claim 1, wherein the plurality of request parameters include a set of properties associated with a Channel profile.

15. The at least one processor assigns the channel profile to the first hierarchy from among a plurality of hierarchies, and the assignment of the channel profile to the first hierarchy includes applying the first request parameter from the plurality of hierarchical parameters and the plurality of request parameters to the first model, Determining whether the parameters within the aforementioned hierarchy of parameters include outliers, The method according to claim 1, further comprising removing the outliers from the plurality of hierarchical parameters.

16. The method according to claim 1, wherein the at least one processor generates the adjusted resource request set associated with the user by applying the decay curve to the second request parameter from the plurality of request parameters, wherein the decay curve is at least partially based on the plurality of decay parameters, and the generation includes applying the plurality of decay parameters to a multivariate adaptive regression spline (MARS) model.

17. The method according to claim 1, wherein the second model is configured to determine a plurality of probabilities associated with the channel profile and the resource allocation set.

18. The method according to claim 1, further comprising the at least one processor generating a control signal causing the renderable object, which includes the index of the resource allocation set, to be displayed on the user interface of the client device.

19. A device for determining the predicted future demand for resources in a dynamic environment, comprising at least one processor and at least one memory containing computer program code, wherein the at least one memory and the computer program code are used by the at least one processor to provide the device, Receiving request data objects from client devices associated with the channel profile, Receiving a hierarchical parameter data object, Receiving the attenuation parameter data object, Extracting a resource request set from the aforementioned request data object, wherein the resource request set includes a plurality of request parameters. Extracting multiple hierarchical parameters from the aforementioned hierarchical parameter data object, Extracting multiple damping parameters from the aforementioned damping parameter data object, Assigning the channel profile to a first hierarchy from among a plurality of hierarchies, wherein the assignment of the channel profile to the first hierarchy includes applying the plurality of hierarchical parameters and the first requirement parameters from the plurality of requirement parameters to a first model. The process involves generating a user-associated, adjusted resource request set by applying a decay curve to a second request parameter from the plurality of request parameters, wherein the decay curve is at least partially based on the plurality of decay parameters. Based on the first hierarchy and the adjusted resource request set, determine whether the channel profile satisfies each of the multiple threshold conditions, In response to determining that the channel profile satisfies each of the plurality of threshold conditions, the adjusted resource request set and the first hierarchy are applied to the second model to generate a resource allocation set for the channel profile. A device configured to generate a control signal that causes a renderable object containing an index of the resource allocation set to be displayed in the user interface.

20. A non-transient computer-readable storage medium having computer executable program code instructions stored internally, wherein the computer executable program code instructions are Receiving request data objects from client devices associated with the channel profile, Receiving a hierarchical parameter data object, Receiving the attenuation parameter data object, Extracting a resource request set from the aforementioned request data object, wherein the resource request set includes a plurality of request parameters. Extracting multiple hierarchical parameters from the aforementioned hierarchical parameter data object, Extracting multiple damping parameters from the aforementioned damping parameter data object, Assigning the channel profile to a first hierarchy from among a plurality of hierarchies, wherein the assignment of the channel profile to the first hierarchy includes applying the plurality of hierarchical parameters and the first requirement parameters from the plurality of requirement parameters to a first model. The process involves generating a user-associated, adjusted resource request set by applying a decay curve to a second request parameter from the plurality of request parameters, wherein the decay curve is at least partially based on the plurality of decay parameters. Based on the first hierarchy and the adjusted resource request set, determine whether the channel profile satisfies each of the multiple threshold conditions, In response to determining that the channel profile satisfies each of the plurality of threshold conditions, the adjusted resource request set and the first hierarchy are applied to the second model to generate a resource allocation set for the channel profile. A non-transient computer-readable storage medium comprising at least one program code instruction configured to generate a control signal for displaying a renderable object containing an index of the resource allocation set on a user interface.

Images