Device and method for prediction and modeling of resource distribution, and generation, adjustment and approval of resource acquisition offer
Patent Information
- Application Number
- JP2024107195
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2018-05-18
- Filing Date
- 2024-07-03
- Publication Date
- 2025-02-06
- Estimated Expiration
- 2039-05-20
AI Technical Summary
Existing systems struggle with inefficient allocation of resources in dynamically changing environments due to rapid fluctuations in resource supply, availability, and value, exacerbated by data editing, analysis, and visualization challenges, leading to delays and inefficiencies in resource acquisition planning.
Implementing machine learning models to predict resource demand and distribution channels, using a processor and memory to receive and process data objects, apply predictive models, and generate resource offer sets optimized for efficient distribution based on contextual information.
Enables timely and efficient allocation of resources by predicting future demand and conditions, reducing obsolescence and waste by directing resources to optimal channels, aligning availability with demand, and optimizing financial and benchmark goals.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
[Technical field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS: This application claims the benefit of U.S. Provisional Patent Application No. 62 / 673,325, filed May 18, 2018, which is incorporated by reference in its entirety as if fully set forth herein.
[0002] Exemplary embodiments relate generally to the use of machine learning predictive models to implement efficient allocation of time-dependent resources. Exemplary implementations are particularly directed to systems, methods, and apparatus for forecasting and modeling future demand for time-dependent, deteriorating objects in resource-constrained environments. Additional or alternative exemplary embodiments relate to improved generation of resource offer sets and / or improved visualization and display of such resource offer sets for analysis, adjustment, and approval. [Background technology]
[0003] Many of today's network environments are dynamically resource constrained, at least in the sense that resource needs and the nature of the resources needed can change rapidly and significantly over time and geography. Summary of the Invention [Problem to be solved by the invention]
[0004] Some of the technical challenges that impede effective and efficient allocation of resources in such environments are exacerbated in situations where the supply, availability, and / or value of needed resources change over time. Additionally, in this regard, resource availability for a particular time and / or geography may vary significantly. Technical challenges in compiling, analyzing, visualizing, and manipulating data associated with conventional systems impede efficient resource availability planning. The inventors of the inventions disclosed herein have identified these and other technical challenges and developed solutions that are described and otherwise referenced herein. [Means for solving the problem]
[0005] Accordingly, apparatus, computer program products, and methods in accordance with example embodiments are provided to enable efficient determination of one or more channels and / or associated conditions over which a particular resource set may be effectively allocated. In this regard, the method, apparatus, and computer program product of the example embodiments provide for the creation of predicted channel and condition data sets that may be stored within renderable objects and otherwise presented to a user via a client device interface.
[0006] Additionally, the method, apparatus, and computer program product of the exemplary embodiments provide for the use of machine learning models in connection with the determination and retrieval of predicted channel and condition data sets determined based at least in part on contextual data associated with a particular resource set to be distributed at a future time.
[0007] In an exemplary embodiment, an apparatus is provided, the apparatus including a processor and a memory, the memory including instructions configuring the apparatus to: receive a request data object from a client device associated with a user; extract a request dataset from the message request data object, the request dataset being associated with a first set of resources; receive a first contextual data object, the first contextual data object being associated with one or more resource distribution channels; retrieve a predicted channel and condition dataset, the retrieval including applying the request dataset and the first contextual data object to a first model; and generate a control signal to cause a renderable object including the predicted channel and condition dataset to be displayed on a 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 including at least one non-transitory computer-readable storage medium having computer-executable program code instructions stored therein, the computer-executable program code instructions including program code configured to: receive a request data object from a client device associated with a user; extract a request dataset from the message request data object, the request dataset being associated with a first set of resources; receive a first contextual data object, the first contextual data object being associated with one or more resource distribution channels; retrieve a predicted channel and condition dataset, where retrieving the predicted channel and condition dataset includes applying the request dataset and the first contextual data object to a first model; and generate a control signal to cause a renderable object including the predicted channel and condition dataset to be displayed on a user interface of the client device associated with the user.
[0009] In another example embodiment, a method for determining predicted future demand for resources in a dynamic environment is provided, the method including receiving a request data object from a client device associated with a user; extracting a request dataset from the message request data object, the request dataset being associated with a first set of resources; receiving a first contextual data object, the first contextual data object being associated with one or more resource distribution channels; retrieving a predicted channel and condition dataset, the retrieving including applying the request dataset and the first contextual data object to a first model; and generating a control signal to cause a renderable object including the predicted channel and condition dataset to be displayed on a user interface of the client device associated with the user. [Brief description of the drawings]
[0010] [Figure 1] 1 illustrates an example system in which some embodiments of the present disclosure may operate. [Diagram 2] 1 illustrates a block diagram of an example device for implementing a prediction system using dedicated circuitry, in accordance with some embodiments of the present disclosure. [Diagram 3] 1 illustrates a block diagram depicting a functional overview of a system according to some embodiments of the present disclosure. [Figure 4] 1 illustrates a dataflow model according to some embodiments of the present disclosure. [Diagram 5] FIG. 1 illustrates a block diagram depicting a functional overview of another aspect of a system according to some embodiments of the present disclosure. [Figure 6] 1 illustrates a flowchart describing example operations for generating resource allocations based on forecast conditions, in accordance with some embodiments of the present disclosure. [Figure 7]1 illustrates a flowchart describing example operations for generating resource allocations based on forecast conditions, in accordance with some embodiments of the present disclosure. [Figure 8] 1 illustrates another example system in which some embodiments of the present disclosure may operate. [Figure 9] 1 illustrates a block diagram of an example apparatus for implementing a resource offer generation system using special-purpose circuitry, in accordance with some embodiments of the present disclosure. [Figure 10] 1 illustrates a data flow diagram depicting steps for generating an optimal resource offer set via a resource offer generation system according to some embodiments of the present disclosure. [Figure 11] FIG. 1 illustrates a data flow diagram depicting steps for rendering and / or adjusting a resource offer set, submitting the adjusted resource offer set for approval, and approving or rejecting the adjusted resource offer set, in accordance with some embodiments of the present disclosure. [Figure 12A] 1 illustrates a flowchart depicting operational blocks in an example process for generating a resource offer set, updating a resource offer set to create an adjusted resource offer set, and receiving an offer status indicator for the adjusted resource offer set, in accordance with an example embodiment of the present disclosure. [Figure 12B] 1 illustrates a flowchart depicting operational blocks in an exemplary process for generating a trusted resource characteristic data set from one or more untrusted third party resource characteristic data sets and a distributed resource characteristic set according to an exemplary embodiment of the present disclosure. [Figure 13] 1 illustrates an example analytics interface, specifically an offer adjustment interface, accessible via a dashboard, according to an example embodiment of the present disclosure. [Figure 14] 1 illustrates another example analytics interface accessible via a dashboard, specifically an offer acceptance interface, according to an example embodiment of the present disclosure. [Figure 15] 1 illustrates another example analytical interface, specifically a market comparison interface, accessible via a dashboard, according to an example embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] Having thus described in general terms certain embodiments of the present disclosure, reference is now made to the accompanying drawings, which are not necessarily drawn to scale. Certain embodiments of the present disclosure will now be described in more detail herein with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, various embodiments of the present invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein, but rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numbers refer to like elements throughout. Overview Various embodiments of the present disclosure are directed to improved apparatus, methods, and computer-readable media for forecasting and determining optimized allocation of resources in an environment where the demand, availability, utility, and / or value of resources are dynamic. By modeling and forecasting resource requirements, exemplary implementations of embodiments of the present invention can more quickly and efficiently direct resources (which may be subject to depreciation, impairment, and / or other dynamic changes in utility or value) to channels where such resources can be optimally deployed. One environment recognized by the inventors where the demand, availability, utility, and value of resources are each dynamic is a market environment involving the acquisition and resale of used mobile devices. In such an environment, the demand for a particular mobile device can vary over time and vary significantly by region, which may result in higher demand in one location at a given time compared to another location at the same time or the same location at a different time. Moreover, in such an environment, the supply of a given mobile device may vary based on a number of factors, while user requirements (such as for desired functionality of a mobile device) and the perceived value of a particular mobile device may each vary independently over time. In particular, because the value of a particular mobile device tends to decrease over time, delays in the allocation of a particular mobile device to a particular distribution channel tend to increase the likelihood that a used mobile device will become obsolete due to obsolescence, lack of perceived value, and / or other factors.
[0012] The inventors of the embodiments of the present disclosure herein have recognized that one of the key factors in efficiently satisfying the demand for a particular mobile device in a secondary 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, the decision to deploy resources in a particular channel tends to end up satisfying the needs and demands of users. Furthermore, under reactive approaches, delays are often inserted in the process of acquiring potentially desirable devices and directing them to users looking for such devices. Particularly in situations where devices tend to become obsolete and depreciate in value over time, delayed allocation of devices may result in the uselessness of devices that were directed to a particular channel based on past conditions at the time the resources were introduced to a given channel (e.g., used mobile devices in this environment), resulting in a loss of relevance to existing market conditions and a decrease in the value that can 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 demand and perceived device value are exacerbated by a wide range of information vanishing factors. In the case of mobile devices, one of the vanishing factors includes the wide range of similar, but potentially non-identical, devices in the market. For example, many mobile device manufacturers give mobile devices different identification numbers or other indicators based on the mobile network, retailer, cosmetic features, market, and / or other aspects associated with the initial sale of the mobile device. For example, an identification number used to identify a mobile device originally sold from a retailer associated with one mobile network provider may be different from an identification number for a mobile device originally destined for a retailer associated with another mobile network provider, despite the fact that the two devices may have the same features and function comparably across a wide range of networks. In some environments, the number of device identifiers may number in the tens or hundreds of thousands.
[0014] Information that may be used to predict and model user demand and perceived device value may be further diminished by the large amount of unscaled and / or non-uniform data associated with each device and / or device identification number. For example, a predictive model that accurately and reliably identifies the channel to which a particular mobile device should be directed to meet user demand at a given time may use a range of publicly and privately available datasets, including, but not limited to, resource appropriation data, seasonality information, sales information (e.g., in business-to-business and / or business-to-customer contexts), mobile device attribute information, market data, device billing data (e.g., information regarding insurance claims, warranties, and / or other repairs, etc.), other macroeconomic indicators, stock information, and / or social media data. Because many of these datasets are mutually independent, relevant components of such datasets may need to be extracted, normalized, scaled, and / or otherwise adjusted to allow such information to be used in a predictive model.
[0015] In addition to the technical challenges posed by the volume, complexity, and variability of the multiple data sets used in connection with predictive models, the inventors of the inventions described herein have also recognized the technical challenges posed by the conditions of a given environment (the capacity of any given channel to effectively accept and distribute resources, existing resources available for distribution, actions of external actors, etc.) and with the rate at which such conditions change within the technological environment. In particular, the inventors have recognized that the delays inherent in reactive systems often result in inefficiencies and futility associated with resource allocations that are inconsistent with changing and / or shifting conditions in a given environment.
[0016] To address these and other technical challenges associated with allocating dynamically variable resources under rapidly changing environmental conditions, a user associated with a request for allocation of resources to channels in which such resources can be efficiently distributed may be able to interact with a resource allocation prediction system that uses predictive machine learning models. Using machine learning models, the system may identify, generate, and / or otherwise provide resource allocation guidance based on contextual information associated with the environment in which the resources are distributed. In a context involving the distribution of used mobile devices in a market environment, the system may utilize a wide range of information sources that can be fed into the machine learning models to enable forecasting and modeling of market conditions to identify channels to which a particular amount and type of devices should be allocated at a given time. Furthermore, by applying the decay curves and other aspects of the predictive models, changes in market conditions, resource demand, and other related factors may be predicted, allowing for resource allocation that is more time-aligned with conditions at a given time than is available from traditional reactive approaches.
[0017] For example, in the context of distributing an existing inventory of used mobile devices in an efficient manner, the system may access and process datasets that provide context and / or other information regarding one or more mobile devices and / or the channel 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 claims data associated with one or more mobile device models, device usage and device status data that may be obtained via 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 affect conditions within a given environment. For example, data indicative of seasonal and / or other time-based factors, macroeconomic conditions, social media data, and / or other information (e.g., manufacturer actions, plans, and / or statements, etc.) may be used in addition to and / or apart from any of the above categories. The system may also access and process other sources of information, including, but not limited to, feedback information generated by the system, decay curve information, training data for use in conjunction with machine learning models, etc. As a result, by using available data, information produced using the models, and data describing aspects of the mobile devices and / or environment, one or more channels for distribution of resources (e.g., used mobile devices, etc.) can be identified and selected based on predicted conditions, which in turn allows for the direction of resources in a manner that allows such resources to efficiently reach a given channel when needed and / or when otherwise available for disposal via the channel.
[0018] To overcome these and other technical challenges, exemplary implementations of embodiments of the invention described herein use automated tools to obtain and scale a diverse set of information regarding channels (e.g., aggregators, etc.) through which mobile devices and / or other resources may be distributed. Using the scaled information, groups of aggregators and / or other channels may be assigned to tiers that generally reflect the ability of the aggregators and / or other channels to effectively distribute associated resources. To effectively predict pricing information and otherwise address time-dependent and / or aged data, decay functions are modeled and otherwise applied to pricing data received from aggregators and / or other available channels (e.g., distribution channels through which mobile devices may be sold directly, etc.). This combination of tiering and data decay allows for the identification and ranking of aggregators and / or other channels that are likely to be able to distribute a particular amount of unique devices at a predicted price at a future time. Thus, resources may be directed to the appropriate channels at the right time to take advantage of the optimal pricing and / or distribution opportunities available when resources are available for distribution. In situations where inventory is obtained through the secondary market (e.g., buyback programs, etc.), pricing and associated terms can be calculated for a particular device and / or set of devices, taking into account available distribution channels and anticipated selling prices.
[0019] Many of the example 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, buy-back programs, trade-in programs, and the like. In some such situations, the availability of distribution channels, the viability of such channels, the 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 receipt 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 aligns in time with the availability and demand for devices. Thus, for clarity, some of the example implementations described herein may use terminology, background facts, and details associated with the acquisition and distribution of devices and may 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 example implementations thereof may be applicable and advantageous in a wide range of contexts and situations other than those related to event preparation and planning.
[0020] The embodiments of the present disclosure are further directed to computer-implemented methods, apparatus, systems, and computer program products for improved generation of resource offer sets, analysis and / or adjustment of the generated resource offer sets, and / or approval of the resource offer sets. More specifically, a predicted optimal resource offer set may be modeled using a resource offer generation model. A variety of heterogeneous unstructured data sets (e.g., resource price characteristics offered by third party entities such as vendors and competitors, price characteristics offered by resource owners, resource inventory data, social media data related to resources, seasonality data, resource launch data, etc.) may be retrieved from one or more heterogeneous data sources, warehouses, data stores, etc. The unstructured data sets may be cleaned, normalized, transformed, and otherwise synthesized for application to the resource offer generation model. By modeling optimal resource offers based on various data sources, an exemplary implementation of an embodiment of the present disclosure may rapidly provide one or more resource offer sets for resource acquisition and subsequent distribution (which may be time-dependent or may require careful tuning to be effective to ensure sufficient interest from resource owners). Specifically, for example, in a used mobile device acquisition and distribution environment, resource offer data objects associated with a used mobile device purchase must be appropriately adjusted to set corresponding price characteristics or resource offer values such that device owners are likely to take advantage of the offers while ensuring that financial and / or benchmark objectives (profitability, margins, desired device acquisition distribution, etc.) are met with respect to the acquisition and anticipated distribution of the used mobile device associated with the generated resource offer set (e.g., individual device owners may conduct trade-ins via one or more device acquisition channels, such as a carrier).
[0021] The acquisition and / or distribution of resources, including used mobile devices, may be dynamic and vary significantly across regions and / or across regions or within a single region over time. For each region (e.g., a country, city, or other defined geographic area) and collection period (e.g., a time interval during which offers defined by resource offer data objects may be actively provided to that region), used mobile devices may be optimally associated with a particular resource offer data object in the generated resource offer set. For example, each resource may be mapped to a particular resource offer data object representing a corresponding offer provided for acquisition of the resource, as described herein.
[0022] Resources may 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 a resource offer data object associated with a particular resource set identifier may vary by time and / or region, such that a mobile device having a particular attribute may be optimally associated with a first offer value at a first time and a second offer value at a second time, or may be optimally associated with a first offer value for a first region and a second offer value for a second region. Offer values may also vary depending on various resource attributes associated with the resource. For example, for a given mobile device, the capabilities of the mobile device may, among other things, change the ideal resource offer value of a resource offer data object associated with the resource. In an example environment, a resource, such as a mobile device that is only partially functional, may be associated with a lower offer value than a functional mobile device. It may be difficult to determine the difference in resource offer values between two resources with different functionality.
[0023] The inventors of the embodiments of the present disclosure have recognized that to provide an optimal resource offer data object for a particular resource (e.g., associated with a particular resource set identifier), the offer data object may be modeled and predicted based on various data sets including various types of data. Conventional approaches do not accurately consider resource distribution allocation channels and expected distribution time frames, promotion 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 thus providing an offer defined by the resource offer data object is more likely to fail to obtain a desired volume of resources for distribution via various channels.
[0024] To address these and other technical challenges, a user (e.g., an offer control user) associated with a request to generate a resource offer may interact with a resource offer generation system that employs one or more predictive machine learning models. Through the use of the machine learning models, the system may generate a resource offer set that includes resource offer data objects for various resources associated with various resource set identifiers. The system may further optimize the provided resource offer set based on desired benchmarking and / or targets, such as financial and / or business parameters or goals, provided via benchmark and portfolio goal datasets. The machine learning models may improve the generated resource offers to achieve the desired financial and / or benchmark goals based on output by the predictive models. The machine learning models may utilize other market information dataset(s) retrieved and synthesized for various mobile devices with various attributes and characteristics, as described above, and offered by various third party entities (e.g., competitors, business-to-consumer entities, etc.). The resource offer generation system may similarly access extracted, normalized, scaled, and / or otherwise adjusted information that was previously unavailable due to data loss.
[0025] The inventors of the embodiments of the present disclosure herein further recognize that the technical problem has been presented to provide a resource data object set for analyzing, and, if desired, efficiently and effectively adjusting, the resource offer data objects, e.g., to adjust corresponding resource offer value(s) to achieve new desired financial or benchmark objectives. A system user, e.g., an offer control user, may wish to analyze the generated resource offer set to gauge the relative strength of the resource offer set, e.g., 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 the resource owner) is sufficient, and to determine that the resource offer set will meet the desired financial and benchmark objectives, based on collected and normalized market information, to visualize the effect of the adjustment on the strength of the resource offer set and / or on reaching the benchmark and / or portfolio objectives. Based on the analysis, the system user may wish to adjust one or more of the resource offer data objects in the resource offer set, such as to increase the overall offer strength or improve the benchmark or portfolio objective metric (e.g., profitability).
[0026] In this regard, the embodiments provide an advantageous interface for viewing, analyzing, adjusting, and / or approving resource offer sets. A user may access the offer adjustment interface via embodiments of the present disclosure. The offer adjustment interface may be configured to allow a system user to view and analyze resource offer sets. The offer adjustment interface may be further configured to allow a system user to view and analyze additional information derived from or associated with the resource offer set. For example, the offer adjustment interface may include a dashboard for accessing various interfaces used in analyzing the resource offer set. Additionally, the offer adjustment interface may include an indicator of an offer analysis dataset showing financial metrics of the generated resource offer set and updated to reflect the current adjusted resource offer set as adjustments are made via this interface.
[0027] Additionally, a system user, such as an offer control user, may adjust resource offers via an offer adjustment interface. Such adjustments may be performed to achieve new financial and / or benchmark objectives. As a user adjusts one or more resource offer data objects, the dashboard interface and / or the offer analysis data set associated with the resource offers are dynamically updated by the system to reflect calculations based on the adjusted resource offer set. Such an embodiment provides a technical advantage in visualizing changes to potential resource offers and their impact on offer strength and / or financial and / or benchmark objectives.
[0028] The submitted adjusted resource offer set may be subject to approval by another user, such as an offer approval user. The system of an embodiment may facilitate an improved approval process by providing an improved offer approval interface. Through the offer approval interface, the offer approval user may effectively analyze the adjusted resource offer set submitted by the offer control user. The offer approval interface may include a dashboard, such as a dashboard rendered in association with the offer adjustment interface, to enable efficient and thorough analysis using a particular streamlined interface. definition As used herein, "data," "content," "information," and similar terms may be used interchangeably to refer to data that may be transmitted, received, and / or stored in accordance with embodiments of the present disclosure. Thus, the use of such terms should not be taken to limit the spirit and scope of the embodiments of the present disclosure. Furthermore, where a computing device is described herein as receiving 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, for example, one or more servers, relays, routers, network access points, base stations, hosts, etc., sometimes 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, for example, one or more servers, relays, routers, network access points, base stations, hosts, etc.
[0029] As used herein, the term "circuitry" refers to (a) hardware-only circuit implementations (e.g., implementations with analog and / or digital circuitry), (b) a combination of circuitry and computer program product(s) including software and / or firmware instructions stored in one or more computer-readable memories that cooperate to cause an apparatus to perform one or more functions described herein, and (c) circuitry, such as, for example, a microprocessor(s) or a portion of a microprocessor(s) that requires software or firmware for operation even when the software or firmware is not physically present. This definition of "circuitry" applies to all uses of the term herein, including the claims. As a further example, the term "circuitry" as used herein also includes implementations that include one or more processors and / or portion(s) thereof, and associated software and / or firmware. As another example, the term "circuitry" as used herein also includes, for example, baseband or application processor integrated circuits for mobile phones, or similar integrated circuits in servers, cellular network devices, other network devices, and / or other computing devices.
[0030] As used herein, "computer-readable storage medium" which refers to physical storage media (e.g., volatile or non-volatile memory devices) may be distinguished from "computer-readable transmission medium" which refers to electromagnetic signals.
[0031] As used herein, the terms "user," "client," and / or "request source" refer to an individual or entity that is the source of and / or is associated with a request for identification of one or more channels for use in distributing resources and / or associated content provided by a predictive control system and / or any other system capable of predicting and / or modeling likely conditions of an environment in which the associated resources may be distributed via one or more known channels. For example, a user and / or client may be an owner and / or entity seeking information regarding the optimal channel or channels for distributing a particular inventory of used mobile devices and / or the likely conditions under which a particular inventory of used mobile devices may 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) located on another computer system, in which case the client device accesses the services over a network. Client devices may include, but are not limited to, smartphones, tablet computers, laptop computers, wearables, personal computers, enterprise computers, and the like. As described herein, client devices communicate with and access the prediction system and / or resource offer generation system over one or more networks.
[0033] The term "offer control user" refers to a particular user of the resource offer generation system 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, view for analysis, via the resource offer generation system, resource offer data sets for particular regional program identifiers and collection period data objects, adjust resource offer data for particular regional program identifiers and collection period data objects via an offer adjustment interface, and / or submit resource offer sets or adjusted resource offer sets for approval. An offer control user is associated with a corresponding user account, in some embodiments, authorized to access the resource offer generation system to perform the described actions. The offer control user may authenticate user credentials associated with the user account to initiate an authenticated session and perform the described actions via the resource offer generation system.
[0034] The term "color neutral name" or "CNN" refers to a system-standardized resource identifier that identifies a resource associated with a unique resource attribute. A CNN may be mapped to one or more third-party resource identifiers, for example, maintained by a third-party database and / or device. The term "resource attribute" refers to a device specification, characteristic, or identification information associated with a particular resource. Resources can be categorized by their resource attributes, such that resources having the same resource attributes can be grouped and identified by combinations of resource attributes. For example, in the context of distribution of mobile devices as resources, a mobile device resource may be associated with a manufacturing identifier, a model identifier, a storage size identifier, and / or a carrier identifier. In some embodiments, a resource attribute may include similar information associated with the resource specifications. A corresponding CNN may be associated with multiple country, region, or third-party specific identifiers used to characterize resources of the same device.
[0035] The term "resource set identifier" refers to a unique string, number, or other form of identification 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 a SKU. In other embodiments, the resource set identifier is one or more resource attributes or several resource attributes combined.
[0036] The term "digital content item" refers to any electronic media content item that is intended to be consumed in either electronic form or printed output and that 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 digital content items include images, audio files, video files, text files, etc.
[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 data sets associated with a request by a user to identify one or more channels and / or conditions of one or more channels that may be distributed via a resource (such as a mobile device). A "channel context data object" is a data object that includes one or more data sets that provide, alone or in combination with other data sets, information regarding the channel and / or the environment in which one or more channels may operate such that the behavior 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, embedded, and / or otherwise structured as a data object. A "context dataset" is a dataset that includes information about a channel and / or an environment in which one or more channels may operate. A "predicted condition dataset" is a dataset that encompasses one or more indicators of relevant conditions in which a channel and / or resource (e.g., mobile device, etc.) 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 particular channel profile for the distribution and / or acquisition of resources via the third party entity.
[0040] The term "regional program data object" refers to an electronically managed structured arrangement of data associated with a particular offering associated with the acquisition of resources for a particular region. Each regional program data object may be associated with a particular program for acquiring a set of resources based on an associated approved resource offer set. 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 a collection period data object such that the resource offer set can be accepted as valid for association with a regional program data object only during the time interval represented by the collection period data object. For example, a particular resource offer set can be associated with a particular program in a particular country for the two week time interval represented by a particular collection period data object.
[0042] The term "data collection parameters" refers to one or more parameters associated with the acquisition of resources associated with a particular regional program data object. Data collection parameters include business, portfolio level, and resource acquisition goal parameters associated with the acquisition of resources associated with a regional program data object. Non-limiting examples of data collection parameters include distribution channel mix rates, activity costs, resource volume multipliers, promotional resource lists, commissions associated with resource offer data objects, offer ratios of functional and non-functional resources, desired profits per device, desired volume percentages by grade, time-based resource condition multipliers, and minimum resource offer values for functional and / or non-functional resources. A regional program data object may include or be associated with a "data collection parameter set" that includes one or more data collection parameter(s) for that regional program data object.
[0043] The term "benchmark and portfolio target datasets" refers to a collection of data representing or associated with a target metric for the distribution and / or procurement of resources. In some embodiments, the benchmark and portfolio target datasets represent a subset of the data collection parameters. In some embodiments, the benchmark and portfolio target datasets are associated with a regional program data object. In some embodiments, the benchmark and portfolio target datasets define boundary conditions entered by an offer control user or an offer approval user such that a generated and / or submitted resource offer set must satisfy the boundary conditions defined by the benchmark and portfolio target datasets. For example, in some embodiments, the benchmark and portfolio target datasets include at least a minimum expected profitability based on the resource offer set or a minimum expected margin based on the resource offer set. In some embodiments, the benchmark and portfolio target datasets include a target time interval for the distribution or acquisition of some resources.
[0044] The term "resource offer data object" refers to an electronically managed structured arrangement of data that includes at least a resource offer value for a particular resource set identifier. A resource offer data object may include a resource set identifier with which a resource offer value is associated. A resource offer data object is adjustable by a user, such as an offer control user, that changes 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 in a resource offer set may be associated with a different resource set identifier.
[0046] The term "adjustment 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 object(s). In some embodiments, an adjustment data object includes adjusted resource offer values of one or more resource offer data objects. One or more adjustment data objects may 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 to one or more resource offer data objects by an offer control user. In some embodiments, the adjusted resource offer set is created by updating the resource offer set based on one or more adjustment data objects. The 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 a collection period data object is embodied by the adjusted resource offer set, for example, after one or more adjustments have been performed 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 collection parameter data objects. In some embodiments, the offer status record is stored in an offer approval repository, which may be a sub-repository managed by the resource offer generation system. The offer status record is associated with, retrievable based on, or utilizing the regional program identifiers and collection parameter data objects. In some embodiments, the offer status record includes at least an offer status indicator. In some embodiments, the offer status record is associated with or otherwise linked to the resource offer set.
[0049] The term "offer status indicator" refers to data or information that indicates a processing status for the generation, adjustment, and approval of a resource offer set associated with a particular regional program data object and collection period data object. In some embodiments, the offer status indicator is represented by one of a number of possible status indicators. An exemplary offer status indicator is a "request status indicator," which indicates that a resource offer generation process has been requested for the corresponding regional program identifier and collection period data object, but a 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 object, but has not yet been submitted by an offer control user for approval. In some embodiments, another exemplary offer status indicator is a "pending approval status indicator," which indicates that an adjusted resource offer set has been submitted by an 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 an offer-rejecting user.
[0050] In some embodiments, the offer status indicator is stored in or associated with an offer status record corresponding to the regional program identifier and collection period data object. The offer status record may be stored in an offer acceptance repository. In some embodiments, the offer status record also 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 another repository or sub-repository.
[0051] The term "envisioned resource volume data set" refers to a collection of data associated with the distribution of resources associated with a particular resource set identifier to an envisioned channel. In some embodiments, the envisioned resource volume set data is output by or parsed from the output of a prediction system. In some embodiments, for example, the envisioned resource volume data set includes or is derived from at least one resource allocation set generated by the prediction system associated with at least one channel profile. In some embodiments, the envisioned resource volume data set is generated by another system associated with the prediction system.
[0052] The term "average distribution request amount dataset" refers to a collection of data associated with parameters associated with the distribution of resources identified by the expected resource quantity dataset. In some embodiments, the average distribution request amount dataset includes at least an average selling price at which the resources are predicted to be distributed. In some embodiments, the average distribution request amount dataset is output by or parsed from the output of a forecasting system.
[0053] The term "market intelligence dataset" refers to a 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 regarding the acquisition of resources associated with one or more channels, sentiment information associated with the resources, launch information associated with the resources, and the perceived value of the resources for distribution and / or acquisition. A market intelligence dataset, or portions thereof, may be retrieved from one or more third party systems, scraped from various data sources (e.g., web scraping), or received from a third party system (e.g., data that is updated periodically). In some embodiments, a market intelligence dataset includes one or more subsets, each associated with a particular resource set identifier, such as a CNN. In some embodiments, the market intelligence dataset includes, for one or more particular resource set identifiers, distributed user platform pricing for the particular resource set identifier (e.g., average selling price for the particular resource set identifier via one or more distributed user platforms, such as eBay™ or similar channels), other third party offer values for the particular resource set identifier, social media sentiment for the particular resource set identifier, seasonality information, launch information associated with the particular 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 particular resource in an untrusted third party resource characteristic dataset is not within an expected operating range. In some embodiments, the expected operating range is embodied by an expected deviation of an offset between the untrusted third party resource characteristic dataset and the distributed resource characteristic dataset. In some embodiments, the exception period begins at a first timestamp at which the deviation of the offset for the value of the particular resource characteristic meets an exception deviation threshold and ends at a second timestamp at which the deviation of the offset for the value of the particular resource characteristic does not meet the exception deviation threshold. In some embodiments, the exception period for a particular untrusted third party resource characteristic dataset includes one or more records of the untrusted third party resource characteristic dataset associated with timestamps that are within the exception period.
[0055] The term "exception deviation threshold" refers to a normal operating range of deviations of offsets between resource characteristics of an unreliable resource characteristic data set and resource characteristics of a distributed resource characteristic data set for a particular resource set identifier. In some embodiments, an exception period is indicated when the deviations of offsets meet the exception deviation threshold by exceeding the exception deviation threshold.
[0056] The term "exception detection model" refers to one or more machine learning, algorithmic, and / or statistical models, or combinations thereof, for generating a trusted resource characteristic dataset based on one or more untrusted third-party resource characteristic dataset(s) applied to the model and a distributed resource characteristic dataset applied to the model. In some embodiments, the exception detection model is configured to identify an exception period set for the applied untrusted third-party resource characteristic set based on a deviation of an offset with respect to the distributed resource characteristic dataset, remove the exception period set creating an updated untrusted third-party resource characteristic dataset, and generate a trusted resource characteristic dataset based on at least the updated untrusted third-party resource characteristic dataset. In some embodiments, the exception detection model is configured to generate a trusted resource characteristic dataset based on a comparison between two or more updated untrusted third-party resource characteristic datasets associated with different third-party entities.
[0057] The term "resource characteristic" refers to a particular attribute associated with a resource. One or more resource characteristics of a resource associated with a particular resource set identifier are represented in a record of a data set associated with the resource set identifier. For example, the terms "price characteristic" and "pricing characteristic" refer to an offer value for the acquisition or distribution of a resource associated with the corresponding resource set identifier.
[0058] The term "untrusted third party resource characteristic dataset" refers to a collection of one or more resource characteristics associated with a particular third party entity, which may include one or more resource characteristics associated with an exception period. The untrusted third party resource characteristic dataset described herein is updated based on a comparison with a dissemination resource characteristic dataset. In some embodiments, the untrusted third party resource characteristic dataset includes at least a price characteristic for a particular resource, such as a used mobile device.
[0059] The term "third-party resource pricing dataset" refers to a particular historical dataset representing a resource characteristic dataset of an untrusted third party 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 that are reflected as records in the third-party resource pricing dataset. In some embodiments, the third-party resource pricing dataset is included in a market intelligence dataset.
[0060] The term "distributed user platform" refers to a marketplace or other platform configured to enable individual users to generate offers for the purpose of acquiring and / or distributing resources. In some embodiments, the 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 a price characteristic for a particular resource set identifier. The distributed user platform is associated with a corresponding third party entity that controls the distributed user platform.
[0061] The term "distributed resource pricing data set" refers to a particular historical data set that includes at least price characteristics for one or more resources or resource set identifiers. In some embodiments, a distributed resource pricing data set is associated with user-generated offers for resource acquisition available for one or more resources or resource set identifiers via a distributed user platform.
[0062] The term "alignment" refers to the organization and / or sorting of one or more data sets based on one or more characteristics of each record. The term "temporal alignment" refers to a particular organization of one or more data sets based on associated timestamp characteristics. The term "resource set identifier alignment" refers to a particular organization of one or more data sets 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, the 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 in association with various resource set identifiers determined based on the regional program identifier and 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, a data object, a set of data, or a portion of any of the above to a particular user interface. Examples of indicia include, but are not limited to, text indicia, graphic indicia, chart indicia, image indicia, and encoded indicia. It should be understood that an indicia may cause a user interface to display and / or render a visual presentation of data, a data object, a set of data, or a portion of any of the above. Example System Environment Turning now to the drawings, FIG. 1 illustrates an exemplary system environment 100 in which implementations involving efficient prediction and modeling of conditions and channels under which resources may be distributed may be implemented. The depiction of the environment 100 is not intended to limit or otherwise restrict the embodiments described and contemplated herein to any particular configuration of elements or systems, nor is it intended to exclude any alternative configurations or systems of the set of configurations and systems that may be used in connection with embodiments of the present disclosure. Rather, FIG. 1 and the environment 100 disclosed therein are presented merely to provide an exemplary basis and context for facilitating some of the features, aspects, and uses of the methods, apparatus, and computer program products disclosed and contemplated herein. While many of the aspects and components presented in FIG. 1 are shown as discrete, separate elements, it will be understood that other configurations, including configurations that combine, omit, and / or add aspects and / or components, may be used in connection with the methods, apparatus, and computer programs described herein.
[0065] An embodiment implemented in a system environment such as system environment 100 advantageously provides efficient prediction and modeling of conditions and channels over which resources 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, etc.) for presentation 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 that cause renderable objects associated with the predicted condition dataset to be displayed in a user interface of a client device associated with the user. Some such implementations contemplate the use of channel context data objects and / or other datasets associated with a distribution channel, and / or mobile devices or other resources that are 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 over which resources may be distributed and response message generation actions as described, contemplated, and / or otherwise disclosed herein.
[0066] 1, the prediction system 102 includes an online prediction system module 102A configured to receive, process, convert, transmit, communicate with, and evaluate request data objects, channel context data objects, content and other information associated with such data objects, and related interfaces via web servers, such as a prediction system server 102B and / or a prediction system device 102D. The prediction system server 102B and / or the prediction system device 102D are connected to any of a number of public and / or private networks, including, but not limited to, the Internet, the public telephone network, and / or networks associated with particular communication systems or protocols, and may include at least one memory for storing at least application and communication programs.
[0067] It will be appreciated that all of the components illustrated in Figure 1 may be configured to communicate over any wired or wireless communication network, including interfaces with wired or wireless local area networks (LANs), personal area networks (PANs), metropolitan area networks (MANs), wide area networks (WANs), etc., as well as the associated hardware, software, and / or firmware necessary to implement the above networks (e.g., network routers, network switches, etc.) For example, networks such as cellular, 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 combinations thereof, and currently available or later developed networking protocols, including, but not limited to, TCP / IP-based networking protocols, may be used in connection with system environment 100 and embodiments of the present invention that may be implemented therein or involved therein.
[0068] 1, the prediction system 102 also includes a prediction database 102C that may be used to store information associated with the requested data objects, users, resources (e.g., used mobile devices, etc.), and / or other information related to efficient prediction and modeling of the requested data objects, channel context data objects, channels associated with other data sets, interfaces associated with such data objects or data sets, request source systems, channel content systems, and / or conditions and channels over which resources may be distributed, and the generation of one or more related sets of messages and / or digital content items. The prediction database 102C may be accessed by the prediction system module 102A, the prediction system server 102B, and / or the prediction system device 102D, and may be used to store any additional information accessed by and / or otherwise associated with the prediction system 102 and / or components of the prediction system 102. Although FIG. 1 depicts the prediction system database 102C as a single structure, it will be understood that the prediction system database 102C may additionally or alternatively be implemented in a distributed manner and / or to enable storage at facilities that are physically remote from one another 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, a desktop computer, or a mobile device, for example, to provide additional means for interfacing (other than via the user interface of the prediction system server 102B) with other components of the prediction system 102 and / or other components shown in or otherwise contemplated by the system environment 100.
[0070] The request data object, the 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. A user of the request source system 104 may use a request source device 104B, such as, for example, a laptop computer, desktop computer, or mobile device, to interface with the request source module 104A to create, generate, and / or communicate the request data object and / or information to include in the request data object, such as identification information for one or more resources (e.g., information of a mobile device identification information, inventory information, timing information, and / or other request parameters, etc.). The request source system 104 may transmit the request data object to the prediction system 102 (e.g., via operation of the request source module 104A and / or the request source device 104B). For the sake of clarity, only one request source system 104 is depicted in FIG. 1, but it will be appreciated that many other such systems may be present in the system environment 100, enabling a multitude of users and / or other request sources to create and transmit information associated with request objects and / or request data objects to the prediction system 102.
[0071] As shown in FIG. 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. Although only one content system 106 is depicted in FIG. 1 for the sake of clarity, it will be understood that numerous additional such systems may be present in the system environment 100 that enable numerous sources of channel context content and / or other information relevant to efficient prediction and modeling of the conditions and channels through which resources may be distributed to communicate with and / or otherwise interact with the prediction system 102 and / or one or more request source systems 104. As shown in FIG. 1, the content system 106 may communicate with the prediction system 102 to provide information that the prediction system 102 may require when predicting and modeling the conditions and channels through which resources may be distributed. For example, content system 106 may obtain and provide information associated with one or more mobile devices, distribution channels, mobile device data, disposition information, market information, macroeconomic data, and / or other data related to the devices or channels, such as through the capabilities and / or actions of content module 106A, content system server 106B, and / or content system 106C, for example.
[0072] The content systems 106 are also shown as being optionally in communication with the request source systems 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 systems 104 in general, and the request source devices 104B in particular, to capture and / or process such content.
[0073] Overall, as depicted in system environment 100, the prediction system 102 engages in machine-to-machine communication with request source systems 104 and contextual content systems 106 over one or more networks to facilitate processing requested data objects received from users, efficiently predicting and modeling the conditions and channels over which resources may be distributed, retrieving and / or generating sets of digital content items and / or other data sets based at least in part on the requested data objects, and generating and / or transmitting control signals that cause renderable objects associated with the predicted channels and / or conditions to be displayed in a user interface of a client device associated with the user. Exemplary Apparatus for Implementing Improved Channel Prediction and Modeling - Patent application It will be appreciated 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, a 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 the exemplary embodiment includes or is otherwise configured to communicate with a processor 202 and a memory device 204, and optionally input / output circuitry 206 and / or communication circuitry 208. In some embodiments, the processor (and / or a 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-transitory 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) that includes gates configured to store data (e.g., bits) that may be retrievable 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. for enabling the device to perform various functions according to 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 mentioned 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., chips) that include materials, components, and / or wires on a structural assembly (e.g., baseboard). The structural assembly may provide physical strength, size conservation, and / or electrical interaction limitations for the component circuitry contained therein. Thus, the apparatus may be configured to implement embodiments of the present disclosure, in some cases, on a single chip or as a single "system-on-chip." Thus, in some cases, the chip or chipset may constitute the means for performing one or more operations to provide the functionality described herein.
[0076] The processor 202 may be embodied in a number of different ways. For example, the processor may be embodied as one or more of a variety of hardware processing means, such as a co-processor, a microprocessor, a controller, a digital signal processor (DSP), a processing element with or without an associated DSP, or various other processing circuitry including integrated circuits, such as, for example, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), a microcontroller unit (MCU), a hardware accelerator, a dedicated computer chip, and the like. Thus, in some embodiments, the processor may include one or more processing cores configured to execute independently. A multi-core processor may enable multi-processing 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 multiple threads.
[0077] In an exemplary embodiment, the processor 202 may be configured to execute instructions stored in the memory device 204 or otherwise accessible to the processor. Additionally or alternatively, the processor may be configured to execute hard-coded functionality. Thus, whether configured by hardware or software methods or a combination thereof, the processor may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to embodiments of the present disclosure, while being configured accordingly. Thus, for example, if the processor is embodied as an ASIC, FPGA, etc., the processor may be hardware that is 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 uniquely 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 unique 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 by instructions to perform the algorithms and / or operations described herein. A 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 input / output circuitry 206, such as a user interface, which may be in communication with the processor 202 to provide output to a user and, in some embodiments, receive an indication of a user input. Thus, the user interface may include a display, and in some embodiments may also include a keyboard, a mouse, a joystick, a touch screen, a touch area, soft keys, a microphone, a speaker, or other input / output mechanisms. Alternatively or additionally, the processor may include user interface circuitry configured to control at least some functionality of one or more user interface elements, such as the display, and, in some embodiments, a speaker, a ringer, a microphone, etc. The processor and / or user interface circuitry 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 a processor-accessible memory (e.g., memory device 204, etc.).
[0079] The device 200 may also optionally include communications circuitry 208. The communications circuitry 208 may be any means, such as a device or circuitry embodied in either 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 communications interface may include an antenna (or multiple antennas) and supporting hardware or software for enabling communication with a wireless communications network. Additionally or alternatively, the communications interface may include circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or for processing reception of signals received via the antenna(s). In some environments, the communications interface may alternatively or additionally support wired communications. Thus, for example, the communications interface may include a communications modem and / or other hardware / software for supporting communications via cable, digital subscriber line (DSL), universal serial bus (USB), or other mechanisms.
[0080] As shown in FIG. 2, the device may also include prediction circuitry 210. The prediction circuitry 210 includes hardware configured to maintain, manage, and provide access to prediction models and / or information used by the prediction models to predict and model the conditions and channels through which resources may be distributed. The prediction circuitry 210 may provide an interface, such as an application programming interface (API), that allows other components of the system to obtain 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, etc.) may be efficiently distributed. For example, the prediction circuitry 210 may facilitate access to and / or processing of information regarding a particular inventory, its characteristics, associated market environment, and / or other information that may be used to predict and model the conditions and channels through which resources may be distributed, including, but not limited to, any of the information obtainable from the content system 106 and / or that may be otherwise associated therewith.
[0081] The prediction circuitry 210 may facilitate access to the channel context information and / or other information used by the predictive model through the use of an application or API executed using a processor such as the processor 202. However, it should also be understood that in some embodiments, the prediction circuitry 210 may include a separate processor, a specially configured field programmable gate array (FPGA), or an application specific interface circuit (ASIC) to manage the access and use of the associated data. The prediction circuitry 210 may also provide an interface that allows other components of the system to add or delete records from 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 circuitry 208. Thus, the prediction circuitry 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 circuitry 212 includes hardware configured to manage, store, process, cleanse, scale, normalize, and analyze channel context data objects, as well as data sets and other information that may be contained and / or used to generate the channel context data objects. Because the information that may be accessed and used to create the 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 circuitry 210 and the content aggregation circuitry 212 may have similar and / or overlapping functions. For example, both the prediction circuitry 210 and the content aggregation circuitry 212 may interact with one or more data objects associated with a context in which a channel exists. The content aggregation circuitry 212 may also provide access to other historical information, such as previous sets of information presented to a user regarding a given set of mobile devices (or other resources) and the channel or channels used to efficiently distribute such devices or other resources. Exemplary Functional Implementations of the Disclosed Embodiments 3 is a block diagram illustrating an overview of the functionality of a system 300 according to some embodiments of the present disclosure. As shown in FIG. 3, the system 300 incorporates three main functional blocks, including a user interface block 302, a data warehouse block 304, and a support systems block 306, which are arranged such that each functional block can communicate with other functional blocks in the system 300.
[0083] 3, the user interface block 300 includes one or more interface modules 302A-302N. In some example implementations, the system 300 is designed to interact with a range of internal and / or external (or third party, for example) users. In the context of a system designed to predictively identify one or more channels through which used mobile devices should be efficiently distributed, the system 300 may be used by one or more internal users (such as users associated with an entity responsible for distributing used mobile devices to the appropriate channel(s) and / or to one or more external entities, such as an aggregator responsible for collecting inventory for redistribution by the system 300). In such an example implementation, one interface module, such as interface module 302A, may provide the user interface functionality, access controls, and / or other aspects necessary for an internal user to operate and / or otherwise use the system 300 to predictively identify the appropriate channel through which to direct mobile devices and the conditions (such as capacity, pricing, and / or other factors) that apply to the one or more identified channels. Similarly, the user interface may provide the user interface functionality, access controls, and / or other aspects necessary for an external user (e.g., an aggregator) to interact with the system 300 using another module, such as, for example, interface module 302N.
[0084] Similar to the user interface 302, the data warehouse block 304 and the support systems block 306 each incorporate one or more functional modules, denoted as warehouse modules 304A-304N and support modules 306A-306N. In some example implementations, one of the modules provides functionality associated with planning and forecasting resource demand, which may involve optimizing one or more disposition channels based on information regarding available resource inventory, demand for such resources, strategic parameters, and / or other business rules, and other information associated with inventory and / or inventory visibility. In some such example implementations, one or more modules associated with the data warehouse block 304 and / or the support systems block 306 may generate a possible device list that contains information regarding a likely inventory of mobile devices maintained by the system 300 and information associated with the channels to which such inventory may be disposed.
[0085] In some example implementations, one of the modules provides functionality associated with aggregator management, which may include, but is not limited to, management of applications, account profiles, purchase histories, hierarchical and / or other rankings, bidding, negotiation functions, purchase orders, tracking of financial transactions, and / or billing associated with aggregators. In some such example implementations, one or more modules associated with the data warehouse block 304 and / or the support systems block 306 may enable onboarding of potential aggregators, ranking of aggregators, accepting and processing bids received from aggregators, accepting and processing purchase orders, and / or billing functions.
[0086] In some example implementations, one of the modules provides functionality associated with recovery and disposition of resources and / or other assets, which may include, but is not limited to, management of data sets and / or other information necessary to discover and document inventory and manage pricing and / or other aspects of inventory allocation. In some such example implementations, one or more modules associated with the data warehouse block 304 and / or the support systems block 306 may facilitate generating periodic inventory updates, initiating pricing and allocation allocations for use by aggregators, analyzing aggregator bids, and / or analyzing and approving pricing and / or other offer terms associated with aggregators.
[0087] In some implementations, one of the modules provides functionality associated with materials management, which may include, but is not limited to, managing inventory sorting operations, repairing bulk materials, aggregator skid reports, and / or material shipping. In some such example implementations, one or more modules associated with the data warehouse block 304 and / or the support systems block 306 may facilitate the development, receipt, and / or transmission of inventory sorting instructions (e.g., instructions associated with inventory liquidation, etc.), uploading and / or other processing of aggregate skid reports, and / or processing associated with shipping resources (e.g., mobile devices and / or other goods, etc.).
[0088] In some example implementations, one of the modules provides functionality associated with accounting and / or financial operations, which may include, but is not limited to, managing the determination of costs, pricing, and / or other terms associated with generating invoices. In some such example implementations, one or more modules associated with the data warehouse block 304 and / or the support systems block 306 may facilitate the generation of entries for use in aggregator material allocation, invoice logging, and / or other accounting operations.
[0089] In some example 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 example implementations, one or more modules associated with the data warehouse block 304 and / or the support systems block 306 facilitate the creation and management of documents used in connection with relationships between the entities operating the system and one or more aggregators or other third party users. Illustrative Data Flow Diagram of an Embodiment of the Disclosure 4 is a block diagram depicting an example data flow through a system 400 that may be used in connection with an example implementation of an embodiment of the present invention. As shown in FIG. 4, the system 400 includes a portal user interface services module 402 configured to receive and transmit information from an internal user 404A and / or an external user 404B (such as a request data object associated with a request for identification and / or allocation of channels through which a mobile device may be efficiently distributed). The portal user interface services module 402 is also configured to receive and transmit information from one or more data repositories 410A-410N, some of which may be configured to interact with a disposition database 406 and / or an inventory system 408.
[0090] In some example implementations, a user, such as internal user 404A and / or external user 404B, transmits a request data object and / or other information associated with a request for an identification of one or more channels through which a resource (such as a mobile device) may be disposed, and pricing and / or other terms associated with directing the resource through the channel or channels. Upon receiving such a request, the portal user interface services module 402 may interact with one or more of the data repositories 410A-410N to send or receive information used in connection with fulfilling the parameters of the requested data object.
[0091] For example, the portal user interface services module 402 may interact with a data warehouse, such as data repository 410A, that contains information associated with planning and forecasting of resource demand. In some such example implementations, the portal user interface services module 402 and associated data repository may create, exchange, and / or modify material lists and details associated with associated resources. In some such example implementations, the data repository 410A may also interact with the disposition database 406 to obtain lists and / or related information regarding anticipated resource inventory (e.g., identities of mobile devices anticipated to be in inventory at a given time, etc.).
[0092] In some example implementations, the portal user interface services module 402 may interact with a data repository, such as data repository 410B, that contains information associated with asset distribution. In some such example implementations, the portal user interface services module 402 and associated data repositories may create, exchange, and / or modify inventory and / or sales information associated with the related resources being distributed.
[0093] In some example implementations, the portal user interface services module 402 may interact with a data repository, such as data repository 410C, that contains information associated with buyback pricing and / or other buyback parameters. In some situations that arise in the context of used mobile devices, one source of mobile device inventory may include buyback systems and / or other arrangements where an entity purchases mobile devices from users in accordance with the terms of insurance coverage contracts, buyback programs, and / or other approaches for acquiring used devices. In some such example implementations, the portal user interface services 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 example implementations, the portal user interface services module 402 may interact with a data repository, such as data repository 410D, that contains information associated with material management functions. In some such example implementations, the portal user interface services module 402 and associated data repositories may create, exchange, and / or modify information associated with prices, costs, and / or other terms imposed on a given set of materials and / or other resources, including but not limited to invoices. In some such example implementations, the associated data repositories may also interact with the inventory system 408 to exchange information associated with grading and / or sorting of allocated materials, lot skid reports, and / or lot shipment releases.
[0095] In some example implementations, the portal user interface services module 402 may interact with a data repository, such as data repository 410N, that contains information associated with aggregator management functions. In some such example implementations, the portal user interface services module 402 and associated data repositories may create, exchange, and / or modify information associated with aggregator application submissions, management of aggregator profiles and / or accounts, and purchase order submissions.
[0096] Overall, as shown in FIG. 4, system 400 can leverage a wide variety of data sets and data sources to obtain and process the information necessary to identify one or more channels through which resources may be efficiently distributed at a given time, and to manage the functions necessary to ensure efficient movement of resource inventory according to the predicted and modeled channels. Example Process for Channel Prediction and Modeling Figure 5 is a block diagram illustrating an example data flow 500 that may be used in connection with efficient prediction and modeling of conditions and channels through which resources may be distributed. In Figure 5, a predictive modeler 508 is configured to receive a request data object from a user, such as via the interfaces shown and described in connection with Figures 2, 3, and 4. In some example implementations, upon receiving the request data object, the predictive modeler 508 may leverage data sets from a wide range of sources, depicted as data repositories 502A-502N, such as in connection with a master data aggregation manager 504.
[0097] One such repository from which the predictive modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relevant to efficient forecasting and modeling of distribution of resources, such as, for example, mobile devices, over one or more channels is an asset disposition data repository, which may include, for example, information about how one or more sets of particular resources have been efficiently distributed in the past. Such a repository may include (or otherwise access) information scraped, extracted, and / or otherwise obtained from one or more records of past resource allocations and / or information regarding the results of such allocations.
[0098] Another repository from which the predictive modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relevant to efficient forecasting and modeling of distribution of resources over one or more channels is a data repository that may contain, for example, information regarding seasonal changes and / or other time-related factors affecting the demand, availability, utility, and / or perceived value of one or more sets of resources. Such a repository may include (or otherwise access) information scraped, extracted, and / or otherwise obtained from one or more records of past resource allocations, and / or information regarding the results of such allocations, and / or studies of such seasonal and / or other time-based effects.
[0099] Another repository from which the predictive modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relevant to efficiently predicting and modeling the distribution of resources through one or more channels is a data repository that may include, for example, information regarding past sales and / or other distribution of resources. Such a repository may include (or have other access to) information scraped, extracted, and / or otherwise obtained from one or more records of past business-to-business and / or business-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 relevant to efficient forecasting and modeling of distribution of resources through one or more channels is a data repository that may include, for example, information regarding resource attributes. Such a repository may include (or otherwise have access to) information regarding the structure, functionality, operation, use, age, features, and / or other characteristics of used mobile devices in inventory, and / or may also include information relevant to determining whether and to what extent the mobile devices are capable of achieving one or more sets of functional expectations of a potential customer.
[0101] Another repository from which the predictive modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relevant to efficient forecasting and modeling of distribution of resources through one or more channels is a data repository that may include, for example, information regarding the market and / or other environment within which a particular relevant channel may exist. Such a repository may include (or have other access to) information scraped, extracted, and / or otherwise obtained from one or more records of activity and / or analysis of such activity conducted by competitors and / or other participants 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 relevant to efficient forecasting and modeling of distribution of resources through one or more channels is a data repository that may include, for example, information regarding claims made in connection with one or more resources, such as, for example, mobile devices. In a context in which all or a portion of the inventory of distributed mobile devices is obtained in connection with insurance coverage contracts and / or related programs, information regarding claims made on an individual and / or aggregate basis may be beneficial in capturing changes in the utility and value of mobile devices over time. Such a repository may include (or otherwise access) information scraped, extracted, and / or otherwise obtained from one or more records of claims made regarding one or more devices. This information may include, for example, troubleshooting data, device data, customer service data, and / or repair data used in connection with determining whether a device is eligible for a particular insurance coverage and / or buyback.
[0103] Another repository from which the predictive modeler 508 and / or master data aggregation manager 504 may receive channel context data and / or other information relevant to efficient forecasting and modeling of distribution of resources through one or more channels is a data repository that may include, for example, social media information and / or information regarding macroeconomic indicators. Such a repository may include (or have other access to) 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 affect the perception of value held by one or more potential customers.
[0104] As shown in FIG. 5, the predictive modeler 508 and / or the master data aggregation manager 504 can interact with a wide range of data sets from a wide range of sources. In some example implementations, such as when data sets are obtained in multiple different formats, the master data aggregation manager 504 may work in conjunction with the data filtering manager 506 to scale, cleanse, normalize, and / or otherwise format the various data sets so that they can be processed by the predictive modeler 508. Upon receiving the 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 FIG. 5 as model outputs 510A-510N. For example, in a situation where a particular inventory incorporates mobile devices from multiple different manufacturers, each of the model outputs 510A-510N may provide an identification of a particular channel in either or both a business-to-business and / or business-to-customer context through which a given portion of the inventory may be distributed, and an indication of pricing and / or other terms that may apply.
[0105] In some example implementations of data flow 500, the predictive modeler 508 may use the MARS model and / or another machine learning or trainable model such that over time, the predictive modeler 508 may improve its determination of one or more channels and / or conditions through which resources may be efficiently distributed by receiving multiple user confirmations.
[0106] In some such embodiments, the predictive modeler 508 may use machine learning, or equivalent, techniques to improve prediction and modeling of channels and conditions through which resources may be efficiently distributed. In some examples, the predictive modeler 508 may provide a trained model, generally configured to provide an output, such as a score (e.g., a confidence score, etc.), a recommendation, etc. In some embodiments, the trained model may be generated using supervised or unsupervised learning. In some examples, such learning may occur offline, during the start-up phase of the system, or may occur in real-time or near real-time during execution of the method illustrated in the described figures (e.g., predicting and modeling optimal channels for distribution of resources). The trained model may include the results of a clustering algorithm, a classifier, a neural network, an ensemble of trees, in that the trained model is configured or otherwise trained to map input values or input features to one of a set of predefined output scores or recommendations, and to change or adapt the mapping in response to historical data returned from previous iterations (e.g., measured distributions, such as those derived from available data).
[0107] Alternatively or additionally, the trained model may be trained to extract one or more features from the historical data using pattern recognition based on unsupervised learning, supervised learning, semi-supervised learning, reinforcement learning, association rule learning, Bayesian learning, solving probabilistic graphical models, among other computational intelligence algorithms that may extract patterns from data using iterative processing. In some examples, the historical data may include data generated using user input, crowd-based input, etc. (e.g., user verification).
[0108] In some examples, the predictive modeler 508 may be configured to apply the trained model to one or more inputs to identify a set of confidence scores. For example, if the input features were competitive sales information, such as may be obtained from one or more data sources, the predictive modeler 508 may apply such data to the trained model to determine whether the resulting predicted channel and / or pricing is accurate. In some examples, the trained model outputs a suggested confidence score based on other predictions and / or measurements using the same data.
[0109] Regardless of the exact configuration of the predictive modeler 508, upon receiving a request data object (and any necessary extraction or analysis of the data contained therein and / or other data related to the request), the predictive modeler 508 retrieves and / or otherwise receives one or more data objects from repositories 502A-502N and determines the channel, pricing, and / or other terms that will apply to the forecasted disposition of the inventory referenced in the request data object.
[0110] FIG. 6 is a flow chart of an example process 600 for predicting and modeling one or more channels and / or conditions that enable efficient distribution of resources in a given environment. As shown in block 602, the process 600 begins with receiving a request data object from a user. The request data object may incorporate a wide range of information and be expressed in any format that allows the request data object from a system associated with the user, such as the request source system 104, to be transmitted to a machine learning model and / or a system associated with such a model. In general, the request data object incorporates sufficient information to identify inventory and / or other resources associated with the request and may further identify time and / or other conditions that affect the likely disposition of the future inventory. In some example implementations of block 602, the request data may also include an authenticated indication of the user's identity.
[0111] As indicated at block 604, process 600 continues with extracting a requisition dataset for the relevant inventory from the requisition data object. As described herein, the requisition dataset may include sufficient information to identify the relevant inventory, such as mobile devices and / or the quantity of such devices distributed. In some example implementations, the requisition dataset includes set additional 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 requisition itself.
[0112] At block 606, process 600 entails receiving a set of contextual data objects. The contextual objects received at block 606 may include any of the data sets described herein and / or otherwise contemplated, including but not limited to data sets that may be stored in one or more memories, data warehouses, and / or other data repositories. As illustrated in process 600, an example implementation of block 606 entails contextual data objects and data sets associated with resources and channels through which such resources may be delivered and / or otherwise distributed. This data is used to drive predictive models that are used to identify and model channels and conditions that enable efficient distribution of associated inventory and / or other resources at future times.
[0113] As indicated at block 608, process 600 also includes generating and / or otherwise deriving a predicted channel and / or condition set using a machine learning model (e.g., through application of the received contextual data object and dataset). In some example implementations, the model can be a MARS model, and upon application of the relevant dataset 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 efficient distribution of associated resources.
[0114] As indicated at block 610, process 600 also includes causing a renderable object having the predicted channel and condition data set to be displayed on the user device. In some example implementations, the renderable object may be transmitted to the user device and cause the channel information, condition information, and / or other content contained in the predicted channel and condition data set to be presented to the user in a manner that allows the user to view and interact with the information. Exemplary Contextual Implementation of Channel Prediction and Modeling As noted herein, some example implementations arise in the context of resale of mobile devices received in connection with the fulfillment of insurance programs and / or other service agreements. In some such situations, the mobile devices are directed to one or more aggregators that can distribute the mobile devices through various commercial channels. In connection with identifying and selecting an aggregator (or other channel) to which to direct one or more sets of mobile devices, multiple categories of disparate data are captured, scaled, and / or otherwise processed to enable algorithmic layering of aggregators and the direction of resources to those aggregators.
[0115] In some example implementations, several processes involve identifying available inventory to be distributed, receiving bids from aggregators for portions of that inventory, algorithmically tiering the aggregators, creating and applying decay curves to offers associated with the aggregator bids, determining optimal offers and profit calculations among the offers from the aggregators, and allocating inventory among available channels. These processes tend to occur on a regular cycle (such as weekly, monthly, and / or on another regular schedule. FIG. 7 is a flow chart illustrating an example process 700 that reflects these and other operations according to some example implementations that may be used to allocate resources to aggregators.
[0116] As shown in block 702, the exemplary process 700 includes obtaining resource inventory and one or more offers from an aggregator. In a given cycle, upon receiving a list of available inventory and / or inventory expected to be distributed, the system shares all or a portion of the available inventory information with the relevant aggregator group. Based on this available inventory information, each aggregator prepares an offer, which may take the form of a request data object that encompasses multiple request parameters, such as, for example, a bid price for one or more SKUs, expected margin information, the amount of various inventory elements the aggregator requests, and / or other information requested as part of the bidding process. In some exemplary implementations, additional information regarding the aggregator may be provided by the aggregator and / or determined by the system to build a channel profile that reflects a set of properties associated with a given aggregator.
[0117] As shown in block 704, the example process 700 includes updating the associated decay parameters and the associated tiering parameters. In addition to soliciting bids and / or other resource requests from aggregators, the system updates the bid decay parameters and the tiering parameters before calculating the aggregator's assigned tiers and the decay curves to be applied to the collected bids. In some example implementations, the set of tiering parameters and / or the set of decay parameters may be received by the system as a data object from which the associated parameters may be extracted for use by the system.
[0118] Because the heterogeneous categories of data used in connection with the exemplary implementations may originate from multiple independent sources and / or may reflect quantities, values, and / or other metrics set on multiple different scales, one of the data processing steps used in connection with the algorithmic hierarchy involves scaling the data, which may result in transformed numerical values that can be more easily combined and processed, e.g., a limited set of integers, scaled range values, etc.
[0119] One of the factors that may be used in connection with tiering one or more aggregators is the volume at the portfolio level offered by a given aggregator. In some example implementations, the associated volume is the sum of all the volumes offered by the aggregator across all of the associated SKUs that may be distributed using the aggregator. It will be appreciated that such a volume measurement provides a gauge to the overall volume of mobile devices and / or other resources that the aggregator is looking to purchase, and may further indicate the scale of business the aggregator is capable of providing. Because the information underlying the volume calculation is typically expressed as the actual number of units of each associated SKU, a scaled value may be achieved using a scoring algorithm that ranks each aggregator based on the sum of their expressed volumes, assigns the highest score to the aggregator with the highest rank, and assigns progressively decreasing scores to other aggregators based on the aggregator's rank.
[0120] Another factor that may be used in connection with tiering one or more aggregators is the portfolio-level profit margin expected by one or more aggregators. In some example implementations, the portfolio-level profit margin is calculated by summing the profit margin across all SKUs identified by a given aggregator. It will be appreciated that this aggregated portfolio-level profit margin represents the total profit margin that may be available through a given aggregator. Since the information underlying the portfolio-level profit margin is typically expressed as a monetary value, the scaled value may be achieved using a scoring algorithm that ranks the aggregators based on their respective profit margins and assigns the highest score to the aggregators with the highest expected margins and assigns progressively decreasing scores to other aggregators based on their rank.
[0121] Another factor that may be used in connection with 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 the aggregator in the various unique SKUs with which the aggregator is associated. This information provides insight into how many types of devices the aggregator is looking to purchase, indicating the volume of business the aggregator can provide. In one exemplary implementation, the entropy measure is determined and scaled by sorting the associated CNNs according to their respective revenue potential by multiplying the CNN volumes by their projected average selling prices. The sorted devices are then combined or binned into categories (e.g., 10 categories, etc.) according to their rank. An aggregator-level entropy measure may then be obtained using the formula E=Σn*log n, where n is the volume of devices bid on in a given bid divided by the total volume of devices bid on. The entropy scores are then assigned an integer score based on the inverse ranking of the entropy values. Thus, a higher entropy score for an aggregator tends to mean that the aggregator is bidding on a large number of CNNs and has potentially better customers for mobile device providers from a volatility-focused perspective.
[0122] Another factor that may be used in connection with tiering one or more aggregators is the specialization of the aggregator. In some example implementations, the identity of the geographic market in which the aggregator focuses its efforts is relevant in determining the degree to which the aggregator competes in a given market. For example, where specialization in a domestic market tends to intensify competition disproportionately, the geographic focus of the aggregator may be assigned on a points scale incorporating positive and negative numbers, such as an integer between -2 and 2, with a purely domestic aggregator receiving -2, a mostly domestic aggregator receiving -1, an aggregator with an equal domestic and international footprint receiving 0, a mostly international aggregator receiving 1, and a fully international aggregator receiving 2.
[0123] Another factor that may be used in connection with tiering one or more aggregators is the length of the relationship between the source of mobile devices and / or other resources and the aggregator. In some circumstances, the length of the relationship tends to correlate with the stability of the business relationship. To convert a temporal measurement into a scaled value, a scoring algorithm may be used that calculates the length of the associated relationship in days and then provides an inverse ranking to ensure that the longest relationships receive the most points.
[0124] Another factor that may be used in connection with tiering one or more aggregators is a determination of whether the aggregator failed an associated audit. In some circumstances, a failed audit indicates that the aggregator should undergo additional scrutiny and / or penalties before allocating mobile devices and / or other resources to the aggregator. Because a failed audit is a binary condition, a scoring algorithm may be used to apply a binary score to a given aggregator, such as, for example, a -1 score for an aggregator that failed the audit and a zero score for an aggregator that did not fail.
[0125] Another factor that may be used in connection with tiering one or more aggregators is the invoice amount that each business-to-business aggregator provided in the previous offer cycle. In some circumstances, the previous invoice amount is an indicator of the actual volume of business provided by a given aggregator, as opposed to the projected levels reflected in the offer or bid. Since invoice amounts are typically expressed as monetary values in their native form, the invoice value may be scaled by applying an algorithm that identifies the highest total invoice amount among a set of aggregators, provides that aggregator with the highest score, and then incrementally reduces the scores applied to lower ranked aggregators.
[0126] Other factors that may be used in connection with tiering one or more aggregators include, for example, rankings based on D&B Paydex score, the extent to which the aggregator has an exclusive relationship with a source of mobile devices and / or other resources, the value and / or volume of return authorizations sought by the aggregator over time, the timeliness of bids, and the timeliness of payments.
[0127] As shown in block 706, the exemplary process 700 includes applying tiering parameters to the associated aggregators. Regardless of the exact factors used to generate the scaled scores used to tier the group of aggregators, upon compilation of the scores, the aggregators may be automatically divided into multiple tiers. For example, based on scores built over four or more (or another number, for example) bidding cycles, one set of aggregators may be assigned to the top tier, while lower ranked aggregators may be assigned to lower tiers. For example, the top 40% aggregators may be assigned to tier 1, the next 30% may be assigned to tier 2, and the remaining 30% may be assigned to a lower, third tier. Regardless of the particular thresholds applied, the channel profiles associated with the aggregators are assigned to a tier based at least in part on application of one or more of the tiering parameters described herein and / or additional information to the tiering algorithm received in the bids from the aggregators. In some example implementations, the tier assigned to a given aggregator is used in connection with further algorithmic evaluation of the bid or bids provided by the given aggregator and / or allocation of inventory across the set of eligible aggregators.
[0128] One of the technical challenges encountered in exemplary implementations dealing with resource distribution is the potential for high volatility in market and spot prices, which is further amplified by the potential for third-party datasets and other data sources to contain errors. Because machine learning algorithms tend to be sensitive to the range and distribution of attribute values, addressing 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 in time, it can be advantageous to remove outlier data points (such as pricing values and / or rate of change values) that are outside of expected ranges. In some situations, such as when data points are sparse, it can be advantageous to replace outliers with an interpolation, weighted average, and / or moving average between two or more adjacent data points.
[0129] As shown in block 708, the exemplary process 700 includes applying a decay curve to the offers received from one or more aggregators. In addition to assigning one or more aggregators to a given tier based on certain scaled parameters, as noted herein, exemplary implementations further contemplate the application of a decay curve to the bid and / or bids associated with a given aggregator. As noted herein, some aspects of the evaluation of aggregators, comparing bids received from aggregators and allocating resources to various channels, involve the use of multiple data sets obtained over time. To prevent aged data from obscuring current trends and / or compromising the predictive power of the associated model or models, some exemplary implementations contemplate using a decay factor applied to the bids and / or aged data to reduce the impact of the aged data over time and ensure that the model retains the model's ability to predict future pricing information and / or other information related to the ability to efficiently distribute inventory through one or more channels. One approach for developing the decay coefficients and / or otherwise processing the associated data involves the use of MARS (Multivariate Adaptive Regression Spline) models. MARS is a non-parametric regression technique (which may be considered an extension of linear models) that automatically models nonlinearities and interactions between variables. In general, MARS builds models of the following form:
[0130]
number
[0131] In some circumstances, applying a MARS-based model to establish a decay function allows pricing information provided by an aggregator and / or otherwise obtained (e.g., by analysis of sales on distributed user platforms, such as eBay™ and / or other channels through which mobile devices may be sold directly to consumers) to be fed into a decay model that can model the price at which a customer is likely to purchase a mobile device at a particular time in the future. For example, pricing estimates and market pricing information obtained from an aggregator, along with other scaled data streams (e.g., received in connection with an aggregator's evaluation, included in a bid, and / or additional market data, etc.) can be fed as inputs 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 tiered rankings and a predicted decay price curve, mobile device inventory can be directed to aggregators that are most likely to be able to distribute the mobile device when the device is actually available.
[0132] As noted herein, some example implementations arise in situations where used mobile devices and / or other resources are acquired through buyback programs, insurance policies, and / or other arrangements that prevent a central actor from fully controlling the content and volume of the acquired inventory. However, the information used to tier aggregators (e.g., bids, assumed pricing, assumed profit margin percentage information, etc.) combined with the predicted price decay curves obtained using the MARS-based model can be combined with and applied to a logistic regression model to set the price and / or price range at which inventory may be appropriately acquired. This can redirect inventory that is not being effectively distributed through one channel to an alternative channel that has capacity.
[0133] For example, a MARS-based model produces a pricing decay function that provides as an output a predicted price for all of the associated mobile devices and / or other resources for a given time frame in the future. This pricing information can then be combined with the tiering information and the list of all devices to be allocated. For example, pricing information provided in bids from aggregators, additional market data, data defining internal margin guidelines, etc., can be combined with the expected future prices to calculate the price at which each available item in the inventory is likely to sell during a future time period.
[0134] After the price decay function has been applied to the bids received from the aggregators, the system generally retains three categories of information that may be combined with and otherwise applied to the model to identify the optimal offer(s) and profit(s) for the available inventory. This information, including but not limited to the results of the tiering and application of the decay curve to the associated offers, may be retained in memory, as shown in block 710 of FIG.
[0135] As shown in blocks 712 and 714, the exemplary process 700 includes determining one or more optimal offers, determining a resource allocation, and applying the resource allocation. It will be understood that not all aggregators, other channels, and their respective bids are created equal. As noted herein, several different data points are combined in connection with assigning tiers to aggregators. In addition to a tiering approach, the system and / or other central actors may engage in different relationships bounded by different rules and / or other thresholds that govern at least a portion of the allocation of inventory. For example, one or more aggregators may be internal partners with the central actor and / or may have a full or partial exclusivity agreement that gives the aggregator the right to have at least a portion of the inventory regardless of the competitiveness of its bids and / or the tier to which the aggregator is assigned. In some exemplary circumstances, such a particular relationship may be sufficient to allocate all or most of the available inventory.
[0136] In situations where inventory remains available after the rules associated with a particular relationship have been fulfilled, the bids from the aggregators are ranked. In some example implementations, the ranking may be performed across all aggregators for a given set of items in the inventory. In other example implementations, the bids may be further subdivided based on the quantity requested in association with the bids prior to ranking. After the bids are ranked, one or more thresholds are applied in some example implementations to limit the number of bids under consideration. For example, a threshold may be set at three bids (or other number of bids) such that the top three (and / or a group of aggregators submitting the three highest bids) are considered to have met the threshold. In some such example implementations, the tier to which the high-bidding aggregator is assigned is considered to exclude bidders from unfavorable tiers and / or include bidders from favored tiers.
[0137] Upon identifying the three (or more) aggregators with the highest bids, the associated resource inventory is allocated to the channel profiles. An offer price is generated for each associated item in the inventory based on the decay pricing curve, the generated probability, and the calculated profitability associated with the highest bid that otherwise meets the associated threshold. This offer price can then be used to calculate a 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 informed by the amount requested by the given aggregator, and / or any of the intermediate calculations referenced herein (such as probability calculations). It will be appreciated that other factors may be used in the allocation of resources, particularly in some situations where considerations such as participation in the channel profile, perceptions of fairness, and / or other factors are permitted to influence the allocation. For example, an 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, the cloud and / or oracle may be referenced to adjust the allocation.
[0138] Additional steps may also be performed. For example, after inventory is initially allocated according to the aggregator's tiering and the predicted decay pricing curve, requests by 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 available additional inventory. Based on the bid pricing and the requested inventory of the bids, the aggregator's bids are re-ranked, thereby generating the best bids for the additional inventory (which may differ, for example, from the initial ranking obtained by the tiering process described above). In some example 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 against the profitability associated with the highest bid.
[0139] In some example implementations, various parameters associated with one or more channel profiles may vary, making direct comparison of one parameter to another inappropriate in situations where such a comparison is desired. For example, one channel profile may include bids or other offers configured to be valid for 30 days or more, while a second channel profile may include 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 of different times decay so that bids can be compared over similar time frames. For example, if one channel profile provides bids that are valid for a full month, a first weekly bid may decay for a month while a second channel profile provides a series of bids on a weekly basis to allow accurate comparison with the month-long bids. In such an example, a second weekly bid may decay for three weeks, a third weekly bid may decay for two weeks, and a fourth weekly bid may decay for one week.
[0140] Based on the available inventory and the underlying aggregator information, the probability that a given aggregator will accept the updated item associated with the additional inventory is calculated and used to set an offer price when additional inventory can be acquired in the market and / or repurchased from the slow-moving aggregator. Thus, based on the initial tiering model and price decay model, discrepancies between the calculated device allocations can be addressed through inventory redirection and / or acquisition of additional inventory to meet the demand for a given channel that exceeds the initial allocation. Exemplary System Environment for Resource Offer Generation FIG. 8 illustrates another exemplary system environment 800 in which implementations with improved resource offer generation may be implemented. The depiction of the environment 800 is not intended to limit or otherwise restrict the embodiments described and contemplated herein to any particular configuration of elements or systems, nor is it intended to exclude any alternative configurations or systems of the set of configurations and systems that may be used in connection with embodiments of the present disclosure. Rather, FIG. 8 and the environment 800 disclosed therein are presented merely to provide an exemplary basis and context for facilitating some of the features, aspects, and uses of the methods, apparatus, and computer program products disclosed and contemplated herein. While many of the aspects and components presented in FIG. 8 are shown as discrete, separate elements, it will be understood that other configurations, including configurations that combine, omit, and / or add aspects and / or components, may be used in connection with the methods, apparatus, and computer programs described herein. For example, in some embodiments, the resource offer generation system 802 may be combined, in part or in full, with the prediction system 102 to form a single component configured to perform the operations disclosed herein with respect to both systems.
[0141] An embodiment implemented in a system environment such as system environment 800 advantageously provides improved resource offer generation associated with a given regional program identifier by preparing and / or retrieving one or more resource offer generation input data sets, and / or expected resource volume data sets, average distribution demand data sets, and market intelligence data sets, generating a fair market offer set using an exception detection model based on the retrieved data sets, receiving benchmark and portfolio goal data sets, and generating a resource offer set by applying one or more of the retrieved and generated data sets to a resource offer generation model and / or submodels therein, in addition to efficiently predicting and modeling the conditions and channels through which resources may be distributed, as described above. Some such implementations contemplate rendering an offer adjustment interface to a client device associated with an offer control user, the offer adjustment interface being configured to receive manual adjustments to the generated resource offer set for updating to create an adjusted resource offer set. Further, some such embodiments cause 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 approval or rejection of the adjusted or generated resource offer set. Some such embodiments leverage a hardware and software arrangement or environment for improved generation of resource offers via the actions and operations described, contemplated, and / or otherwise disclosed herein.
[0142] As shown in FIG. 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 FIG. 1. For example, the prediction system 102 may include a prediction system server 102B or a prediction system device 102D, a prediction system configured to store information associated with a request data object, a user, a resource (e.g., a used mobile device, etc.), and / or a channel associated with the request data object, a channel context data object, other data sets, interfaces associated with such data objects or data sets, a request source system, a channel content system, and / or other information related to the conditions and channels through which resources may be distributed and efficient prediction and modeling of the channel and generation of one or more associated sets of messages and / or digital content items. The prediction system module 102A may be configured to receive, process, convert, transmit, communicate with, and evaluate request data objects, channel context data objects, content and other information associated with such data objects, other data sets, and associated interfaces via a server such as a prediction system device 102D (other than via a user interface of the prediction system server 102B) configured to provide additional means for interfacing with the system database 102C, and other components of the prediction system 102, and / or other components shown in or otherwise contemplated by the system environment 100. The prediction system server 102B and / or the prediction system device 102D may be connected to the prediction system via any of a number of public and / or private networks, including, but not limited to, the Internet, the public telephone network, and / or networks associated with particular communication systems or protocols, and may include at least one memory for storing at least application and communication programs.
[0143] Similarly, system environment 800 also includes a content system 106 including a content module 106A, a content server 106B, and a content system database 106C, configured to communicate with prediction system 102 to provide information that prediction system 102 may need when predicting and modeling the conditions and channels under which resources may be distributed. Additionally, system environment 800 includes a request source system 104, which may originate one or more requested data objects, requested data object information, and / or additional content or other information associated with one or more requested data objects.
[0144] The system environment 800 further includes a resource offer generation system 802. The resource 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 generation system module 802A may be configured to receive, process, transform, transmit, communicate with, and evaluate offer requests, resource offer data objects, content and other information associated with such data objects, other data sets, and associated interfaces to generate resource offer sets, facilitate resource offer set adjustments, and / or manage 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, the public telephone network, and / or networks associated with a particular communication system or protocol, 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 that may be used to store information associated with the offer request, the user, the resource (e.g., used mobile device, etc.), and / or the offer request or corresponding information associated with the offer request, regional program data objects or corresponding information, resource offer sets, adjusted resource offer sets, other data sets, interfaces associated with the offer request, and / or other information related to improved generation of the resource offer set(s). The resource offer generation system database 802C may be accessed by the resource offer system module 802A and / or the resource offer system 802B. In some embodiments, the resource offer generation system database 802C may additionally or alternatively be accessed by the prediction system module 102A, the prediction system server 102B, and / or the prediction system device 102D to store information received, generated, or accessed by components of the prediction system 102. 8 depicts the resource offer generation system database 802C as a unitary structure, it will be appreciated that the generation system database 802C may additionally or alternatively be implemented in a distributed manner and / or to enable storage at facilities that are physically remote from one another 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 joint database or distributed repository.
[0146] It will be appreciated that all of the components illustrated in Figure 8 may be configured to communicate over any wired or wireless communication network, including interfaces with wired or wireless local area networks (LANs), personal area networks (PANs), metropolitan area networks (MANs), wide area networks (WANs), etc., as well as the associated hardware, software, and / or firmware necessary to implement the above networks (e.g., network routers, network switches, etc.) For example, networks such as cellular, 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 combinations thereof, and currently available or later developed networking protocols, including, but not limited to, TCP / IP-based networking protocols, may be used in connection with 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 processing and operations facilitated and described with respect to systems 102-106, the resource offer generation system 802 engages in machine-to-machine communications with the request source system 104, the prediction system 102, and the contextual content system 106 over one or more networks to facilitate processing of offer requests received from users, improved generation and management of resource offer sets and corresponding resource offer data objects, and generation and / or transmission of control signals to cause rendering of interfaces for viewing resource offer sets and / or offer analysis datasets and / or market information, adjusting the resource offer sets, and / or approving submitted adjusted resource offer sets. Exemplary Apparatus for Implementing Improved Resource Offer Generation It will be appreciated that the resource offer generation system 802 may be embodied by one or more computing systems, such as the apparatus 900 shown in Figure 9. As illustrated in Figure 9, the apparatus 900 may include a processor 902, a memory 904, input / output circuitry 906, communications circuitry 908, data management circuitry 910, and model performance circuitry 912. The apparatus 900 may be configured to perform any of the operations described herein.
[0148] Regardless of how the device 900 is embodied, the device of the exemplary embodiment includes or is otherwise configured to communicate with a processor 902 and a memory device 904, and optionally input / output circuitry 906 and / or communication circuitry 908. In some embodiments, the processor (and / or a 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 904 may be non-transitory 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) that includes gates configured to store data (e.g., bits) that may be retrievable 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. for enabling the device to perform various functions according to 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.
[0149] As mentioned 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., chips) that include materials, components, and / or wires on a structural assembly (e.g., baseboard). The structural assembly may provide physical strength, size conservation, and / or electrical interaction limitations for the component circuitry contained therein. Thus, the apparatus may be configured to implement embodiments of the present disclosure, in some cases, on a single chip or as a single "system-on-chip." Thus, in some cases, the chip or chipset may constitute the means for performing one or more operations to provide the functionality described herein.
[0150] The processor 902 may be embodied in a number of different ways. For example, the processor may be embodied as one or more of a variety of hardware processing means, such as a co-processor, a microprocessor, a controller, a digital signal processor (DSP), a processing element with or without an associated DSP, or various other processing circuitry including integrated circuits, such as, for example, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), a microcontroller unit (MCU), a hardware accelerator, a dedicated computer chip, and the like. Thus, in some embodiments, the processor may include one or more processing cores configured to execute independently. A multi-core processor may enable multi-processing 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 multiple threads.
[0151] In an exemplary embodiment, the processor 902 may be configured to execute instructions stored in the memory device 904 or otherwise accessible to the processor. Additionally or alternatively, the processor may be configured to execute hard-coded functionality. Thus, whether configured by hardware or software methods or a combination thereof, the processor may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to embodiments of the present disclosure, while being configured accordingly. Thus, for example, if the processor is embodied as an ASIC, FPGA, etc., the processor may be hardware that is 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 uniquely 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 unique 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 by instructions to perform the algorithms and / or operations described herein. A 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 input / output circuitry 906, such as a user interface, which may be in communication with the processor 902 to provide output to a user and, in some embodiments, receive an indication of a user input. Thus, the user interface may include a display, and in some embodiments may also include a keyboard, mouse, joystick, touch screen, touch area, soft keys, microphone, speaker, or other input / output mechanisms. Alternatively or additionally, the processor may include user interface circuitry configured to control at least some functionality of one or more user interface elements, such as the display, and, in some embodiments, a speaker, ringer, microphone, etc. The processor and / or user interface circuitry 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 a processor-accessible memory (e.g., memory device 904, etc.).
[0153] The device 900 may also optionally include communications circuitry 908. The communications circuitry 908 may be any means, such as a device or circuitry embodied in either 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 communications interface may include an antenna (or multiple antennas) and supporting hardware or software for enabling communication with a wired and / or wireless communication network. Additionally or alternatively, the communications interface may include circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or for processing reception of signals received via the antenna(s). In some environments, the communications interface may alternatively or additionally support wired communications. Thus, for example, the communications interface may include a communications modem and / or other hardware / software for supporting communication via cable, digital subscriber line (DSL), universal serial bus (USB), or other mechanisms.
[0154] As shown in FIG. 9 , the apparatus may also include 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 a fair market offer set, generating a resource offer set, and / or optimizing a resource offer set. For example, the data management circuitry 910 may access one or more local 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, data sets, etc. that include 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 data sets, such as via base tables associated with one or more databases, including that the resource offer generation input data sets may include a historical offers data set, a resource listing data set, a market intelligence data set, and a resource mapping data set.
[0155] The data management circuitry 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 cell phones as resources, used cell phones with 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. The 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 as a resource mapping data set in a database or repository.
[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 data sets may be associated with third party systems and may require standardization and / or sanitization for use by one or more data models using the resource mapping data sets. The data management circuitry 910 may include means configured to perform one or more processing algorithms on the received market intelligence data sets prior to storing the market intelligence data sets for use by one or more models.
[0157] In some embodiments, the data management circuitry 910 may receive, obtain, prepare, and / or otherwise access an envisioned resource volume data set. The envisioned resource volume data set may include a stored channel profile to which resources are distributed when another system, such as the prediction system 102, is allocated. The envisioned resource volume data set 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 envisioned resource volume data set may be a portion of data output by the prediction system 102.
[0158] In some embodiments, the data management circuitry 910 may receive, obtain, prepare, and / or otherwise access the average distribution demand dataset. The average distribution demand dataset may include at least an average selling price of the various resources associated with the various resource set identifiers. In some embodiments, the average distribution demand dataset may be generated by another system, such as the 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 interfaces, such as application programming interfaces (APIs), that allow other components of the system to obtain, generate, or otherwise access various data sets. In some embodiments, the data management circuitry 910 may obtain information regarding one or more resources or economic factors associated with the distribution of the resources. For example, the data management circuitry 910 may retrieve and / or normalize data associated with the distribution of the resources with other information that may be used to generate improved resource offer generation, including, but not limited to, any of the information obtained from and / or otherwise associated with the content system 106, including previous distribution of similar resources by the system, distribution of the resources by one or more third party entities (e.g., competitors), neutral competitor entities (e.g., business-to-consumer competitors), macroeconomic factors associated with the resources, promotional periods associated with the distribution of the resources, and / or other information that may be used to generate improved resource offer generation.
[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 an API or an application executed using a processor such as the 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 associated 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., the prediction system database 102C) via a network interface provided by the communication circuitry 908. Thus, the data management circuitry 910 may be implemented using hardware components of an apparatus configured with either hardware, software, or a combination of both hardware and software to implement these planned functions.
[0161] The apparatus further includes model performance circuitry 912. The model performance circuitry 912 includes hardware, software, or combinations 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 algorithms and / or machine learning models for improving resource offer generation. The model performance circuitry 912 may validate and / or receive and validate collection period data objects received by a client device (e.g., request source system 104), data collection parameter value sets, and pre-required data record sets retrieved from associated databases and / or accessed in other manners, such as utilizing data management circuitry 910. The model performance circuitry 912 may additionally or alternatively initiate a resource offer generation model and / or apply one or more associated data sets to the resource offer generation model. In some embodiments, the model performance circuitry may communicate with external systems and / or servers (e.g., cloud servers), alone or in combination with one or more of the other components of the apparatus configured to manage and execute the resource offer generation models and / or associated models and sub-models. Exemplary Process for Generating and Adjusting Resource Offers FIG. 10 illustrates an example 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 the 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 may each be embodied by a request source system such as the request source system 104. The client device 1001 may be associated with an offer control user, such as an authenticated user, that submits an offer request and / or authenticates and accesses the resource offer generation system 1003 with authorization to adjust the generated resource offer set. Similarly, the approval device 1005 may be associated with an offer approval user, such as an authenticated user, that 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 may be embodied by a resource offer generation system, for example, the resource offer generation system 802 embodied by the apparatus 900.
[0162] In data flow 1000, some 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] At 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 access an interface via the client device 1001 to create a new regional program data object. Each regional program data object may be associated with at least a region identifier (e.g., identifying a particular country or sub-region within a country) and a program identifier (e.g., identifying a particular set of offerings within a country). The offer control user may, for example, enter one or more parameter values associated with the regional program data object via the client device 1001. For example, financial goal 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, for example, by editing one or more parameter values of an existing regional program data object.
[0164] In optional step 1004, the resource offer generation system 1003 may store the configured regional program data object. The regional program data object may be configured by the offer control user in step 1002 and received by the resource offer generation system 1003 upon submission by the offer control user via the client device 1001 (e.g., when the offer control user engages a save or submit button associated with an interface for configuring the regional program data object). The regional program data object may be stored in association with a corresponding regional program identifier. The regional program identifier may uniquely identify the regional program data object and may 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, via the client device 1001, selects existing regional program data objects for which the offer control user desires to generate a resource offer set. In some embodiments, the resource offer generation system 1003 may cause rendering to the client device 1001 of an interface for selecting regional program data objects for which the offer control user desires 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 cause a renderable object including a rendered interface for selecting regional program data objects from a list of existing regional program data objects.
[0166] At step 1008, the client device 1001 may submit a collection period data object associated with the generated resource offer set, or a corresponding collection period timestamp for defining the collection period data object. 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 during which an offer control user intends to provide resource offers based on the generated resource offer set. In some embodiments, the offer control user may enter a collection start timestamp and a collection end timestamp via an interface rendered on the client device 1001 (e.g., via a user interface component, such as a drop-down component, for entering the collection period start timestamp and the collection period end timestamp) to generate a corresponding collection period data object.
[0167] At step 1010, the resource offer generation system 1003 may receive a resource offer generation initiation request. The resource offer generation request may be received in response to engagement by an offer control user via a client device 1001 after input of a collection period start timestamp and a collection period end timestamp of an interface component configured to transmit the resource offer generation initiation request. The resource offer generation initiation request may result in preparation of one or more resource offer generation input data sets 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 initiation request includes at least a collection period start timestamp and a collection period end timestamp selected by the offer control user that may be used by the resource offer generation system in creating and / or determining a collection period data object. Alternatively, in some embodiments, the resource offer generation initiation request includes a collection period data object created and / or transmitted from a client device, e.g., the 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 a collection period start timestamp associated with the collection period data object represents a future timestamp (e.g., after today). The resource offer generation system 1003 may also validate that a 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 of the collection start period timestamp). In this regard, the resource offer generation system 1003 is configured to validate that the collection period represents a valid future timestamp range 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 may query a repository, such as an offer acceptance repository, for all offer status records associated with a particular regional program identifier, each offer status record being associated with a collection period data object, and determine that each of the collection period data objects for the stored offer status records does not overlap with the input collection period. The resource offer generation system 1003 may then determine whether or not multiple conflicting offers have occurred. 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 (e.g., 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 of 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 for rendering in a corresponding interface. If the collection period data object is validated in step 1014, the flow continues to step 1016.
[0170] At step 1016, the resource offer generation system 1003 may validate one or more resource offer generation input data sets. The resource offer generation input data sets may be retrieved from a repository or multiple repositories maintained by and / or accessible to the resource offer generation system 1003. The resource offer generation input data sets may include data extracted from or retrieved in association with multiple disparate resources and / or repositories, and / or 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 data sets via various data extraction and / or retrieval processes. In some embodiments, for example, some or all of one or more of the resource offer generation input data sets may be obtained via scraping of one or more tracked web resources, retrieval from public data repositories, retrieval from private data repositories derived and / or tracked via the resource offer generation system 1003 and / or associated systems.
[0171] In some embodiments, the one or more resource offer generation input data sets are updated by the resource offer generation system (or an associated system) at one or more predefined intervals. For example, the resource offer generation input data sets can be updated daily, weekly, etc., or some resource offer generation input data sets can be updated at a first interval and some resource offer generation input data sets can be updated at a second interval. Each of the resource offer generation input data sets can be associated with a particular regional program identifier and / or collection period data object.
[0172] Additionally or alternatively, one or more of the resource offer generation input data sets may be updated in real time. In some embodiments, one or more of the resource offer generation input data sets are automatically updated in real time immediately prior to validation. In other embodiments, one or more of the resource offer generation input data sets are updated in real time when validation fails for one or more of the resource offer generation input data sets.
[0173] In some embodiments, each of the one or more resource offer generation input data sets is validated using one or more data sufficiency models. The data sufficiency models may determine whether the resource offer generation input data sets meet one or more predefined requirements. For example, the data sufficiency check may determine whether one or more of the resource offer generation input data sets have been updated within a predefined time interval (e.g., updated within the previous day, the previous week, or another time interval). In some such embodiments, each of the resource offer generation input data sets may be associated with a last updated timestamp. Additionally or alternatively, in some embodiments, the data sufficiency check may determine whether one or more of the resource offer generation input data sets meet an expected accuracy threshold. For example, one or more data accuracy models may be used to determine an accuracy value for each of the resource offer generation input data sets based on expected data formats, 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 data sets.
[0174] The resource offer generation input datasets may be applied to one or more models, such as algorithmic or machine learning models, for use in generating the resource offer set. The resource offer generation input datasets may be input to and / or otherwise utilized by one or more models for use in generating the resource offer set. For example, the resource offer generation input datasets may include one or more datasets for application to an exception detection model to generate a reliable resource characteristic dataset, such as a fair market offer set that may be applied or otherwise used by the resource offer generation model. Additionally or alternatively, the resource offer generation input datasets may include one or more datasets for application to a resource offer generation model to generate a resource offer set.
[0175] The resource offer generation input data sets may include a historical offer data set, a resource list data set, a market intelligence data set, and a resource mapping data set. Each of the resource offer generation input data sets 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 data sets via a database accessible to the resource offer generation system 1003. Each of the resource offer generation input data sets 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 a table corresponding to the resource offer generation input data set.
[0176] The resource offer generation input data sets may include historical offer data sets, which may include at least information associated with previously generated offer data objects, resource acquisition information associated with previously generated offer data objects, sales information associated with said resources, etc. The historical offer data sets may be used to retrieve and / or generate potential resource volume data sets, which may be associated with a particular resource set identifier for a particular regional program identifier.
[0177] The resource offer generation input dataset may include a resource list dataset. The resource list dataset may include resources present in inventory for a particular regional program identifier and a grade level for each resource set identifier associated with the resource. The resource list dataset may include warehouse details, which may include resource attributes, mapped to each resource set identifier for the resource. For example, resource make and model identifiers may be mapped to resource set identifiers to assign resource identifiers. The resource list dataset may also indicate whether a resource offer data object should be generated for a resource in the resource list dataset. For example, the resource list dataset may flag, for example using a bit flag, each resource that causes a resource offer data object to be generated.
[0178] The mapping dataset may include correlation information to link various resource identifiers associated with various third-party entities, aggregators, etc., with standardized resource set identifiers for use in analyzing other resource offer generation input datasets that include data records retrieved or associated with third-party systems. The mapping dataset may 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 retrieved associated with a particular third-party system for a particular region. The 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 a mapping between the third-party resource identifier information and the standardized resource set identifiers and generate a mapping score that indicates the likelihood that the generated mapping is correct. The mapping score may be based on matching known resource attribute values associated with the resource set identifiers with resource attribute values parsed from the third-party resource identifier information. The mapping score may then be compared to a mapping confirmation threshold, and a mapping score that meets (e.g., by exceeding) the mapping confirmation threshold is considered to be correctly mapped. If third-party resource identifier information is mapped and assigned a mapping score that does not meet the mapping confirmation threshold, the third-party resource identifier information may be marked for manual mapping and / or reviewed. The mapping dataset may include completed algorithmic and manual mappings.
[0179] The resource offer generation input data set may include a market intelligence data set. The market intelligence data set 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 data set using one or more processing algorithms to validate the sufficiency and / or validity of various records in the market intelligence data set. For example, one or more processing algorithms may be used to identify and delete or flag for manual adjustment data records that do not contain information required to map the market intelligence data to resource set identifiers. The market intelligence data may be mapped as associated with a particular resource set identifier and / or a particular resource based on the mapping data set. For example, a particular subset of the market intelligence data set may include or be otherwise associated with the resource set identifier to which that subset of market intelligence data applies.
[0180] Additionally or alternatively, the resource offer generation input data set may include one or more data sets derived and / or generated from a forecasting system as described herein. For example, the resource offer generation input data set may include an expected resource volume data set, an average distribution request amount data set. The resource offer generation input data set may include an expected resource volume set, an average distribution request amount, an average distribution request amount data set, and / or an expected receipt amount data set derived from other data objects or data sets derived or generated from the forecasting system. The expected receipt amount data set may represent an expected resource volume for a given regional program identifier and / or may include an expected or predicted price characteristic for each resource set identifier to be distributed in association with a particular channel profile.
[0181] If one or more of the resource offer generation input data sets are not validated at 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 data sets are not present in an associated database, such as the resource offer generation system database 802C. For example, the resource offer generation input data sets may not be validated if one or more of the prerequisite data record sets have not been generated previously for the regional program identifier for which the resource offer generation process was initiated at step 1006. In some embodiments, the resource offer generation system 1003 may query a 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 the required resource offer generation input data sets are present and / or updated as described above. If the resource offer generation input data sets are validated at step 1018, flow may continue 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 configured by the offer control user and provided based on the regional program data objects stored in an earlier step. For example, the collection parameters may include certain financial analysis metrics, targets, costs, or other parameters associated with the regional program data objects. Some, none, or all of the collection parameters may be associated with default values configured by the offer control user at an earlier stage. Examples of collection parameters include a channel mix of distribution channels, one or more activity costs, commissions, minimum offer requirements, minimum offer profit requirements, minimum margin requirements, volume mix of resources, and / or resource multipliers and / or adjustment indexes based on one or more resource attributes and / or conditions (e.g., resource age multipliers, resource functionality multipliers, resource lock status multipliers, etc.).
[0183] The resource offer generation system 1003 can generate and / or send one or more control signals to the client device 1001, where the control signal(s) result in a renderable data object including an interface that is displayed on one or more client devices, including the client device 1001. The interface may include, or may be otherwise configured for rendering, a component for rendering the data collection parameters for input by a user, such as an offer control user, associated with the client device 1001. For example, the interface may include an input component associated with each data collection parameter for receiving a data collection parameter value for the corresponding data collection parameter.
[0184] At step 1022, the client device 1001 may render the data collection parameters for input by the offer control user. In some embodiments, each of the data collection parameters provided at step 1020 is rendered in an interface provided via the client device 1001 in response to receiving the provided data collection parameters. For example, a renderable data object may be rendered by the client device 1001, where the renderable data object includes an interface component for each data collection parameter. Each data collection parameter may be rendered in association with an interface component for changing a value associated with the corresponding data collection parameter. If provided, each data collection 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 collection parameter to input a new data collection parameter value associated with that data collection parameter.
[0185] At step 1024, the client device 1001 submits values for the data collection parameters. In some embodiments, the offer control user may engage an interface component, such as a submit button, rendered in the interface to submit the currently entered values for the data collection parameters. The submitted values may include various 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 did not change. The client device 1001 may transmit an electronic data transmission including the data collection parameter values to the resource offer generation system 1003, which may receive the electronic data transmission and parse the electronic data transmission to extract the data collection parameter values.
[0186] In step 1026, the resource offer generation system 1003 may receive and, in some embodiments, validate the submitted data collection parameter values. The data collection parameter values may be validated using a validation rule set stored and / or retrievable by the resource offer generation system 1003. The validation rule set may ensure that one or more of the collection parameter values, alone or in combination with other collection parameter values, satisfy predefined rules. For example, in some embodiments, the validation rule set may include business rules associated with resource profitability and / or distribution allocations.
[0187] If the data collection parameter values are not validated at 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 have not been satisfied. Additionally or alternatively, the error message may specifically indicate that a particular validation rule has not been satisfied and / or a suggestion associated with modifying the collection parameter values to satisfy the validation rule set. If the data collection parameter values are validated at optional step 1028, the data collection parameter values 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 values may be stored as benchmark and portfolio goal data sets associated with the regional program data object. In some embodiments, the data collection parameter values may be stored in temporary or staging tables in a database, such as the resource offer generation system repository 802C. Flow then continues to step 1030.
[0188] At 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 generation of a resource offer in response to submitting the collection parameter values. In other embodiments, upon submission and validation of the data collection parameter values, the offer control user may be prompted via the client device 1001 to provide and submit additional data sets (e.g., values for one or more additional data collection parameters based on the initially submitted collection parameter values).
[0189] To request a resource offer generation, 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 be otherwise associated with a regional program identifier and a collection period data object that were associated with the regional program data object initiated by the offer control user in an earlier step. 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, for example, by the client device 1001. The resource offer generation system 1003 may receive a regional program data object and / or a corresponding regional program identifier, and may receive 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 the resource offer generation request from the client device 1001, the resource offer generation system 1003 may transfer the data collection parameter values from the temporary or staging tables to implementation tables accessible by one or more models for resource offer generation. For example, in some embodiments, the data collection parameter values may be transferred to attribute tables accessible for application to resource offer generation models and / or exception detection models.
[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 particular regional program identifiers and collection period data objects. For example, in some embodiments, the resource offer generation system may maintain an offer approval repository that includes an offer status record for each regional program identifier and collection parameter data object for which resource offer generation has been requested. Each offer status record may be associated with and retrievable with the regional program identifier and collection parameter data object.
[0192] An offer status record may be created upon receiving a resource offer generation request. 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. The offer status record may initially be associated with a resource offer set generated in a later step. The resource offer set may then be updated or otherwise adjusted to create an adjusted resource offer set, which may then be stored in association with the offer status record. Additionally, adjustments may be made to the stored resource offer set associated with the offer status record such that the adjusted resource offer set may be further updated.
[0193] At 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 particular 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 data set. In other embodiments, the resource offer generation model may be a machine learning model configured to predict a resource offer set.
[0194] The resource offer generation model may be configured and / or trained to generate a resource offer set based on one or more of the resource offer generation input data sets. The resource offer generation input data sets may additionally or alternatively include one or more data sets received or output from the prediction system, or other data sets derived from data sets received or output from the prediction system. For example, the resource offer generation model may generate a resource offer set based at least in part on an assumed resource volume data set for various channel profiles allocated by the prediction system. In a specific example of acquisition and distribution of used mobile devices, the assumed resource volume data set may include a set of assumed or predicted resources to be distributed in association with an efficient channel allocation of resources (e.g., some resources associated with various resource set identifiers). Additionally or alternatively, the resource offer generation model may generate a resource offer set based at least in part on an average distribution request amount data set. In a specific example of acquisition and distribution of used mobile devices, the average distribution request amount data set may include an assumed sales price at which the resources will be distributed via the efficient channel allocation. The average distribution request amount dataset may include, for example, price characteristics for various resource set identifiers and / or may be based on or include a decay parameter data object associated with a decay curve for estimating the change in expected price characteristics for various resource set identifiers due to expected time intervals for distribution. In some embodiments, the resource offer generation model may retrieve, receive, or otherwise obtain a decay parameter data object for use in determining expected price characteristics of the distribution of resources associated with one or more resource set identifiers based on the distribution time delay input parameters included in the benchmark and portfolio goal datasets. For example, the average distribution request amount dataset may be adjusted based on the decay curve and the distribution time delay input parameters.In some embodiments, the anticipated resource volume dataset and the average distribution request amount dataset, a combination of these sets, or a portion or combination of portions thereof, and / or the market intelligence dataset and / or portions of the market intelligence dataset may be used to derive a predicted receipt amount dataset for distribution of an anticipated resource, such as used mobile devices, via efficient channel allocation associated with conditions or characteristics, such as price characteristics, predicted by the prediction system. In some embodiments, a resource offer generation model may be configured to generate a resource offer set based at least in part on the predicted receipt amount 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 data sets. In some embodiments, the database may be updated, at least in part, 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 generation input data sets 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 a resource offer set, where the resource offer set includes resource offer data objects for various resource set identifiers that meet desired benchmark and portfolio goal data sets. The benchmark and portfolio goal data sets may include some or all of the data collection parameters entered by the offer control user in the previous steps. For example, in some embodiments, a particular regional program data object having an input regional program identifier may be associated with one or more particular data collection parameters that define the benchmark and portfolio goal data sets (e.g., financial goal parameters that the resource offer set must meet). Additionally, in some embodiments, one or more of the data collection parameters may be associated with default parameter values that may be changed via input by the offer control user, e.g., provided in step 1024.
[0197] In some embodiments, the resource offer generation model may utilize or be otherwise associated with one or more sub-models for generating a resource offer set. For example, the resource offer generation model may include an offer optimization model configured to optimize a resource offer set or generate an optimized resource offer set based on one or more boundary conditions, such as at least a benchmark and portfolio goal dataset and / or other applicable dataset. Additionally or alternatively, for example, the resource offer generation model may be associated with or utilized with an exception detection model configured to generate fair market offer sets for various resources, such as those obtained based on a resource listing dataset and / or an expected resource volume dataset. In some embodiments, a market intelligence dataset, and / or one or more subsets thereof, along with the fair market offer set generated by the exception detection model, may be utilized to generate the resource offer set. For example, the market intelligence dataset may include an average third party offer data object set including 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 may include and / or otherwise represent an average price characteristic associated with a particular third party entity for a resource set identifier.
[0198] In some embodiments, one or more datasets are applied to the resource offer generation model to generate a resource offer set. For example, in some embodiments, a maximum third party offer data object set, an average third party offer data object set, a fair market offer set, a benchmark and portfolio goal dataset, and / or one or more resource offer generation input datasets. The various applied datasets may be applied such that the resource offer generation model generates a resource offer set including 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 goal datasets.
[0199] The resource offer generation model may generate an optimal resource offer set based on various applied data sets. For example, the resource offer set may be generated to optimally satisfy the benchmark and portfolio goal data sets. In this regard, the resource generation model may be configured to utilize one or more algorithms, statistical models, and / or machine learning models to generate the resource offer set. In some embodiments, the resource offer generation model may utilize an assumed resource volume data set and / or an average distribution request amount data set to generate the resource offer set. For example, in some embodiments, the resource offer generation model includes at least a linear optimization model configured to generate a resource offer set based on various input data sets to optimally satisfy the benchmark and portfolio goal data sets. For example, based on the assumed channel profile allocation and price characteristics for the resource set identifier to be distributed (e.g., as identified in the input assumed resource volume data set and average distribution request amount data set), the resource offer generation model may generate a resource offer set to maximize the satisfaction of the benchmark and portfolio goal data sets. For example, in some embodiments, the benchmark and portfolio goal data sets may include only a minimum resource margin for the resource offer data objects in the generated resource offer set. In other embodiments, the benchmark and portfolio goal data sets may include boundary conditions for the acquisition and distribution of particular resources, for example, by maximizing price characteristics of resource offer data objects associated with a subset of resources (e.g., resources associated with a particular resource set identifier).It should be understood that the benchmark and portfolio goal datasets may act as any number and type of boundary conditions for optimizing the resource offer set, such as minimum profit for the resource offer dataset, a desired margin per resource, resource offer data objects associated with a particular subset of resources (e.g., resources associated with a promotion), a combination of distribution channel profiles, and / or other financial analysis targets.
[0200] In some embodiments, some or all of the resource offer generation model is maintained and executed via a sub-server and / or a second server managed by and / or otherwise associated with the resource offer generation system 1003. For example, a second server in communication with 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 implementing the model using any number of myriad programming implementations. For example, in some embodiments, the resource offer generation model may be configured using the R programming language, where the second server or the sub-server is configured with an environment for interfacing with the model.
[0201] The resource offer generation system 1003 may initiate the resource offer generation model, or one or more operations performed by the resource offer generation model, on the second server or sub-server via one or more APIs and / or services for communicating with the second server or sub-server. In some embodiments, the resource offer generation system 1003 may transmit one or more requests to initiate and / or apply one or more of the input datasets to the resource offer generation model on the second server or sub-server. 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 including the input datasets, and uses one or more SQL Server Integration Services (SSIS) to push the resource offer generation input datasets and / or generated datasets to the second server or sub-server for application to the resource offer generation model. Upon output of resource offers by the resource offer generation model, the generated resource offer set (or corresponding data) may be pushed back from the second server or sub-server, for example, to the resource offer generation system 1003, for storage in a database environment (e.g., an SQL environment) using one or more APIs and / or services, such as one or more SSIS associated with the SQL environment.
[0202] In some embodiments, the resource offer generation system 1003 directly controls and / or has access to the resource offer generation models to generate the resource offer sets. For example, the resource offer generation system 1003 may perform all of the operations described with respect to the steps above on the same system (e.g., a server or group of servers) as opposed to a separate system.
[0203] In some embodiments, the generated resource offer set is stored in association with an offer status record for the regional program identifier and collection period data object. Additionally or alternatively, an offer status indicator included in or associated with the offer status record may be updated to embody or represent a pending adjustment status indicator. For example, the offer status record may be maintained in or retrieved from an offer approval repository accessible to 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.
[0204] At 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 a database for retrieval. In some embodiments, the notification may be transmitted in association with the offer control user's user account utilized to access the resource offer generation system 1003 and 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 an email transmitted to an email account associated with the offer control user (e.g., an email associated with a user account associated with the offer control user).
[0205] 11 illustrates an example data flow diagram 1100 for rendering a resource offer set, adjusting the resource offer set, submitting the adjusted resource offer set for approval, and approving or rejecting the adjusted resource offer set. These operations are performed through a number of specific interfaces corresponding to and configured to enable such operations. The data flow diagram 1100 includes data flow steps between components such as subsystems of the system 800, including the client device 1001, the resource offer generation system 1003, and the approval device 1005. The data flow diagram 1100 may be performed after some or all of the steps described with respect to the data flow diagram 1000 above.
[0206] In data flow 1100, some 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, an 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, the client device 1001, or another of multiple client devices. Upon re-accessing the resource offer generation system 1003, the offer control user may re-authenticate and / or otherwise begin a new authenticated session or may continue an existing authenticated session.
[0208] In step 1104, the resource offer generation system 1103 generates and / or transmits a control signal that causes a renderable object including an offer adjustment interface to be displayed on one or more client devices, such as the client device 1001. In some embodiments, the control signal(s) may be transmitted to a second client device accessed by an offer control user associated with the client device 1001 (e.g., a second computer or mobile device through which the offer control user accessed the resource offer generation system 1003 and initiated an authenticated session). The offer adjustment interface includes an indication of a resource offer set. For example, the offer adjustment interface may include resource offer values of 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 a storage or database. For example, the resource offer set may be a generated and / or optimized resource offer set from a previous step that has been stored in association with a regional program identifier.
[0209] The offer adjustment interface may be configured to enable adjustment of the 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 for adjustment and enter, e.g., via user engagement, an adjusted resource offer value for said selected resource offer data object. 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 performed by the offer control user.
[0210] The control signal causes at least the client device 1001 to render an offer adjustment interface including at least an indication of the resource offer set. In some embodiments, the offer adjustment interface further includes an indication of data from or derived from a resource offer generation input dataset. For example, in some embodiments, the offer adjustment interface includes market intelligence data, or a representation of the market intelligence data, for each resource offer data object in the resource offer set. For example, the market intelligence data rendered in the offer adjustment interface may include one or more third party offers, such as competitor offers. The offer adjustment interface may further include an indication of an offer analysis dataset associated with the resource offer set. For example, the offer analysis dataset may include an 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 that is currently associated with the 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 a market intelligence dataset. Alternatively, the resource offer generation model and / or the exception detection model may be configured to generate an offer analysis data set 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 the resource offer set, and any adjustments. One or more of the analysis interfaces may provide an indication of data for analyzing the adjusted resource offer set with respect to one or more third-party offers. For example, the 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] At step 1106, the client device 1001 renders an offer adjustment interface. The offer adjustment interface may be rendered to enable an offer control user to view offer data objects associated with various resources. The offer adjustment interface may be configured to enable adjustment of each of the resource offer data objects in the resource offer set in response to user engagement with the offer adjustment interface to change offer values, for example.
[0213] At 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 resource offer values associated with each offer data object in the resource offer set. The offer control user may additionally or alternatively analyze one or more indicators of the rendered offer analysis dataset via the offer adjustment interface. For example, the price adjustment interface may include a dashboard for accessing various analysis interfaces, such as the interfaces illustrated by FIG. 14 and FIG. 15, and indicators of the offer analysis dataset that may be analyzed to determine whether to adjust the resource offer values of one or more resource offer data objects in the resource offer set. 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 execute 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] At step 1110, the client device 1001 and / or an offer control user via the client device 1001 may adjust the resource offer set. In some embodiments, the offer control user may adjust the resource offer values of one or more resource offer data objects. For example, the offer control user may enter adjusted resource offer values of one or more resource offer data objects via user engagement with a price adjustment interface. The adjustments to the resource offer set may be performed based on analysis of information rendered in the offer adjustment interface.
[0215] In some embodiments, the offer control user may adjust at least one resource offer data object via the client device 1001 and then 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, where the control signal(s) include 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 objects to create a new adjusted offer set. In other embodiments, the one or more control signal(s) are generated and / or transmitted automatically in response to input by the offer control user to adjust the resource offer data objects, e.g., in response to input of an adjusted resource offer value for a particular resource offer data object.
[0216] In some embodiments, the stored resource offer set to be updated is retrieved in association with the regional program identifier and collection period data object. For example, the stored resource offer set may be retrieved from an offer acceptance 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 new adjusted resource offer set created may then be stored, for example in association with the regional program identifier and collection period data object, to replace the previously stored resource offer set. 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 the adjustment(s). For example, an adjusted resource offer set may include one or more offer resource data objects associated with an adjusted offer value that may be dynamically updated via the offer adjustment interface. Additionally, an offer analysis dataset may be recalculated or determined, and metrics of the offer analysis dataset may be updated to render the updated offer analysis dataset in the interface. For example, one or more offer analysis algorithms for determining, identifying, or otherwise calculating an offer analysis dataset may be executed based on the adjustment of one or more of the resource offer data objects, and metrics of the offer analysis dataset rendered in the offer adjustment interface may be dynamically updated in real time to reflect the output from said algorithm(s). In some embodiments, one or more analysis interfaces accessible via a rendered dashboard may be dynamically updated upon adjustment of one or more of the resource offer data objects. By dynamically updating the rendering of the offer adjustment interface, an offer control user may immediately visualize the effect of adjusting one or more offer data object(s) and continue to adjust the resource offer set in real time.
[0219] At 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 finalized 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 data set to create the adjusted resource offer set. In other embodiments, the completion control signal includes the adjusted resource offer set itself, for example, created by the user device 1001. The adjusted resource offer set may reflect any adjustments made to the resource offer data objects in the resource offer set. In some embodiments, the offer adjustment interface additionally includes an interface component, such as an offer submission component, that an offer control user may engage to cause the generation and / or transmission of the completion control signal.
[0220] At 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 the adjusted resource offer set. In some embodiments, the resource offer generation system 1003 retrieves, for example, from an offer approval repository, an offer status record associated with the regional program identifier and collection period data object, and updates an associated offer status indicator to represent a pending approval status indicator. In some embodiments, the resource offer generation system 1003 creates the adjusted resource offer, for example, by updating a previously stored resource offer set based on one or more adjustment data objects. Alternatively, in some embodiments, a resource offer set stored in association with the regional program identifier and collection period data object, for example, in the offer approval repository or another repository, may be updated based on the adjusted resource offer set parsed and / or extracted from the completion control signal.
[0221] In optional step 1116, the resource offer generation module 1003 notifies the offer approved user that the adjusted resource offer set has been submitted and stored. In some embodiments, a notification associated with the offer approved user's user account may be transmitted such that the offer approved user may access to retrieve the notification by accessing the resource offer generation system 1003. In some embodiments, the offer approved user may be notified via an application, interface, or other service associated with the resource offer generation system 1003. In other embodiments, the offer approved user may be notified via a third party application, interface, or other service, such as via an email transmitted to an email account associated with the offer approved user (e.g., an email associated with a 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 the 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 the second request source system 104. The approval device 1005 may be configured to execute an application, interface, web / browser application, etc. for accessing the resource offer generation system 1003 as an offer approval user may be different 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 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] The offer approval user may be associated with a user account that has permissions to access the submitted adjusted resource offer sets, to access the corresponding offer adjustment interface, and to respond to the submitted adjusted resource offer sets (e.g., to approve or reject the submitted adjusted resource offer sets). For example, the resource offer generation system 1003 may provide to the management device 1005 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 particular regional program identifier and collection period data object. The offer approval user may then select the adjusted resource offer sets for the particular regional program identifier and collection period data object that the offer approval user wants to view, analyze, and / or approve or reject.
[0224] At step 1120, the resource offer generation system 1003 may generate and / or transmit an approval request control signal to result in a second renderable object including an approval interface for display at another of the 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 a selection of an adjusted resource offer set for a particular regional program identifier and collection period data object. The approval interface includes an indication of the adjusted resource offer set. The adjusted resource offer set may be retrieved from storage upon access by an offer approval user, for example, via the management device 1003. For example, the offer approval user may select to view the adjusted resource offer sets submitted in association with a particular regional program data object having a particular regional program identifier.
[0225] In some embodiments, the approval interface includes additional indications of data. The approval interface may include the same indications of data rendered in 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 an indication of data from or derived from the resource offer generation input dataset. The approval interface, in some embodiments, further includes market intelligence data, or a representation of the market intelligence data, for each resource data object in the resource offer set. For example, the market intelligence data rendered in the approval interface may include one or more third party offers, such as competitor offers. The approval interface may further include an indication of 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 or otherwise determined based on the submitted adjusted resource offer set and one or more resource offer generation input datasets. Thus, it is 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 an embodiment, 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] At step 1122, the managing device 1005 and / or an offer approval user via the managing device 1005 may analyze the adjusted resource offer set. In some embodiments, the offer approval user may view resource offer values 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 goal information) that may be analyzed to determine 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, e.g., taking into account the benchmark and portfolio goal datasets. For example, the analysis interfaces may include one or more interfaces for visualizing the offer strength of the adjusted resource offer set, price trends associated with the adjusted resource offer set, market comparisons associated with the adjusted resource offer set, etc.
[0228] The offer approval user may analyze the adjusted resource offer set based on identified, received, or offline benchmark and portfolio goal data sets via various interfaces and indicators therein. The benchmark and portfolio goal data sets may include one or more profitability, margin, or other financial targets for the regional program identifier associated with the adjusted resource offer set. In some embodiments, the approval device 1005 may be configured to automatically analyze the adjusted resource offer set. For example, the approval device 1005 may be configured to run one or more offer approval algorithms based on the adjusted resource offer set and / or the offer analysis data sets to determine whether the adjusted resource offer set should be approved or rejected.
[0229] At step 1124, the offer approval user, via the managing device 1005, may engage an approval interface to approve or reject the adjusted resource offer set. For example, in some embodiments, the offer approval user may engage a first interface component to approve the resource offer set or a second interface component to reject the resource offer set. The resource offer set may be approved or rejected based on the analysis performed at step 1122.
[0230] In step 1126, the managing device 1005 may determine whether the offer accepting user has accepted the adjusted resource offer set or rejected the adjusted resource offer set. In some embodiments, the determination depends on the user interface component that the offer accepting user engaged in step 1124. In other embodiments, an offer acceptance control signal is transmitted to the resource offer generation system 1003 after step 1124, and the decision is based on a control signal received from the resource offer generation system 1003 in response to the offer acceptance control signal.
[0231] In a situation where the offer approval user rejects the adjusted resource offer set, the flow may continue to optional step 1128. In optional step 1128, the managing device 1005 and / or the offer approval user via the managing device 1005 may create an offer rejection message associated with the adjusted resource offer set. In some embodiments, a user interface, or a user interface component, is rendered to allow the offer approval user to enter and submit the offer message for creating it. In some embodiments, the interface may provide free text input to allow entry of one or more predefined offer rejection messages and / or a custom offer rejection message. The offer rejection message may be created after the offer approval user rejects or indicates a desire to reject the 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 adjusted resource offer set and / or a determination of the adjusted resource offer set, an explanation defining why the adjusted resource offer set is rejected, and / or adjustment steps performed to refine the adjusted resource offer set for approval. Alternatively, in some embodiments, an offer rejection message may be created and / or created and submitted by the offer-approving user prior to rejecting the adjusted resource offer set. In some embodiments, a user interface component is provided for rejecting the adjusted resource offer set and submitting the offer rejection message.
[0232] The management device 1005 may transmit an offer acceptance response to the resource offer generation system 1003 in response to submitting an acceptance or rejection. For example, the offer acceptance response may be generated and / or transmitted in response to engagement with an acceptance interface to accept or reject the adjusted resource offer set, or in some embodiments, in response to engagement with a user interface component to submit an offer rejection message. The offer acceptance response may include at least an offer acceptance status indicating the acceptance or rejection of the adjusted resource offer set. In some embodiments, if the offer acceptance status is a rejection status (e.g., if the offer acceptance user rejects the adjusted resource offer set), the offer acceptance response may additionally include a created offer rejection message if the offer acceptance user created one.
[0233] At step 1130, the resource offer generation system 1003 may receive an offer acceptance control signal including at least an offer status indicator, where the offer status indicator is represented by or otherwise embodied in a rejection status indicator. Additionally or alternatively, in some embodiments, the offer acceptance control signal may include an offer rejection message created by the offer acceptance user. Upon receiving the offer acceptance 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 the adjusted resource offer set associated with the regional program identifier, the collection period data object, and the 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 the offer acceptance repository, sub-repository, or table. For example, the resource offer generation system 1003 may update the offer status record associated with the adjusted resource offer set to include the rejection status indicator. For example, the resource offer generation system 1003 may retrieve the offer status record from a repository, such as the offer acceptance repository, based on the regional program identifier and the collection period data object. The offer status indicator associated with or included in the 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] At 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 such that the offer control user may access the rejection notice upon subsequent access to the resource generation system via the user account.
[0236] The resource offer generation system 1103 may generate and / or configure one or more control signals for causing the rendering of a rejection notice to the client device 1001. The control signal(s) may be generated or configured to include a renderable data object associated with or including the rejection notice. The control signal(s) may be transmitted to the client device 1001 to cause the rendering of an interface or interface component that includes the rejection notice. In some embodiments, the control signal(s) are transmitted following a subsequent access by the offer control user to the resource offer generation system 1003, such as via the client device 1001 or another client device.
[0237] At 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 again access the resource offer generation system 1003 via the client device 1001 a period of time after submitting an adjusted resource offer set for approval. In some embodiments, the offer control user may not have ended an authenticated session associated with accessing the resource offer generation system since beginning a resource offer generation process or submitting an adjusted resource offer set for approval, and thus may re-access the resource offer generation system 1003 without subsequent authentication. In other embodiments, the offer control user may re-authenticate himself via the client device 1001 to begin another authenticated session for accessing the resource offer generation system 1003.
[0238] At step 1136, the client device 1001 may render a rejection notice. In some embodiments, the rejection notice may be rendered in an interface associated with the regional program data identifier and collection period data object, e.g., in an interface in which the offer control user may view each regional program data object and / or associated information, each collection period data object for which resource offer generation was simulated, associated offer status indicators, and / or, if available, a rejection notice for one or more rejected adjusted resource offer sets for a particular regional program identifier and collection period data object (e.g., based on an offer status record that includes or is associated with a rejection status indicator).
[0239] The offer control user may then access the rejected adjusted resource offer set to make further adjustments to resubmit a new adjusted resource offer set for approval. Flow may then return to step 1106, where an offer adjustment interface is rendered on the client device 1001 for access by the offer control user via the client device. The offer control user may engage the offer adjustment interface to adjust the adjusted resource offer set and resubmit for approval. In some embodiments, the cycle defined by steps 1106-1136 may be repeated once, twice, or more times until adjusted acceptance by the offer approval user.
[0240] Returning to step 1126, in a situation where the offer-accepting user rejects the adjusted resource offer set, flow may continue to step 1138. At step 1138, the resource offer generation system 1003 may receive an offer acceptance control signal that includes at least an offer status indicator, where the offer status indicator is represented or otherwise embodied by an acceptance status indicator. Upon receiving the offer acceptance 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 the adjusted resource offer set associated with the regional program identifier, the collection period data object, and the offer status indicator (e.g., an approval status indicator). In some embodiments, the resource offer generation system 1003 may update a corresponding offer status record in an offer approval repository, sub-repository, or table. For example, the resource offer generation system 1003 may update an offer status record associated with the adjusted resource offer set to include the 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 included in 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] Upon updating the offer status record based on the approval status indicator at step 1140, 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 be similarly associated with one or more user accounts, such as a user account of the offer control user who submitted the adjusted resource offer set, a user account associated with an executive leader for the regional program data object, and / or one or more user accounts associated with a sales or distribution user for the regional program data object. In some embodiments, the approval notification includes the approval status indicator and / or an indication of the adjusted resource offer that has been set as approved.
[0243] The approval notice may be generated and / or transmitted in a myriad of ways. In some embodiments, the approval notice may be embodied by a message stored by the resource offer generation system 1003 and accessible via the client device during the authenticated session (e.g., via a messenger or notification system accessible via the resource offer generation system 1003). In other embodiments, the approval notice 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 notice.
[0244] After step 1140 is completed, the adjusted resource offer set may be distributed, for example, by the resource offer generation system 1003 and / or one or more of the notified users, to one or more entities, such as one or more third party entities associated with various resource acquisition and / or distribution channels in the region associated with the regional component of the regional program identifier. The adjusted resource offer set may then be utilized for resource acquisition in the region, for example, by offering to acquire resources associated with the particular resource set identifier at predefined price characteristics defined by resource offer values of resource offer data objects in the adjusted resource offer data set associated with the particular resource set identifier.
[0245] 12A is a flowchart of an example process 1200 for generating a resource offer set, adjusting the resource offer set, and receiving an offer acceptance status for the adjusted resource offer set, according to some embodiments of the present disclosure. The operations illustrated with respect to the example process 1200 may be performed by a resource offer generation system, for example, embodied by the apparatus 900.
[0246] At optional block 1202, the apparatus 900 includes means, such as the model performance circuitry 912, the input / output circuitry 906, the communication circuitry 908, the processor 902, etc., or a combination thereof, for receiving a regional program identifier and a collection period data object. The regional program identifier may be received from a client device to initiate resource offer generation associated with the regional program data object having the regional program identifier. The collection period data object may be received from a client device and include a collection period start date timestamp and a collection period end date timestamp.
[0247] At optional block 1204, the apparatus 900 includes means, such as the data management circuitry 910, the model performance circuitry 912, the processor 902, etc., or a combination thereof, for determining that the regional program identifier and collection period data object are not associated with a pending resource offer generation process. In some embodiments, the apparatus may query a repository, such as an offer acceptance repository embodied by the resource offer generation system database 802C, based on the regional program identifier and collection period data object. If an offer status record is retrieved, for example as response data to the query, a resource offer generation process has been initiated 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 initiated and the flow may end.
[0248] At block 1206, the device 900 includes means, such as data management circuitry 910, communication circuitry 908, processor 902, etc., or a combination thereof, for retrieving at least one resource offer generation input data set. In some embodiments, the resource offer generation input data set 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 data set in a particular database. In some embodiments, the resource offer generation input data set includes a historical offer data set, a resource list data set, a market intelligence data set, a resource mapping data set, an expected resource volume data set, an average distribution request amount data set, and / or an expected receipt amount data set. The expected resource volume data set may include a subset of the expected channel and condition data set output by the prediction system, or may be derived in other ways therefrom. For example, the expected resource volume data set may include predicted volume condition data from the predicted channel and condition data set output by the prediction system for various channel profiles. The average distribution request amount data set may include a subset of the expected channel and condition data set output by the prediction system, or may be derived in other ways therefrom. For example, the average distribution demand dataset may include predicted pricing characteristic condition data from the predicted channel and condition dataset output by the prediction system. In some embodiments, a combination of these various datasets is 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, in generating the resource offer set, the resource offer generation model may utilize the reliable resource characteristic dataset generated by the exception detection model. In one such example, the reliable resource characteristic dataset may include characteristics associated with resource acquisition and / or distribution, e.g., 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 untrusted third-party resource pricing datasets and one or more distributed resource pricing dataset(s). In this regard, at block 1212, the apparatus 900 includes means, such as model performance circuitry 912, processor 902, etc., or a combination thereof, for generating a fair market offer set using the exception detection model. It should be understood that in some embodiments, a fair market offer set may not be generated.
[0250] Using the acquisition of used mobile devices as an example, one or more untrusted third-party resource pricing datasets and the distributed resource pricing datasets may be applied to the anomaly detection model to generate a trusted resource characteristic dataset, e.g., a fair market offer set. The fair market offer set may include fair market offer data objects for various resource set identifiers, each having a price characteristic (e.g., a fair market offer value) for each of the resource set identifiers. For example, each third-party resource pricing dataset may be associated with a particular third-party entity, e.g., a competing entity, and may include a record for an average price characteristic (e.g., a weekly pricing value at which the third-party entity purchases and / or distributes the resource set identifier) for each resource set identifier offered by the third-party entity set over a particular time interval. The distributed resource pricing dataset may include an average offer value (e.g., a weekly value at which the resource associated with the resource set identifier can be purchased from an individual user via the distributed user platform) for each resource set identifier offered by users via the distributed user platform. The exception detection model may generate a reliable resource characteristic data set embodied by a fair market offer set via the process described below with respect to FIG. 12B.
[0251] At block 1214, the apparatus 900 includes means, such as the data management circuitry 910, the model performance circuitry 912, the communications circuitry 908, the processor 902, etc., or combinations thereof, for receiving the benchmark and portfolio goal data sets. The benchmark and portfolio goal data sets may be received from a client device, e.g., in response to user input and submission by an offer control user, or may be received from an approval device, e.g., in response to input of submission by an offer approval user. Alternatively, in some embodiments, the benchmark and portfolio goal data sets may be retrieved from a database, such as the resource offer generation system database 802C.
[0252] In some embodiments, the benchmark and portfolio goal data sets may include one or more data collection parameter values for various data collection parameters. In some embodiments, the benchmark and portfolio goal data sets may additionally or alternatively include default values associated with the regional program data objects having the regional program identifiers entered in the previous block. The benchmark and portfolio goal data sets may include various data objects that represent boundary conditions for use in generating the resource offer sets, for example. For example, in one exemplary context of acquiring and distributing used mobile devices, the benchmark and portfolio goal data sets may include portfolio-level financial targets such that the resource offer sets are generated such that the resource offer values for the various resource offer data objects satisfy the boundary conditions represented by the benchmark and portfolio goal data sets.
[0253] At block 1216, the apparatus 900 includes means, such as data management circuitry 910, model performance circuitry 912, processor 902, etc., or combinations thereof, for generating a resource offer set using a resource offer generation model. In some embodiments, the resource offer set is generated by applying at least one or more of the resource offer generation input data sets to the resource offer generation model. Additionally or alternatively, benchmark and portfolio goal data sets may be applied to the resource offer generation model, such that the generated resource offer set must satisfy the applied benchmark and portfolio goal data sets. The resource offer set may include resource offer data objects associated with one or more resources to be acquired in association with a regional program data object. A resource offer value for said resource offer data object may represent a price at which a particular resource is offered for acquisition from a resource owner via 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 data set. In other embodiments, the resource offer generation model includes one or more configured and trained machine learning models to generate an output using the applied data set.
[0254] In some embodiments, the resource offer generation model may include one or more algorithms and / or machine learning models for optimizing the resource offer data objects for various resource set identifiers to generate an optimal resource offer set to satisfy the benchmark and portfolio goal data sets. The benchmark and portfolio goal data sets may act as boundary conditions for optimizing the generated resource offer set. For example, in some embodiments, the benchmark and portfolio goal data sets may include a minimum profit, margin or profit per resource, and / or other financial analysis objectives. The resource offer generation model may include a linear optimization model configured to maximize the resource offer set according to the benchmark and portfolio goal data sets. 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 an optimization request to a server, for example via one or more APIs, and receiving a responsive optimized resource offer set.
[0255] Using acquisition of used mobile devices as another example, the resource offer set may include resource data objects having price characteristics for various resource set identifiers generated to optimally meet the applied benchmark and portfolio goal data sets. The resource offer generation model may generate device offer values for various user mobile devices associated with various resource set identifiers, e.g., CNNs, such that the entire device offer set for all devices meets user-entered and / or default values of parameters associated with the benchmark and portfolio goal data sets (e.g., desired profit margin, combination of channel profile, device resource set identifier, or CNN offered as promotion, etc.). The resource offer generation model may consider efficient resource allocation for one or more channel profiles and / or corresponding predicted price characteristics associated with the distribution of a particular resource set identifier, e.g., generated by a forecasting system, to generate optimal resource offer data objects for the various resource set identifiers.
[0256] The resource offer generation model may utilize one or more other datasets applied, e.g., one or more other resource offer generation input datasets (such as offer history datasets and / or market intelligence datasets) and / or one or more datasets derived by an exception detection model, to identify price characteristic targets to exceed in generating resource offer data objects to be included in the resource offer set while satisfying the boundary conditions represented by the benchmark and portfolio goal datasets. For example, in some embodiments, the resource offer generation model may execute one or more algorithms, machine learning models, etc. to attempt to first generate a resource offer set to include resource offer data objects associated with a price characteristic (e.g., resource offer value) that meets, e.g., exceeds, a 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 is unable to generate a resource offer set to meet 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 a price characteristic that meets, e.g., exceeds, an 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 is unable to generate a resource offer set to satisfy the average price characteristic 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 exceed, e.g., satisfy, the average price characteristic for the resource set identifiers associated with the fair market offer set.
[0257] At block 1218, the apparatus 900 includes means, such as the data management circuitry 910, the model performance circuitry 912, the processor 902, etc., or a combination thereof, for generating a control signal that causes a renderable object including an offer adjustment interface to be displayed on a first of the one or more client devices. The client device may be a particular client device associated with an offer control user authenticated with the apparatus 900 for the authenticated session. The control signal may cause rendering of the offer adjustment interface.
[0258] The offer adjustment interface may include respective resource offer values for each resource offer data object in the resource offer set. The offer adjustment interface may additionally include measures of the offer analytics data set, such as portfolio-level financial values based on the adjusted resource offer set and the market intelligence data. Furthermore, in some embodiments, the offer adjustment interface includes a dashboard for accessing one or more analytics interfaces, each analytics information including one or more measures of data based on or derived from various portions of the resource offer set and / or the market intelligence data. The device may cause the rendering of the offer adjustment interface by transmitting a renderable data object that embodies the offer adjustment interface.
[0259] At block 1220, the apparatus 900 includes means, such as the data management circuitry 910, the communications circuitry 908, the processor 902, etc., or a combination thereof, for updating the resource offer set to an adjusted resource offer set. The adjusted resource offer set may include one or more resource offer data objects having adjusted offer values entered by the offer control user.
[0260] In some embodiments, the apparatus 900 can receive one or more control signals from one or more client devices, the control signals including one or more adjustment data objects for use in updating the resource offer set. The resource offer set can be updated to create an adjusted resource offer set based on the one or more adjustment data objects. For example, the one or more adjustment data objects can 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 the adjusted resource offer set based on one or more adjustment data objects, where the apparatus 900 may receive the adjusted resource offer set from the client device after saving and / or saving and submitting the adjusted resource offer set by an offer control user via the client device.
[0262] At block 1222, the apparatus 900 includes means, such as communications circuitry 908, input / output circuitry 906, processor 902, etc., for generating a control signal or control signals that cause a renderable object including an approval interface to be displayed at a second one of the one or more client devices. The second one of the one or more client devices may be an approval device associated with an offer approval user authenticated with the apparatus 900 for the authenticated session. The control signal(s) may be transmitted, for example over a network, to cause rendering of the approval interface.
[0263] The approval interface may include the adjusted resource offer set received and submitted from the client device associated with the offer control user, and / or additional information (such as a dashboard) for analyzing the adjusted resource offer set. For example, the approval interface may additionally include metrics of an offer analysis dataset calculated and / or otherwise determined based on the adjusted 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 adjusted resource offer set. In some embodiments, the dashboard and metric(s) of the offer analysis dataset in the approval interface may include the same elements rendered in the offer adjustment interface. The device may cause the rendering on the approval device when an offer approval user accesses the device via the approval device.
[0264] At block 1224, the apparatus 900 includes means, such as communications circuitry 908, processor 902, etc., or a combination thereof, for receiving an offer acceptance control signal including an offer status indicator from an acceptance device. The offer acceptance control signal may be received from the acceptance device in response to user engagement with the acceptance interface. The offer status indicator may represent an acceptance status indicator (e.g., when an offer acceptance user analyzes and / or accepts the adjusted resource offer set) or a rejection status indicator (e.g., when an offer acceptance user analyzes and / or rejects the adjusted resource offer set). The offer status indicator may be received in response to user engagement with the acceptance interface, e.g., in response to user engagement with an offer acceptance component or an offer rejection component of the acceptance interface.
[0265] At block 1226, the apparatus 900 includes means, such as the data management circuitry 910, the communications circuitry 908, the processor 902, etc., or a combination thereof, for storing the adjusted resource offer set associated with the regional program identifier, the collection period data object, and the offer status indicator. In some embodiments, the apparatus is capable of storing the adjusted resource offer set and / or the offer approval status associated with the adjusted resource offer set such that each is retrievable using the regional program identifier and the collection period data object. The apparatus may store the adjusted resource offer set and / or the offer approval status in a database, for example embodied by the resource offer generation system database 802C.
[0266] If the offer acceptance status is an accepted status, the flow may end. If the offer acceptance status is a rejected status, the flow may return to block 1218 for adjustment by the offer control user via the client device. This cycle may continue until an offer control user acceptance status is received for the adjusted resource offer set. The accepted resource offer set may be used to provide one or more offers to various third party entities for the purchase of such resources.
[0267] 12B illustrates a flowchart of an example process 1200B for generating a trusted resource characteristic data set based on applying one or more untrusted third-party resource characteristic data sets and one or more characteristic data objects from a distributed user platform to an exception detection model according to some embodiments of the present disclosure. The operations illustrated with respect to the example process 1200 may be performed by a resource offer generation system embodied by the device 900, for example.
[0268] One non-limiting exemplary use for generating a trusted resource characteristic dataset based on one or more untrusted third party resource datasets and a distributed resource characteristic dataset is for generating a fair market offer set for acquiring used mobile devices. Each untrusted third party resource characteristic dataset can include price characteristics for various used mobile devices associated with various resource set identifiers, where each untrusted third party resource characteristic dataset is associated with a different third party entity. The untrusted third party resource characteristic dataset may include historical prices at which the third party entities purchased used mobile devices for the various resource set identifiers. However, the untrusted third party resource characteristic dataset is unreliable as a fair price characteristic for each resource because the price characteristics may be associated with exception periods (e.g., a third party entity may offer a promotion that increases the price of a particular used mobile device even though the value of the device is decreasing).
[0269] In this regard, the distributed resource characteristic dataset is not subject to promotions because the pricing characteristics are for offers for acquisition and / or distribution of resources by individual users of the distributed user platform. Unlike third-party entities that are commercial resellers, individuals do not apply exception periods (such as promotion periods for specific resources) to pricing characteristics for various resources. However, trusted sellers of used mobile devices generally receive higher prices for certain resources, so the distributed resource characteristic dataset is not accurate for purposes of generating a fair market offer set. Generating a trusted resource characteristic dataset via an exception detection model removes the deficiency of trusting either a dataset associated with one or more third-party entities and a dataset associated with the distributed resource characteristic dataset.
[0270] At block 1252, the apparatus 900 includes means, such as data management circuitry 910, communication circuitry 908, processor 902, etc., or a combination thereof, for retrieving an untrusted third party resource characteristic dataset. The untrusted third party resource characteristic dataset may include one or more records associated with one or more third party offerings of resources by a third party entity. For example, in some embodiments, the untrusted third party resource characteristic 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 particular date. In some embodiments, the resource may be a used mobile device.
[0271] In some embodiments, the untrusted third party characteristic dataset may be scraped from one or more web services accessible via communication with a third party device, such as a server, associated with the third party entity. The apparatus 900 may include means for performing scraping and / or be associated with one or more systems for performing scraping, and may retrieve the untrusted third party characteristic dataset from an updated repository upon completion of scraping. In some embodiments, the untrusted third party resource characteristic dataset may be retrieved from a third party device associated with the third party entity. For example, via one or more APIs, the apparatus 900 may communicate with a server and / or an accessible repository associated with the third party entity to retrieve the untrusted third party resource characteristic dataset. In other embodiments, the untrusted third party resource characteristic dataset may be retrieved from a third party device associated with a different third party entity, such as a data aggregator.
[0272] At block 1254, the apparatus 900 includes means, such as data management circuitry 910, communication circuitry 908, processor 902, etc., or combinations thereof, for retrieving a distributed resource characteristic dataset associated with a distributed user platform. The distributed resource characteristic dataset may include one or more records associated with offerings generated by one or more distributed users of resources offered via the distributed user platform. In some embodiments, the distributed user platform may enable users to offer to buy and / or sell resources to other users of the distributed user platform at any price the user desires. Examples include, but are not limited to, distributed user platforms such as eBay™, craigslist™, Amazon marketplace™, Facebook marketplace™, etc. Each record may represent the price of a used mobile device offered by a user on a particular date via a particular distributed user platform. Each record may include or be otherwise associated with, for example, an offer price, a resource set identifier, and / or a timestamp.
[0273] In some embodiments, the distributed resource data set may be scraped from one or more web services accessible via communication with a device associated with the distributed user platform, such as, for example, a server. The apparatus 900 may include means for performing scraping and / or be associated with one or more systems for performing scraping, and may retrieve the distributed resource characteristic data set from an updated repository upon completion of scraping. In some embodiments, the distributed resource characteristic data set may be retrieved from a device associated with the distributed user platform. For example, via one or more APIs, the apparatus 900 may communicate with a server associated with the distributed user platform and / or an accessible repository to retrieve the distributed resource characteristic data set. In other embodiments, the distributed resource characteristic data set may be retrieved from a device associated with a different third party entity, such as, for example, a data aggregator.
[0274] The apparatus may generate a trusted resource characteristic dataset by applying at least the untrusted third-party resource characteristic dataset (or multiple untrusted third-party resource characteristic datasets) and the distributed resource characteristic 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 a particular characteristic. The exception detection model, in some embodiments, may be embodied by one or more algorithms or machine learning models. In this regard, applying at least the untrusted third-party resource characteristic dataset and the distributed resource characteristic dataset to the exception detection model may include one or more of blocks 1256-1278.
[0275] At block 1256, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, or the like, or a combination thereof, for integrating the untrusted third party resource characteristic dataset with the distributed resource characteristic dataset. Integrating the untrusted third party resource characteristic dataset with the distributed resource characteristic dataset may include one or more pre-processing steps to align, organize, and / or otherwise structure the datasets for comparison.
[0276] In some embodiments, the untrusted third-party resource characteristic dataset and the distributed resource characteristic dataset are aligned based on a temporal alignment. Using a third-party resource pricing dataset as the untrusted third-party resource characteristic dataset and a distributed resource pricing dataset as the distributed resource characteristic dataset, for example, the third-party resource pricing dataset may include a plurality of records, each including at least a resource price offered by a 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 a plurality of records, each including at least a resource price offered via a distributed user platform and an associated timestamp (e.g., representing the date the price was offered via the distributed user platform). An exemplary temporal alignment may align the third-party resource pricing dataset and the distributed resource pricing dataset based on the timestamp for each record, for example, such that records associated with the same date may be compared.
[0277] In some embodiments, the untrusted third-party resource characteristic data set and the distributed resource characteristic data set are aligned based on temporal alignment and resource set identifier alignment. Continuing with the example of the third-party resource pricing data set and the distributed resource pricing data set, each record in the third-party resource pricing data set and the distributed resource pricing data set may also include or be otherwise associated with a particular resource set identifier. Based on the resource set identifier in or associated with each record, the untrusted third-party resource data set and the distributed resource pricing data set may be aligned such that records associated with the same date and the same resource set identifier may be compared.
[0278] At block 1258, the apparatus 900 includes means, such as model performance circuitry 912, processor 902, etc., or a combination thereof, for identifying an offset between the untrusted third party resource characteristic dataset and the distributed resource characteristic dataset. In some embodiments, the apparatus includes means for comparing a first characteristic of a first resource in the untrusted third party resource characteristic dataset with a first characteristic of a first resource in the distributed resource characteristic dataset from the distributed user platform to identify an offset. In some embodiments, the first characteristic may be a resource price, for example, if the untrusted third party resource dataset includes a third party resource pricing dataset and the distributed resource characteristic dataset includes a distributed resource pricing dataset. In some such embodiments, the offset may represent a difference in price for a particular resource set identifier for a given time interval (e.g., daily, weekly, etc.) between the untrusted third party resource characteristic dataset and the distributed resource characteristic dataset.
[0279] At block 1260, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, etc., or a combination thereof, for identifying an exception period set including at least one exception period in the untrusted third-party resource characteristic data set based on the deviation of the offset. For example, the deviation may be a change in the offset from an expected level, a determined level, or an average level. In some embodiments, for example, each exception period may represent a time interval during which a particular resource set identifier is offered by a third-party entity at an elevated 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 a timestamp intermediate between the first timestamp and the second timestamp.
[0280] In some embodiments, an exception period may be identified when a deviation in the offset meets an exception deviation threshold. In some embodiments, the apparatus 900 may identify, determine, retrieve, or otherwise associate with the exception deviation threshold. In some embodiments, for example, the apparatus 900 may include means for identifying a first timestamp at which a deviation in the offset meets the exception deviation threshold. For example, in some embodiments, a deviation in the offset meets the exception deviation threshold when the deviation is greater than or equal to the exception deviation threshold. Using a price characteristic as an example, the exception deviation threshold may be met when a deviation in the offset exceeds a particular value or percentage and is due to a resource price associated with an untrusted third party resource characteristic dataset exceeding a set amount or a set percentage greater than a resource price associated with a distributed resource characteristic dataset. The apparatus 900 may include means for identifying a second timestamp at which a deviation in the offset does not meet the exception deviation threshold. In some embodiments, for example, the deviation may be a desired amount of standard deviation from an expected or average deviation based on historical pricing characteristics over a predetermined non-exception time interval (e.g., 15 weeks not including the exception period).
[0281] Additionally, for example, in some embodiments, a deviation of the offset does not satisfy the exception deviation threshold when the deviation is less than or equal to the exception deviation threshold. Returning to the price characteristic as an example, it is possible that the exception deviation threshold is not met when the deviation of the offset returns to or falls below a particular value or percentage, such as a resource price associated with an untrusted third party resource characteristic dataset returning to a standard operating range from a resource price associated with a distributed characteristic dataset. A price characteristic returning to within a standard operating range indicates the end of an exception period, such as a promotional period.
[0282] At block 1262, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, etc., or a combination thereof, for removing at least one exception period from the untrusted third party resource characteristic dataset to generate an updated untrusted third party resource characteristic dataset. In some embodiments, removing the untrusted third party resource characteristic dataset includes marking each record associated with the exception period as an exception such that these records may be ignored. By marking the exception period, the untrusted third party resource characteristic dataset may be used for data analysis, for example, by rendering an indication of the untrusted third party resource characteristic dataset in one or more interfaces provided to the offer control user and / or the approval user. In other embodiments, records associated with the exception period may be erased from the untrusted third party resource characteristic dataset.
[0283] At block 1264, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, etc., or a combination thereof, for generating a trusted resource characteristic dataset based on at least the updated untrusted third-party resource characteristic dataset. In some embodiments, for example, the trusted resource characteristic dataset may include the updated untrusted third-party resource characteristic set. In other embodiments, the trusted resource characteristic dataset may include at least an average resource price characteristic for a given resource set identifier by averaging remaining price characteristics for each record associated with the resource set identifier. The trusted resource characteristic dataset may include, for example, a maximum price characteristic and / or an average price characteristic for various resources or resource set identifiers associated with offers by third-party entities associated with the updated untrusted third-party resource characteristic dataset.
[0284] In some embodiments, the multiple untrusted third party resource characteristic data sets may be updated and compared such that generating the trusted resource characteristic data set is based on a comparison of the multiple untrusted third party resource characteristic data sets. In this regard, at block 1266, the apparatus 900 includes means, such as the data management circuitry 910, the communication circuitry 908, the processor 902, etc., or a combination thereof, for retrieving the second untrusted third party resource characteristic data set. The second untrusted third party resource characteristic data set may include one or more records associated with one or more third party offerings of resources by the 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 characteristic data set 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 apparatus 900 may include means for performing scraping and / or be associated with one or more systems for performing scraping, and may retrieve the second untrusted third party characteristic data set from an updated repository upon completion of scraping. In some embodiments, the second untrusted third party resource characteristic data set may be retrieved from a second third party device associated with the second third party entity. For example, via one or more APIs, the apparatus 900 may communicate with a second server associated with the second third party entity and / or an accessible second repository to retrieve the second untrusted third party resource characteristic data set. In other embodiments, the second untrusted third party resource characteristic data set may be retrieved from a second third party device associated with a different third party entity, such as a data aggregator. In some embodiments, the second untrusted third party characteristic data set may be retrieved in the same manner as the earlier initially retrieved untrusted third party characteristic data set. At block 1270, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, or the like, or a combination thereof, for identifying a second offset between the untrusted third party resource characteristic data set and the distributed resource characteristic data set.
[0286] At block 1272, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, etc., or a combination thereof, for identifying a second set of exception terms including at least one exception term in the second unreliable third party resource characteristic dataset based on a second deviation of the second offset. For example, the second deviation may be a change in the offset from an expected level, a determined level, or an average level based on the distributed resource characteristic dataset.
[0287] In some embodiments, an exception period in the second untrusted third party resource characteristic dataset is identified when the second deviation of the second offset meets the exception deviation threshold or a second exception deviation threshold associated with the second untrusted third party resource characteristic dataset. It should be appreciated that the offset and deviation may define an expected operating range of a characteristic, e.g., a price range for a price characteristic associated with a particular resource set identifier.
[0288] At block 1274, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, etc., or a combination thereof, for removing the exception period set from the second untrusted third party resource characteristic dataset to generate an updated second untrusted third party resource characteristic dataset. In some embodiments, removing the exception period set from the second untrusted third party resource characteristic dataset includes marking each record within or associated with each exception period as an exception such that these records may be ignored. By marking the exception periods, the second untrusted third party resource characteristic dataset may be used for data analysis. In other embodiments, records within or associated with the exception periods may be erased from the untrusted second third party resource characteristic dataset.
[0289] At block 1276, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, or the like, or a combination thereof, for comparing the updated untrusted third party resource characteristic dataset with the updated second untrusted third party resource characteristic dataset. In some embodiments, the updated untrusted third party resource characteristic dataset and the updated second untrusted third party resource characteristic dataset may be compared to determine a greater characteristic, such as a greater price characteristic, for a particular resource set identifier between the two datasets. In other embodiments, multiple untrusted third party resource characteristic datasets may be compared.
[0290] At block 1278, the apparatus 900 includes means, such as the model performance circuitry 912, the processor 902, etc., or a combination thereof, for generating a trusted resource characteristic data set based on a comparison between the updated untrusted third-party resource characteristic data set and the updated second untrusted third-party resource characteristic data set. In some embodiments, the trusted resource characteristic data set may be generated to include specific resource characteristics from each of the data sets based on the comparison. For example, if the data sets include resource pricing characteristics, the trusted resource characteristic data set may include a maximum pricing characteristic for each resource set identifier based on a comparison between two or more updated untrusted third-party resource data sets.
[0291] For example, in some embodiments, the authoritative resource characteristic data set includes fair market offer data objects for various resource set identifiers. The fair market offer data objects can include pricing characteristics, such as fair market offer values, for each resource set identifier, where the pricing characteristics are generated based on the comparison. For example, the pricing characteristics for a particular resource set identifier can be a maximum pricing characteristic among various updated untrusted third party resource characteristic data sets for the resource set identifier. The updated untrusted third party resource characteristic data sets can include maximum pricing characteristics for a particular resource set identifier associated with various third party entities. For example, an average pricing characteristic can be determined, for example, for a particular third party entity and a particular resource set identifier, by calculating an average pricing characteristic for the resource set identifier over a predetermined time interval (e.g., 15 weeks) with exception periods removed. An average pricing characteristic for the distributed user platform can then be determined, for example, based on the distributed resource characteristic data sets. The maximum pricing characteristic for a particular resource set identifier and for a particular third-party entity may then be determined by multiplying the average pricing characteristic for resource set identifiers associated with the distributed user platform by the average pricing characteristic for resource set identifiers associated with the third-party entity as a percentage of the average pricing characteristic for resource set identifiers associated with the distributed user platform (e.g., the average pricing characteristic for resource set identifiers associated with the third-party entity divided by the average pricing characteristic for resource set identifiers associated with the distributed user platform).
[0292] The maximum pricing characteristic for each resource set identifier and each third-party entity represented in each of the updated untrusted resource characteristic datasets can then be used to calculate a fair market offer value for the resource set identifier, where the fair market offer value may be embodied by a fair market offer data object or may be included in the trusted resource characteristic dataset associated with the particular resource set identifier. For example, the fair market offer value (e.g., the trusted pricing characteristic) may be determined as the maximum pricing characteristic of the maximum pricing characteristics for each third-party entity. Continuing with the used mobile device acquisition example, if a first updated untrusted third-party resource characteristic data set for third-party entity A is associated with a pricing characteristic of 90 units (e.g., dollars) for the particular resource set identifier, and a second updated untrusted third-party resource characteristic data set for third-party entity B is associated with a pricing characteristic of 85 units for the particular resource set identifier, and a third updated untrusted third-party resource characteristic data set for third-party entity C is associated with a pricing characteristic of 87 units for the particular resource set identifier, and a fourth updated untrusted third-party resource characteristic data set for third-party entity D is associated with a pricing characteristic of 93 units for the particular resource set identifier, then the trusted resource characteristic data set may include the pricing characteristic for the particular resource set identifier of 93 units as the maximum value among all updated untrusted third-party resource characteristic data sets. This pricing characteristic may be embodied as a fair market offer data object for the particular resource set identifier representing a fair market offer value for the resources associated with the particular resource set identifier during a non-exception (e.g., non-promotion) period.
[0293] The process 1250B for generating a trusted resource characteristic dataset similarly enables generation of a trusted characteristic set for other non-resource datasets from one or more untrusted datasets. For example, if the untrusted characteristic set is associated with an untrusted third-party entity, the untrusted characteristic dataset may be retrieved. A distributed characteristic dataset may then be collected from or associated with the distributed user platform. An offset between the untrusted third-party characteristic dataset and the distributed characteristic dataset may then be identified. Exception periods may be identified based on deviations in the offset, and the exception periods may be removed from the untrusted characteristic dataset to generate an updated untrusted resource characteristic dataset. The updated untrusted resource characteristic dataset may then be used to generate a trusted characteristic dataset, and / or multiple updated untrusted resource characteristic datasets may be generated such that a trusted characteristic dataset may be generated based on a comparison between multiple updated untrusted resource characteristic datasets. The use of resource pricing in the above description should not be considered as limiting the scope and spirit of the disclosure herein. Exemplary User Interface 13-15 illustrate user interfaces of example embodiments. For example, some systems, methods, and computer program products may be configured to render or otherwise cause the rendering of one or more of the example interfaces. It should be understood that in some embodiments, the various components illustrated in each interface may be embodied by a number of known interface components configured to receive a myriad of user input types. All interface components, both alone and in combination, are exemplary and are not intended to limit the scope and spirit of the disclosure herein.
[0294] In some embodiments, each of the interfaces may be rendered by a client device in response to receiving a control signal that includes a renderable data object. The control signal may be generated and / or configured by the resource offer generation system, for example, for transmission to one or more client devices. In some embodiments, the renderable data object may be generated and / or configured by the resource offer generation system, for example, to include the interface to be rendered.
[0295] FIG. 13 illustrates an example offer adjustment interface 1300 according to an embodiment of the present disclosure. The offer adjustment interface 1300 is rendered on a client device associated with an offer control user and may be generated, for example, by a resource offer generation system upon generation of a resource offer set. 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 multiple columns of information associated with and including the generated resource offer set. The offer analysis table includes a resource offer value column 1302 that includes a resource offer value for each resource offer data object in the generated resource offer set. Each row of the resource offer column 1302 is configured to receive user input to adjust the corresponding resource offer value of the resource offer data object. For example, the offer control user may engage a particular row to enter 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, a market intelligence data 1308, and a system generated data column 1310. A system generated data column, such as the system generated data column 1310, includes data generated and output by one or more of a forecasting system, such as the forecasting system 102 embodied by the apparatus 200, and / or a resource offer generation system, such as the resource offer generation system 802 embodied by the apparatus 900. In some embodiments, the one or more system generated data columns may include data generated and output by one or more of a forecasting system, such as the forecasting system 102 embodied by the apparatus 200, and / or a resource offer generation system, such as the resource offer generation system 802 embodied by the apparatus 900, in combination with market intelligence data, such as an assumed margin associated with each resource offer data object, 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, an indication of at least a portion of the offer analysis dataset rendered as text. The indications of the offer analysis dataset may be rendered without overlap from the offer analysis table 1322 and the dashboard 1320 to enable dynamic and efficient visualization and analysis while navigating the offer analysis table 1322 and / or performing adjustments. The offer analysis dataset may include various 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 a profit per resource derived from the generated resource offer set. Additionally or alternatively, in some embodiments, the offer analysis dataset further includes a profit margin 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 a negative margin value (e.g., associated with an assumed selling price that does not exceed the resource offer value). In some embodiments, at least a portion of the offer analysis dataset is dynamically updated as offer control users adjust one or more resource offer values of various resource offer data objects in the resource offer set. Indicators of the offer analysis dataset may also be updated to reflect the updated offer analysis dataset.
[0298] The offer analytics interface 1300 includes analytic table management components 1314. Each of the analytic table management components 1314 may be configured to filter, refine, or otherwise affect the data rendered via the offer analytics table 1322. For example, one or more analytic table management components may be provided to filter rows based on particular values in particular columns, such as based on a resource set identifier or other resource attributes (e.g., carrier, make, model / category type, etc.).
[0299] The offer analysis interface includes an offer save component 1316. The offer save component 1316 may be configured to enable saving of the adjusted resource offer set without submitting it for approval. For example, the offer save component 1316 may be configured to cause transmission of a request to store the adjusted resource offer set accessible by the offer control user, e.g., to the resource offer generation system 802. Once saved, the adjusted resource offer set may be later retrieved and used when rendering the offer adjustment interface (e.g., in another session).
[0300] The offer analysis interface includes an offer submission component 1318. The offer submission component 1318 may be configured to enable submission of an adjusted resource offer set for approval by an offer approval user. The adjusted resource offer set may include resource offer data objects 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 submission of the adjusted resource offer set, the offer submission component 1318 may be configured to cause transmission of the adjusted resource offer set, such as to the resource offer generation system 802, for example. The adjusted resource offer set may be transmitted as part of or otherwise associated with a request to store the submitted adjusted resource offer set.
[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 the offer analysis table 1322. For example, the external management component 1324 may include one or more components for uploading a file containing at least a set of resource offers, such as in Microsoft Excel™, 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 optionally exported as an external file type (e.g., Microsoft Excel™) and download.
[0302] The offer adjustment interface 1300 further includes a dashboard portion 1320. The dashboard portion 1320 may be rendered without overlap from the metrics of the offer analytics dataset 1304, as well as the offer analytics table 1322 and the dashboard 1320 to allow efficient visualization and analysis while navigating the interface offered by the dashboard portion 1320. The dashboard portion 1320 may include one or more components for accessing one or more other interfaces associated with the resource offer sets and / or market intelligence data. The dashboard portion 1320 specifically includes user interface components for accessing or otherwise causing the rendering of an offer strength interface, a market comparison interface, and a price strength interface.
[0303] FIG. 14 illustrates an example offer approval interface 1400 according to an embodiment of the present disclosure. The offer approval interface 1400 is rendered on an approval device associated with an offer approval user and may be generated by a resource offer generation system, for example, upon submission of an adjusted resource offer set by an offer control user. The offer approval interface 1400 includes an offer analysis table 1322 including a resource offer value column 1302 and the remaining columns 1306-1312. The resource offer value column 1302 may be rendered such that the resource offer value column 1302 is not adjustable. For example, the resource offer value column 1302 may not be configured to receive user input. The offer approval interface 1400 may additionally include a dashboard portion 1320 for accessing one or more of the various other interfaces described, and pricing analysis information 1304 based on the adjusted 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 approval of the adjusted resource offer set. For example, in response to user engagement by an offer approval user with the offer approval component 1402, the approval device may transmit an offer approval response including an offer approval status representing an approved status. The offer rejection component 1404 enables rejection of the adjusted resource offer set. For example, in response to user engagement by an offer approval user with the offer rejection component 1404, the approval device may transmit an offer approval response including an offer approval status representing a rejected status. In some embodiments, in response to user engagement by an offer approval user with the offer rejection component 1404, the approval device may cause rendering of an interface component (not shown) configured to create and submit an offer rejection message. For example, a text box configured to enable an offer acceptance user to create an offer rejection message, and a message submit button, where upon user engagement with the message submit button, the management device transmits an offer acceptance response including at least an offer acceptance status representing a rejected status and the created offer rejection message.
[0305] 15 illustrates an example market comparison interface 1500 according to an embodiment of the disclosure. The market comparison interface 1500 is rendered on a user device or an approval 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 to access 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 can be configured to toggle summary market data based on comparison with resource set identifiers marked as being in a promotional period, comparison with resource set identifier markets that are not in a promotional period, or all resource set identifiers. The component status of each of the competitor selection components 1502 can filter the market intelligence data used to generate the market overview visualization component 1506 and the market overview 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 a summary of resource offer values of resource offer data objects of a particular adjusted resource offer set. For example, the market overview visualization component 1506A may provide a summary of all resource offer values compared to a market average for a corresponding resource set identifier based on market intelligence data for all competitor entities. The market overview visualization component 1506B may provide a summary of all resource offer values compared to a market maximum for a corresponding resource set identifier (e.g., for a particular resource offer data object having a resource offer value for a particular resource set identifier, the highest offer value associated with a competitor entity for that resource set identifier) based on market intelligence data for all competitor entity visualization components.
[0309] The market comparison interface 1500 includes a market summary table 1508. The market summary table 1508 may include an aggregated summary of market intelligence data associated with all competitor entities. For example, the market summary table 1508 may include a number of resources within a predefined band compared to a reference metric. For example, the number of resources associated with resource offer data objects having resource offer values within a predefined range, represented by the predefined band, may be displayed. The band may be determined based on a regional program identifier for a selected regional program data object.
[0310] A dashboard, such as dashboard 1320 of 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 a third party offer value associated with a third party compared to an average selling price for a particular 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.). Additionally, the price trend interface may render indicators for promotional periods. Additional implementation details Although an exemplary processing system is described in FIG. 2, implementations of 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, including the structures disclosed herein and their structural equivalents, or in a combination of one or more of these.
[0311] The subject matter and embodiments of the operations described herein may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or a combination of one or more of them. The subject matter described herein may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a computer storage medium for execution by or to control the operation of an information / data processing apparatus. Alternatively, or in addition, the program instructions may be encoded in an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information / data for transmission to a suitable receiver apparatus for execution by the information / data processing apparatus. The computer storage medium may be or may be included in a computer readable storage device, a computer readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Furthermore, t...
Claims
1. 1. A method for allocating a constrained resource set in a dynamic environment, comprising: receiving a request data object from a client device associated with a channel profile; Receiving a hierarchical parameter data object; Receiving an attenuation parameter data object; extracting a resource request set from the request data object, the resource request set including a plurality of request parameters; Extracting a plurality of layered parameters from the layered parameter data object; extracting a plurality of attenuation parameters from the attenuation parameter data object; assigning the channel profile to a first tier from among a plurality of tiers, where assigning the channel profile to the first tier includes applying the plurality of tiered parameters and a first required parameter from the plurality of required parameters to a first model; generating an adjusted resource requirement set associated with the user by applying a decay curve to a second requirement parameter from the plurality of requirement parameters, the decay curve being based at least in part on the plurality of decay parameters; determining whether the channel profile satisfies each of a plurality of threshold conditions based on the first tier and the adjusted set of resource requirements; responsive to determining that the channel profile satisfies each of the plurality of threshold conditions, applying the adjusted resource requirement set and the first hierarchy to a second model to generate a resource allocation set for the channel profile; generating a control signal to cause a user interface to display a renderable object including an indication of the resource allocation set.
2. the plurality of tiering parameters includes a portfolio level volume associated with a channel profile; 2. The method of claim 1 , further comprising: scaling the portfolio level volume associated with the channel profile based at least in part on assigning the portfolio level volume associated with the channel profile to a position in a ranked list of portfolio level volumes.
3. the plurality of tiering parameters including an expected portfolio level profit margin associated with a channel profile; 2. The method of claim 1, further comprising: scaling the expected portfolio level profit margin associated with the channel profile based at least in part on assigning the expected portfolio level profit margin associated with the channel profile to a position within a ranked list of expected portfolio level profit margins.
4. (i) the plurality of hierarchical parameters includes an entropy parameter associated with a channel profile; (ii) the entropy parameter associated with the channel profile is represented 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; 2. The method of claim 1, further comprising: scaling the entropy parameter associated with the channel profile based 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 of claim 1 , wherein the plurality of tiering parameters includes an indication of a geographic location associated with a channel profile.
6. the plurality of hierarchical parameters includes a timing parameter associated with a relationship between a channel profile and a first entity; 2. The method of claim 1, further comprising: scaling the timing parameter based at least in part on calculating a number of days reflected by the timing parameter and assigning the number of days to a position in a ranked list of timing parameters.
7. the plurality of tiering parameters includes an indication of an audit status of a channel profile; 2. The method of claim 1, further comprising: scaling the indication of the audit status of the channel profile by at least converting the indication of the audit status of the channel profile to a single digit binary value.
8. the plurality of tiering parameters includes an indication of an exclusivity status of a channel profile; 2. The method of claim 1, further comprising: scaling the indication of the exclusivity status of the channel profile by at least converting the indication of the exclusivity status of the channel profile to a single digit binary value.
9. The method of claim 1 , wherein the plurality of attenuation parameters comprises: (i) a set of pricing history information associated with the plurality of channel profiles; and (ii) a set of pricing history information associated with a public auction market.
10. The method of claim 1 , wherein the plurality of demand parameters includes a requested quantity of at least one inventory element.
11. The method of claim 1 , wherein the plurality of request parameters comprises a list of SKU identifiers associated with a plurality of inventory elements.
12. The method of claim 1 , wherein the plurality of demand parameters comprises a first bid price for a first inventory element.
13. The method of claim 1 , wherein the plurality of demand parameters comprises a plurality of bids associated with a plurality of inventory elements.
14. The method of claim 1 , wherein the plurality of request parameters comprises a set of properties associated with a channel profile.
15. and assigning the channel profile to the first tier from a plurality of tiers, where assigning the channel profile to the first tier includes applying the plurality of tiered parameters and the first required parameter from the plurality of required parameters to a first model, the assigning comprising: determining whether a parameter in the plurality of stratified parameters includes an outlier; and removing the outliers from the plurality of hierarchical parameters.
16. 2. The method of claim 1, further comprising: generating the adjusted resource requirement set associated with the user by applying the decay curve to the second requirement parameter from the plurality of requirement parameters, the decay curve being based at least in part on the plurality of decay parameters; and generating comprises applying the plurality of decay parameters to a multivariate adaptive regression spline (MARS) model.
17. The method of 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 of claim 1 , further comprising generating a control signal that causes the renderable object including the indication of the resource allocation set to be displayed on a user interface of the client device.
19. 1. An apparatus for determining a predicted future demand for a resource in a dynamic environment, the apparatus comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to cause the apparatus, using the at least one processor, to: receiving a request data object from a client device associated with a channel profile; Receiving a hierarchical parameter data object; Receiving an attenuation parameter data object; extracting a resource request set from the request data object, the resource request set including a plurality of request parameters; Extracting a plurality of layered parameters from the layered parameter data object; extracting a plurality of attenuation parameters from the attenuation parameter data object; assigning the channel profile to a first tier from among a plurality of tiers, where assigning the channel profile to the first tier includes applying the plurality of tiered parameters and a first required parameter from the plurality of required parameters to a first model; generating an adjusted resource requirement set associated with the user by applying a decay curve to a second requirement parameter from the plurality of requirement parameters, the decay curve being based at least in part on the plurality of decay parameters; determining whether the channel profile satisfies each of a plurality of threshold conditions based on the first tier and the adjusted set of resource requirements; responsive to determining that the channel profile satisfies each of the plurality of threshold conditions, applying the adjusted resource requirement set and the first hierarchy to a second model to generate a resource allocation set for the channel profile; generating a control signal to cause a user interface to display a renderable object including an indication of the resource allocation set.
20. 1. A computer program product comprising at least one non-transitory 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 channel profile; Receiving a hierarchical parameter data object; Receiving an attenuation parameter data object; extracting a resource request set from the request data object, the resource request set including a plurality of request parameters; Extracting a plurality of layered parameters from the layered parameter data object; extracting a plurality of attenuation parameters from the attenuation parameter data object; assigning the channel profile to a first tier from among a plurality of tiers, where assigning the channel profile to the first tier includes applying the plurality of tiered parameters and a first required parameter from the plurality of required parameters to a first model; generating an adjusted resource requirement set associated with the user by applying a decay curve to a second requirement parameter from the plurality of requirement parameters, the decay curve being based at least in part on the plurality of decay parameters; determining whether the channel profile satisfies each of a plurality of threshold conditions based on the first tier and the adjusted set of resource requirements; in response to determining that the channel profile satisfies each of the plurality of threshold conditions, applying the adjusted resource requirement set and the first hierarchy to a second model to generate a resource allocation set for the channel profile; and generating control signals to cause a user interface to display a renderable object including an indication of the resource allocation set.