Method for controlling remote system settings using cloud-based control platform

In a general aspect, a cloud-based control platform remotely controls variable settings on a remotely-controlled system. In some aspects, the platform maintains a database of data objects for assets, and the data objects include static and dynamic hyperparameters associated with the asset and a template that specifies values of a variable associated with the asset for future time points. The platform updates a template for a data object by calculating target values for the variable for the future time points based on a target criterion, communicating with remote computer systems to determine current values of the dynamic hyperparameters, calculating scaled values for the future time points by applying a determined ratio to the target values, adjusting the scaled values based on the static hyperparameters, applying an override value to the adjusted scaled values. The remotely-controlled system is updated according to the updated template at each of the future time points.

BACKGROUND

The following description relates to a computer-implemented, cloud-based control platform.

Many types of systems are controlled via Internet. For example, control data for internet-of-things (IoT) devices such as thermostats, cameras, televisions, alarm systems and the like are often provided from a remote Internet-based system that generates the control data based on user inputs. As another example, Internet-based systems may be used to actively manage and control industrial equipment, manufacturing systems, remotely-controlled aircraft and vehicles, and other complex systems.

DETAILED DESCRIPTION

In some aspects of what is described here, a computer-implemented, cloud-based data management platform interacts with disparate computer systems over various networks and manages large amounts of data with precise timing. The cloud-based data management platform may be used in a variety of contexts where large amounts of data need to be managed, where seamless and precisely-timed communications with disparate computer systems is needed, and where assets need to adjust to changing conditions at precise times. Examples of such contexts include thermostats, drones, automated cleaning robots, automobiles with remote-starting capability, sprinkling systems for a lawn, lighting systems, or any other device for which changing conditions can require an update in operations. For example, the detection of rainfall can result in a remotely-controlled automatic lawn sprinkling system being directed to defer its activation. In another example, seasonal changes in ambient light can result in a remotely-controlled lighting system adjusting its schedule.

Many devices and systems, while executing against a programmed schedule, are unable to adjust their schedule in the presence of mitigating factors, e.g., a sprinkler system that is unable to recognize that it is raining. Determination of such an external factor can allow deferral of unnecessary watering. In addition, being able to use a measurement of the moisture in the soil over time as an input to a watering schedule can result in healthier turf as well as a more economical and environmentally-friendly use of water.

In another example, a remotely-controlled home thermostat with a temperature schedule can benefit from an awareness of outside temperature and the overall load on the power grid. Data on the change in outside temperature over the course of the day can result in a more efficient and economical use of heat and/or air conditioning. Furthermore, a schedule for household temperature settings over the course of a day can be tuned by information on overall power consumption across a power system. A schedule for cooling, on an unseasonably hot day, can be adjusted using localized inputs so as to avoid taxing the power grid.

In some aspects of what is described here, a cloud-based computer system can leverage virtually unlimited computing resources to generate precisely-timed control information for remotely-controlled systems. Examples of remotely-controlled systems include a thermostat, a drone, an automated cleaning robot, an automobile with remote-starting capability, a sprinkling system for a lawn, a lighting system, or any other mechanism in which a response is desired for the existence of a condition. Such a remotely-controlled system can rely on a series of iterative adjustments for future time points by comparing current values of variables with target criteria and, as a result, iteratively updating the remotely-controlled system to improve its accuracy and efficiency.

By deploying such computations and control functions on a cloud-based control platform, the resources of the remotely-controlled systems can be conserved and utilized for system operation. In addition, the cloud-based control platform can serve as a shared resource for a number of remotely-controlled systems. For example, a cloud-based control platform can provide a centralized, efficient solution for controlling operations of disparate systems in a global network managed by an enterprise or other entity.

FIG.1is a block diagram showing aspects of an example computing environment1000. The example computing environment1000shown inFIG.1includes three nodes—two cloud nodes1002,1010operating as a cloud-based control platform1012, and a remotely-controlled system1016. The nodes communicate with each other over a network1014. The computing environment1000may include additional or different features, and the components in a computing environment may be configured to operate as shown inFIG.1or in another manner.

Nodes in the computing environment1000may have a client-server relationship. For example, the cloud-based control platform1012can be a server and the remotely-controlled system1016can be its client. In some implementations, nodes in the computing environment1000may have a peer-to-peer relationship. Nodes may have another type of relationship in the computing environment1000. Similarly, the remotely controlled system1016may include multiple nodes.

In the example shown inFIG.1, the example nodes1002,1010and the remotely-controlled system1016each have computational resources (e.g., hardware, software, firmware) that are used to perform computational tasks and communicate with other nodes. As shown inFIG.1, the example node1002includes a processor1004, a memory1006, and an interface1008. Each of the nodes1002,1010, and1016may include the same, additional, or different components. The nodes1002,1010, and1016may be configured to operate as shown and described with respect toFIG.1or in another manner.

In the example node1002shown inFIG.1, the memory1006can include, for example, random access memory (RAM), a storage device (e.g., a writable read-only memory (ROM) or others), a hard disk, or another type of storage medium. The example memory1006can store instructions (e.g., computer code, a computer program, etc.) associated with an operating system, computer applications, and other resources. The memory1006can also store application data and data objects that can be interpreted by one or more applications or virtual machines running on the node1006. The node1006can be preprogrammed, or it can be programmed (and reprogrammed), by loading a program from another source (e.g., from a DVD-ROM, from a removable memory device, from a remote server, from a data network, or in another manner). In some cases, the memory1006stores computer-readable instructions for software applications, scripts, programs, functions, executables, or other modules that are interpreted or executed by the processor1004.

In the example node1002shown inFIG.1, the processor1004can execute instructions, for example, to generate output data based on data inputs. For example, the processor1004can run computer programs by executing or interpreting the software, scripts, programs, functions, executables, or other modules stored in the memory1006. The example processor1004shown inFIG.1can include one or more chips or chipsets that include analog circuitry, digital circuitry, or a combination thereof. In some cases, the processor1004includes multiple processor devices such as, for example, one or more main processors and one or more co-processors. In some instances, the processor1004coordinates or controls operation of other components of the node1002, such as, for example, user interfaces, communication interfaces, and peripheral devices.

In the example node1002shown inFIG.1, the interface1008provides communication with other nodes or devices. In some cases, the interface1008includes a wireless communication interface that provides wireless communication under various wireless protocols, such as, for example, Bluetooth, Wi-Fi, Near Field Communication (NFC), GSM voice calls, SMS, EMS, or MMS messaging, wireless standards (e.g., CDMA, TDMA, PDC, WCDMA, CDMA2000, GPRS) among others. Such communication may occur, for example, through a radio-frequency transceiver or another type of component. In some cases, the interface1008includes a wired communication interface (e.g., USB, Ethernet) that can be connected to one or more input/output devices, such as, for example, a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, for example, through a network adapter.

The example network1014can include all or part of a connector, a data communication network, or another type of communication link. For example, the network1014can include one or more wired or wireless connections, one or more wired or wireless networks or other communication channels. In some examples, the network106includes a Local Area Network (LAN), a Wide Area Network (WAN), a private network, a Virtual Private Network (VPN), a public network (such as the Internet), a peer-to-peer network, a cellular network, a Wi-Fi network, a Personal Area Network (PAN) (e.g., a Bluetooth low energy (BTLE) network, a ZigBee network, etc.) or other short-range network involving machine-to-machine (M2M) communication, or another type of data communication network.

In the example shown inFIG.1, the example cloud-based control platform1012sends control data to the remotely-controlled system1016, and the remotely-controlled system1016adjusts local settings based on the control data. In some cases, the cloud-based control platform1012maintains data objects for assets controlled by the cloud-based control platform1012, and the data objects include templates that specify values of a variable setting associated with the assets.

The example remotely-controlled system1016can be, for example, an internet-of-things device, a computer system, or another type of system that is controlled by a computer. In an example, a remotely-controlled lighting system adjusts its on- and off-times based on seasonal changes in the times of dusk and dawn, and the cloud-based control platform1012controls the variable light setting of the remotely-controlled lighting system. In an example, photocells on the lighting system provide information to a cloud-based computer system. As a result, future time points of lighting are determined by the cloud-based control platform1012and communicated to the remotely-controlled lighting system.

In another example, to control power consumption, a remotely-controlled Internet of Things (IOT) household thermostat is adjusted based upon change in the outside temperature with additional information on power consumption across a power system, and the cloud-based control platform1012controls the variable thermostat settings. From a determination of a rate of change in outside temperature, the cloud-based control platform1012can adjust the thermostat from its normal setting to optimize air conditioning over time, while avoiding a usage of power that could destabilize the power grid. The cloud-based control platform1012can remotely control variable settings of other IOT devices in a similar manner.

In yet another example, a remotely-controlled irrigation system for an agricultural asset provides information regarding temperature changes and soil moisture levels throughout the day. As a result, the cloud-based control platform1012provides control data to adjust the location, time, and duration of irrigation across the growing season. The irrigation system can allow variations in daily temperature and soil moisture to revise seasonal plans based on local/current values.

In another example, a remotely-controlled computer system adjusts data and settings in response to control data provided by the cloud-based control platform1012. For example, the remotely-controlled computer system can be an internet-based service (e.g., a social network, an online banking system, a virtual meeting host, a sales platform, or another type of service), and the cloud-based control platform1012can specify variable settings of the internet-based service over time.

Accordingly, the cloud-based control platform1012can provide technical advantages and improvements over conventional systems. For instance, the cloud-based control platform1012can address the Internet-centric challenge of deploying precisely-timed updates for variable settings on a variety of systems that are controlled over the Internet. For instance, the updates for multiple different types of systems across global networks can be coordinated from a centralized control system that monitors hyperparameters, maintains and updates templates that specify variable settings over time, and continuously pushes updates to the remotely-controlled systems over the Internet. Accordingly, the process of maintaining and updating templates improves the operation and functioning of the particular technological environment of the remotely-controlled system. For example, the remotely-controlled system may operate more efficiently or precisely by updating local settings based on control data provided by the cloud-based control platform1012. Thus, the technical solution provided by the cloud-based control platform is necessarily rooted in computer technology, and overcomes a problem specifically arising in the realm of computer systems.

One specific example of a remotely-controlled computer system that can be controlled by the cloud-based control platform1012ofFIG.1is the secondary ticket market seller servers106shown inFIG.2, where ticket prices are an example of variable settings associated with remotely-controlled assets. In such cases, the cloud-based control platform1012can operate as ticket broker platform108shown inFIG.2that remotely controls the ticket prices on the secondary ticket market seller servers106. In some examples, the cloud-based control platform1012maintains a database (e.g.,116inFIG.2) of data objects for each remotely-controlled asset. The data objects for each remotely-controlled asset includes static hyperparameters and dynamic hyperparameters associated with the asset (e.g., the hyperparameters413shown inFIG.4or other types of hyperparameters). The data objects for each remotely-controlled asset also include a template (e.g., at332inFIG.4) that specifies values of a variable associated with the asset (e.g., ticket price) for a plurality of future time points. The cloud-based control platform1012can use an update process to determine an updated template for one of the data objects (e.g., as shown inFIG.4). The update process can include calculating target values for the variable for the plurality of future time points based on a target criterion (e.g., at410inFIG.4), communicating with one or more remote computer systems to determine current values of the dynamic hyperparameters, determining a ratio based on the current values of the dynamic hyperparameters, calculating scaled values for the plurality of future time points by applying the ratio to the target values (e.g., at411inFIG.4), determining an adjustment based on the static hyperparameters, calculating first modified values for the plurality of future time points by applying the adjustment to the scaled values (e.g., at415inFIG.4), calculating second modified values for the plurality of future time points by applying an override value to the first modified values (e.g., at426inFIG.4), and assigning the second modified values to the template. The cloud-based control platform1012can iteratively update the remotely-controlled system (e.g., the secondary ticket market seller servers106shown inFIG.2) according to the updated template at each of the plurality of future time points. Updating the remotely-controlled system can include identifying a next value of the variable, wherein the next value of the variable can be the value specified by the updated template for a time point associated with a current time, and communicating the next value to the remotely-controlled system with instructions to assign the next value of the variable to a setting associated with the remotely-controlled asset.

Another specific example of a remotely-controlled computer system that can be controlled by the cloud-based control platform1012ofFIG.1is a booking platform server for hotel rooms and other types of lodging (e.g., vacation rentals, by-owner rentals, etc), where lodging prices are an example of variable settings associated with remotely-controlled assets. In such cases, the cloud-based control platform1012can operate as a booking platform that remotely controls lodging prices on the booking platform server system. In some examples, the cloud-based control platform1012maintains a database of data objects for each remotely-controlled asset (e.g., each hotel room, rental property, etc.). The data objects for each remotely-controlled asset can include static hyperparameters (e.g., location, size, amenities, etc.) and dynamic hyperparameters (e.g., weather, local events, travel restrictions, etc.) associated with the asset. The data objects for each remotely-controlled asset can also include a template that specifies values of a variable associated with the asset (e.g., nightly price, etc.) for a plurality of future time points. The cloud-based control platform1012can use an update process to determine an updated template for one of the data objects. The update process can include calculating target values for the variable for the plurality of future time points based on a target criterion, communicating with one or more remote computer systems to determine current values of the dynamic hyperparameters, determining a ratio based on the current values of the dynamic hyperparameters, calculating scaled values for the plurality of future time points by applying the ratio to the target values, determining an adjustment based on the static hyperparameters, calculating first modified values for the plurality of future time points by applying the adjustment to the scaled values, calculating second modified values for the plurality of future time points by applying an override value to the first modified values, and assigning the second modified values to the template. The cloud-based control platform1012can iteratively update the booking platform server according to the updated template at each of the plurality of future time points. Updating the booking platform server can include identifying a next value of the variable, wherein the next value of the variable can be the value specified by the updated template for a time point associated with a current time, and communicating the next value to the booking platform server with instructions to assign the next value of the variable to a setting associated with the remotely-controlled asset.

Yet another specific example of a remotely-controlled computer system that can be controlled by the cloud-based control platform1012ofFIG.1is an online marketplace server system, where prices of marketplace items (e.g., retail items, resell items, etc.) are an example of variable settings associated with remotely-controlled assets. In such cases, the cloud-based control platform1012can operate as an item broker platform that remotely controls marketplace item prices on the online marketplace server system. In some examples, the cloud-based control platform1012maintains a database of data objects for each remotely-controlled asset. The data objects for each remotely-controlled asset can include static hyperparameters (e.g., item condition, item properties, shipping prices, etc.) and dynamic hyperparameters (e.g., quantity available, competing items available, etc.) associated with the asset. The data objects for each remotely-controlled asset can also include a template that specifies values of a variable associated with the asset (e.g., item price) for a plurality of future time points. The cloud-based control platform1012can use an update process to determine an updated template for one of the data objects. The update process can include calculating target values for the variable for the plurality of future time points based on a target criterion, communicating with one or more remote computer systems to determine current values of the dynamic hyperparameters, determining a ratio based on the current values of the dynamic hyperparameters, calculating scaled values for the plurality of future time points by applying the ratio to the target values, determining an adjustment based on the static hyperparameters, calculating first modified values for the plurality of future time points by applying the adjustment to the scaled values, calculating second modified values for the plurality of future time points by applying an override value to the first modified values, and assigning the second modified values to the template. The cloud-based control platform1012can iteratively update the online marketplace server system according to the updated template at each of the plurality of future time points. Updating the online marketplace server system can include identifying a next value of the variable, wherein the next value of the variable can be the value specified by the updated template for a time point associated with a current time, and communicating the next value to the online marketplace server system with instructions to assign the next value of the variable to a setting associated with the remotely-controlled asset.

FIG.2shows an example ticket management system100. The ticket management system100facilitates a ticket broker's transactions between the primary ticket markets and the secondary ticket markets. The ticket management system100includes networks102A,102B, one or more primary ticket market seller servers104, one or more secondary ticket market seller servers106, and a computer-implemented, cloud-based ticket broker platform108. The network102A communicatively couples the primary ticket market seller servers104and the ticket broker platform108, while network102B communicatively couples the ticket broker platform108and the secondary ticket market seller servers106.

In some implementations, the networks102A,102B include the Internet, one or more telephony networks, one or more network segments including local area networks (LANs) and wide area networks (WANs), one or more wireless networks, or a combination thereof.

In some implementations, a cloud-based platform may be a cloud-based ticket broker platform that allows a ticket broker to effectively manage large volumes of data related to the sale of event tickets. For example, in some implementations, the cloud-based ticket broker platform may allow ticket brokers to effectively manage thousands of event tickets in their ticket portfolios, seamlessly communicate with different sales tools and sales platforms (each of which may have their own API, rules, etc.), and quickly and precisely update ticket prices at scheduled times in order to be competitive with a change in demand as the event nears.

Tickets for events, such as sporting events and concerts, are typically sold first on a primary market ticket exchange and often resold on a secondary market ticket exchange. For example, event tickets are typically sold in primary markets (e.g., TicketMaster, Live Nation, or AXS) far in advance of the event, sometimes over a year in advance. Ticket brokers purchase at least a portion of their inventory (or ticket portfolio) from the primary ticket markets. Consumers can also purchase tickets directly from primary markets just like ticket brokers. Other than familiarity with the purchasing process, ticket brokers typically do not have a competitive advantage over everyday consumers when purchasing tickets from the primary markets.

Typically, however, consumers often wait until closer to the event date before deciding to attend an event. Those consumers may find that tickets for popular events are no longer available in primary markets (e.g., the event is sold out), and must purchase those tickets in secondary markets. Generally, there are two main categories of sellers who resell tickets on the secondary market. The first category includes individuals who have tickets (e.g., season or non-season tickets) and wish to sell seats for events they cannot attend. The second category includes ticket brokers that purchase at least a part of their ticket inventory (also referred to as ticket portfolio, which includes both season and non-season tickets) from one or more primary market ticket exchanges.

In some aspects of what is described here, a computer-implemented, cloud-based ticket broker platform is provided. In some instances, the computer-implemented, cloud-based ticket broker platform includes a pricing engine and provides technical improvements and advantages over existing approaches. For example, the systems and techniques described here provide an efficient, computer-implemented, cloud-based ticket broker platform that reduces manual interventions, precisely schedules changes to ticket prices, and allows for the seamless management of higher ticket volumes. For example, the cloud-based ticket broker platform manages large amounts of data related to the sale of event tickets, provides for seamless and precisely-timed communications with disparate computer systems, and precisely times the prices of the tickets to a changing market so that the tickets remain competitively priced.

The one or more primary ticket market seller servers104can include, for example, the ticket management systems of one or more primary market ticket exchanges. The primary market ticket exchange(s) may function as distributors for an event venue, although event venues can distribute the tickets themselves if they are so inclined. As an example, primary market ticket exchange(s) sell tickets on behalf of sports teams, concert promoters, etc., or can represent the ticket management systems (e.g., event or concert promoter) of the actual performers or teams themselves. Therefore, the primary market ticket exchanges offer tickets for sale directly to purchasers and have technology in place which allows teams, artists, and promoters to have their tickets listed and marketed. In some examples, primary market ticket exchanges function as distributors and guarantors of the tickets sold. For example, as a guarantor of the tickets, a broker can contact the primary market ticket exchange (which is the merchant) if the broker has an issue with the ticket purchased from the primary market ticket exchange. Example primary market ticket exchanges that brokers use and that act as distributors include Ticketmaster, Live Nation Entertainment, AEG (AXS.com), Ticketfly, Eventbrite, eTix. Primary market ticket exchanges may also be grouped by region, brand, or genre, examples being Telecharge and ComcastTIX.

The one or more secondary ticket market seller servers106can include, for example, the ticket management systems of one or more secondary market exchanges which enable the buying and selling of tickets previously purchased in the primary market. The secondary ticket market seller servers106process sales, settle payments, and facilitate the ticket delivery from ticket brokers to consumers. In some examples, if the final consumer has an issue with the ticket purchased from the secondary market ticket exchange, the consumer can contact the secondary market ticket exchange, which in turn contacts the broker, who in turn resolves the issue or contacts the primary market ticket exchange. Example secondary market ticket exchanges include Tickets.com, StubHub, Vivid Seats, TicketsNow, SeatGeek, TicketNetwork, Ticket Evolution, Out of This World, and others.

The computer-implemented, cloud-based ticket broker platform108shown in the example ofFIG.2allows a ticket broker to purchase tickets for their ticket portfolio and to process tickets in their ticket portfolio before the tickets are listed on secondary market ticket exchanges and sold to the final consumer. The example ticket broker platform108includes a broker point of sale (POS) system110, a ticket processing system112, a pricing engine114, and one or more databases116. The POS system110functions as a central hub of operations of the ticket broker platform108, while the ticket processing system112, pricing engine114, and database(s)116operate as spokes of the POS system110. In some implementations, a broker purchases tickets from the primary market ticket exchange servers104; the purchased tickets get processed and ported over to the POS system110, thereby becoming a part of the broker's ticket portfolio. In some implementations, the POS system110communicates with the secondary market ticket exchange servers106, ticket processing system112, pricing engine114, and one or more databases116via respective application programming interface (API) calls.

In some implementations, the POS system110is configured to manage the broker's ticket portfolio and ticket sales. For example, in some implementations, the POS system110executes an automated process that lists tickets from the broker's ticket portfolio for sale on multiple secondary market ticket exchanges and, when a sale of a ticket is completed, removes the ticket's listing from all secondary market ticket exchanges. For example, the POS system110reads information for new inventory, posts that information on the various secondary exchanges (including periodic listing price updates), removes listings from the secondary market ticket exchange servers106after the sale of a ticket thereon, and stores results of the sale for the broker to process (e.g., so that the broker can generate performance reports). In some implementations, the pricing engine114is used to automatically and continuously price the tickets in the broker's ticket portfolio. For example, the pricing engine114may be configured to update the offering prices of tickets in the broker's ticket portfolio at specified instances of time. The updated offering prices of the tickets are then provided by the pricing engine114to the POS system110so that the updated offering prices are reflected on the secondary market ticket exchange servers106. This automatic and continuous forecasting and updating of ticket prices can be set for the entire period between the tickets' date of purchase (e.g., from the primary ticket market seller servers104) up until the event date, thereby significantly increasing efficiency by reducing manual interventions, precisely scheduling changes to ticket prices, and allowing for the seamless management of higher ticket volumes.

The ticket processing system112may include one or more processors, examples being central processing units (CPUs), graphics processing units (GPUs), a multi-processor core, or any other type of processor, depending on the particular implementation. In some implementations, the ticket processing system112may be integrated into the broker POS system110. In some implementations, the ticket processing system112acquires information from each ticket in the broker's ticket portfolio, thus generating a ticket portfolio database. The ticket portfolio database may be stored or maintained in the database(s)116of the ticket broker platform108. The database(s)116can be, for example, random access memory (RAM) or any other suitable volatile or non-volatile computer readable storage medium. The database(s)116can also include storage which can take various forms, depending on the implementation. For example, the storage can contain one or more components or devices such as a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. In addition, the memory and/or storage can be fixed or removable. In addition, memory and/or storage can be located remotely.

In some implementations, the pricing engine114uses information included in the ticket portfolio database, which includes a respective ticket profile for each ticket in the broker's ticket portfolio. The ticket profile for each ticket may specify a current offering price of the ticket on the secondary market ticket exchange servers106, attributes of the ticket, offering price parameters, the times to calculate an updated offering price for the ticket, and one or more ticket pricing templates associated with the ticket. The attributes of the ticket may include the event name, date, time, location, seat section and number, among other information pertinent to the ticket or the event. The offering price parameters of a ticket may include a target profit to be achieved from the sale of the ticket, adjusted pricing ratios, pricing boundaries (e.g., a maximum or minimum price of the ticket), predetermined pricing premiums or predetermined pricing discounts to be applied to the offering price of the ticket, and pricing overrides that may be applied by a ticket broker to the ticket price. Furthermore, the ticket pricing template(s) associated with the ticket may specify a time-series of adjustments for the offering price of the ticket. The ticket pricing template(s) may be included in a template database, which is also stored or maintained in the database(s)116of the ticket broker platform108.

As discussed above, the ticket profile for each ticket may specify the times to calculate an updated offering price for the ticket. In some implementations, each ticket pricing template is associated with the times at which an updated offering price for the ticket is calculated. The times at which an updated offering price for the ticket is calculated can be specified by the broker, forecast from analytics, or be a combination thereof. As an example, the times at which the offering price of the ticket is updated may first be stipulated by a scheduling engine (e.g., manually defined by the broker). As described in an example below, the times stipulated by the scheduling engine may not be equally spaced in time. In some implementations, the broker can define a rule that could force a reprice of the ticket, regardless of the times stipulated by the scheduling engine. An example of such an implementation may be the reprice of the ticket at a specific time per week (e.g., at a day and time specified by the broker. In some implementations, the broker can manually override the times stipulated by the scheduling engine.

The example ticket pricing template200A inFIG.2Ashows that the updated offering price for the ticket is calculated at various dates ranging from October 28 up until the event date of July 10. The example ticket pricing template200B inFIG.2Bshows that the updated offering price for the ticket is calculated at various dates before the event, ranging from about 180 days before the event up until the day of the event. The example ticket pricing templates200C to200E show that the updated offering price for the ticket is calculated at various dates before the event, ranging from about 125 days before the event up until the day of the event.

In some implementations, the times at which an updated offering price for the ticket is calculated may not be equally spaced in time. For example, an updated offering price for the ticket may be calculated more frequently soon after the ticket is offered for sale on the secondary market ticket exchange servers106or closer to the event date (e.g., as seen for time periods202A,204A of ticket pricing template200A and time periods202B,204B of ticket pricing template200B). On the other hand, updated offering price for the ticket may be calculated less frequently in an interim time period (e.g., as seen for time period206A of ticket pricing template200A and time period206B of ticket pricing template200B).

As discussed above, the pricing engine114of the ticket broker platform108may be configured to update the offering prices of tickets in the broker's ticket portfolio (e.g., at specified instances of time). In this regard, the ticket pricing engine is configured to determine updated offering prices for the tickets in the ticket portfolio by identifying the current offering price of the ticket; identifying the offering price parameters of the ticket; identifying the ticket pricing template associated with the ticket; and calculating the updated offering price based on the current offering price for the ticket, the ticket pricing template for the ticket, and the offering price parameters for the ticket. Therefore, the pricing engine114automatically prices tickets for the broker using a predetermined pricing scheduler system (e.g., the ticket pricing template and the times at which an updated offering price for the ticket is calculated), whether the pricing scheduler system is forecast from analytics, by manual entry, or a combination of manual and analytical forecasting.

FIGS.3A and3Bshow an example flowchart300that illustrates steps that may be executed by the ticket broker platform108to continuously forecast and update ticket prices for any ticket in a broker's ticket portfolio. Specifically,FIG.3Ashows an example of how the ticket broker platform108finalizes the ticket pricing template associated with the ticket and the offering price parameters associated with the ticket, andFIG.3Bshows an example of how the ticket broker platform108selects times at which an updated offering price for the ticket is calculated and calculates the updated offering price for the ticket.

Referring toFIG.3A, at step302, a ticket from the broker's ticket portfolio is selected. Additionally, at step304, a ticket pricing template that is associated with the ticket is selected. As discussed above, the ticket pricing template, which specifies how the offering price of a ticket changes over time, may be created manually by the broker or predetermined based on analytics. In implementations where the ticket pricing template is created manually by the broker (e.g., as in step306shown in the flowchart300), the broker provides an appropriate naming label to the ticket pricing template (e.g., as in step308) and iteratively defines the target ROI for the ticket at specified instances of time (e.g., as in step310). The manually created target ROI for the ticket at the specified instances of time may subsequently define a ticket pricing template that specifies how the offering price of the ticket changes over time (e.g., as in step312).

The broker may also set or activate offering price parameters associated with the ticket. As discussed above, the offering price parameters may include a target profit to be achieved from the sale of the ticket, adjusted pricing ratios, pricing boundaries (e.g., a maximum or minimum price of the ticket), predetermined pricing premiums or predetermined pricing discounts to be applied to the offering price of the ticket, and pricing overrides that may be applied by a ticket broker to the ticket price. In the example ofFIG.3A, the offering price parameters that are set or activated include the base price of the ticket (e.g., in steps314A,314B), pricing add-ons (e.g., in steps316A,316B), and the broker's reasons for the pricing add-ons (e.g., in steps318A,318B). In some implementations, other offering price parameters may be set or activated, examples being a target profit to be achieved from the sale of the ticket, adjusted pricing ratios, pricing boundaries (e.g., a maximum or minimum price of the ticket), and pricing overrides that may be applied by a ticket broker to the ticket price.

With regards to the base price, the base price of the ticket may be the starting offering price for the ticket on the secondary market ticket exchange servers106(e.g., before any exchange fees are applied). In some implementations, the base price may be the broker price and represents the ticket's price before exchange fees. The pricing add-ons (e.g., in steps316A,316B) may be additional pricing premiums or discounts that could modify the forecasted prices. In some implementations, the pricing add-ons may be derived from a variety of additional market conditions and inventory variables, such as overall quantity of tickets for an event, the number of tickets being sold in a listing, the sellout status of the section or venue, sales activity, etc. The broker's reasons for the pricing add-ons or changes (e.g., in steps318A,318B) serve as internal notes for the broker and assist the broker with internal auditing of the ticket portfolio. Some reasons that a broker may associate with the pricing add-ons include “repriced to market” and “change in ticket pricing template,” among others. Through the steps illustrated inFIG.3A, the ticket broker platform108finalizes the ticket pricing template associated with the ticket (e.g., through steps302,304,306,308,310,312) and the offering price parameters associated with the ticket (e.g., through steps314A,314B,316A,316B,318A,318B). As discussed above, the ticket pricing template, the offering price parameters, along with other attributes of the ticket profile may be stored in the database(s)116of the ticket broker platform108.

Referring toFIG.3B, at step320, a ticket pricing schedule is selected. As discussed above, the ticket pricing schedule, which specifies the times at which an updated offering price for the ticket is calculated, may be created manually by the broker or predetermined based on analytics. In implementations where the ticket pricing schedule is created manually by the broker (e.g., as in step322shown in the flowchart300), the broker provides an appropriate naming label to the ticket pricing schedule (e.g., as in step324) and iteratively defines the times and days at which the updated offering price for the ticket is calculated (e.g., as in step326). In some implementations, even if updated offering prices are to be calculated at a particular day, the broker may freeze such calculations because the particular day falls on a weekend (e.g., as in step328). The resultant ticket pricing schedule (e.g., as in step330) is then used in tandem with the selected ticket pricing template (e.g., as in step312). For example, step332shows the use of both the selected ticket pricing schedule and the selected ticket pricing template in calculating the updated offering price of a ticket.

The updated offering price of a ticket is calculated (e.g., as in step334) by the pricing engine114of the ticket broker platform108, taking into account the current offering price of the ticket, data from the ticket pricing schedule (e.g., in step336), data from the ticket pricing template (e.g., in step338), and the offering price parameters for the ticket (e.g., in steps340A,340B,340C, examples being adjusted pricing ratios, the pricing add-ons, price boundaries and override scenarios). The result is an updated offering price of the ticket, which can be stored in the database(s)116of the ticket broker platform108in some cases. The updated offering price of the ticket is communicated (e.g., via an API call) to the POS system110, which subsequently communicates ticket pricing instructions to the secondary market ticket exchange servers106that changes the current offering price of the ticket on the secondary market ticket exchange servers106to the updated offering prices determined by the ticket pricing engine114. This series of steps continues until the ticket is sold or the broker removes the listing from the secondary market ticket exchange servers106.

FIG.4shows an example flowchart400that illustrates in further detail how the updated offering price of a ticket is calculated by the ticket pricing engine114(e.g., shown in step334ofFIG.3B). As discussed above, offering price parameters for the ticket are taken into account when calculating the updated offering price of a ticket. Some of the offering price parameters are depicted inFIG.4as current and future price overrides (e.g., in step402A), price modifiers (e.g., in step402B), and price restrictions (e.g., in steps402C,402D). At step404, the pricing engine114prepares to price the ticket. At step406, the pricing engine114determines whether it is time to calculate an updated offering price for the ticket (e.g., based on data from the ticket pricing schedule). If the time is not included in the times specified by the ticket pricing schedule, the ticket pricing engine114does not calculate the updated offering price for the ticket. On the other hand, if the time is included in the times specified by the ticket pricing schedule, the ticket pricing engine114determines the target ROI to be achieved from the sale of the ticket (e.g., in step408). In some implementations, the target ROI may be a default ROI included in the offering price parameters of the ticket. In general, the target ROI may depend on various factors, including the motive of the broker, the market, current events, and so on. In step410, the ticket price is set to achieve the target ROI specified in step408.

In step412, the pricing engine114determines whether an adjusted ratio needs to be applied to the ticket price set in step410, and in step411the adjusted ratios are applied. In some implementations, the default ROI can be overwritten (e.g., by the broker), and the adjusted ratio indicates how much the default ROI has been adjusted by the broker. In some implementations, the adjusted ratio has a domino effect that modifies all future price points of the ticket pricing template. In this way, brokers can alter prices forecasted by the ticket pricing template quickly and accurately.

In some implementations, the adjusted ratio may be modified by hyperparameters413. Hyperparameters can be binary, e.g., “yes” or “no,” or a defined range. In some implementations, a binary hyperparameter may represent whether a show is sold out. In another implementation, such a hyperparameter may be described as a percentage, as in 90% sold out. Hyperparameters may be defined by a broker and may be toggled as active or inactive at a broker's discretion on an event-by-event basis. Examples of hyperparameters include, e.g.: an event is sold out; a given section is sold out; a score assigned for a venue; a score assigned for a location; a score assigned for a performer; a type of event, such as a sporting event, concert, festival, comedy, or theatrical performance; further decomposition of a type of event, e.g., a genre. An example of a decomposition can be a type of concert, e.g., rock, pop, or country. Hyperparameters can also be either static or dynamic. Static hyperparameters are unaffected by changes in an event. For example, a static hyperparameter can be a type of event. Dynamic hyperparameters can be influenced by live data. An example of a dynamic hyperparameter is whether an event is sold out.

Other examples of hyperparameters can include: if the event is scheduled on a holiday; the day of the week; a weather status; allowance of odd or even numbers of tickets; allowance of single tickets; general admission tickets; a measurement of the number of sales in a period of time; or a sale related to the market or exclusive to the broker's own inventory. Hyperparameters can be further defined as to whether they impact the price to make it premium or discounted (e.g., at step415). In an example, if a hyperparameter “Day of the Week” is active and a concert is on a Thursday, this may discount the event since Friday and Saturday tend to be more popular for concerts. In another example, if a football game is scheduled for a Thursday, the event may be made premium with a national audience.

As an example, suppose the ticket price is set to $100 in step410, but the broker believes that that $100 is too high and that the ticket price should actually be $75. In such a scenario, the broker can input $75 as a manual price override. Both the $100 price and the manual $75 price for the particular time point are taken as inputs by the pricing engine114, which then calculates an adjusted ratio that adjust future price points of the ticket pricing template to be in line with the 25% decrease in price. One example of how the adjusted ratio changes the future price points of the ticket pricing template is shown inFIG.5A. Specifically,FIG.5Ashows how the ticket pricing template200B shown inFIG.2Bis changed to a new ticket pricing template500A when an adjusted ratio is calculated from a present time point (shown inFIG.5Aas time point502A). As seen in the example ofFIG.5A, the final price point of the new ticket pricing template500A (e.g., target ROI at the endpoint502B) is the same as the final price point (e.g., target ROI) of the ticket pricing template200B; however, the price points (e.g., target ROI) at time points between time point502A and endpoint502B are scaled in relation to the adjusted ratio. Therefore, applying an adjusted ratio takes the new override point (e.g., at time point502A inFIG.5A), holds constant the final price point of the ticket pricing template at endpoint502B, and stretches or shrinks the shape of the ticket pricing template between time point502A and endpoint502B along the vertical axis.

In step414, the pricing engine114determines whether a pricing modifier needs to be applied to the ticket price calculated as a result of step412. In some implementations, the pricing modifier includes predetermined pricing premiums or predetermined pricing discounts to be applied to the offering price of the ticket. In step416, the ticket price calculated because of step414is checked to ensure that it satisfies the minimum price of the ticket (which may be specified by the offering price parameters for the ticket). In an implementation, a hyperparameter may be incorporated in a pricing modifier.

In step418, the pricing engine114determines whether further manual overrides (e.g., by the broker) to the updated offering price of the ticket are needed. If no further overrides are needed, the ticket price calculated at step416is taken as the updated offering price of the ticket. However, if further overrides are needed, the pricing engine114determines (e.g., in step420), how the pricing override affects other points in the ticket pricing template.

In some implementations, a further manual override by the broker is a simple point change and applies only to the offering price of the ticket at that point in time, with all other points in the ticket pricing template being unaffected. For example,FIG.5Bshows how a simple point change to the ticket pricing template200B shown inFIG.2Bat time point504A changes the ticket pricing template200B shown inFIG.2Bto a new ticket pricing template500B. As seen in the example ofFIG.5B, the price at time point504A is changed, but all other points in the ticket pricing template (including the final price point at the endpoint504B) are unaffected. Therefore, if the pricing engine114determines that the further manual override is a simple point change, the step422uses that manually set point as the updated offering price of the ticket (e.g., in step426), while holding constant all other price points (including the final price point) of the ticket pricing template.

In some implementations, a further manual override by the broker results in further changes to future price points of the ticket pricing template. For example,FIG.5Cshows how a change to the ticket pricing template200B shown inFIG.2Bat time point506A changes the ticket pricing template200B shown inFIG.2Bto a new ticket pricing template500C. In contrast to the pricing template500A inFIG.5A(whose shape is stretched or shrunk along the vertical axis relative to ticket pricing template200B) and pricing template500B inFIG.5A(where only the price point at time point504A is changed), the ticket pricing template500C is formed by trending the price points between two manually set prices in a manner that maintains the shape of the ticket pricing template200B from time point506A onwards, which includes changing the price point at endpoint506B in order to maintain the shape of the ticket pricing template200B from time point506A to endpoint506B. Therefore, if the pricing engine114determines that the further manual override shifts future price points of the ticket pricing template, the step424uses that manually set point at time point506as the updated offering price of the ticket (e.g., in step426), and also uses the future price points of the ticket pricing template for subsequent adjustments of the offering price of the ticket. Therefore, based on the description of the flowchart400, manually overriding a price can affect future price points of the ticket pricing template in a number of ways: (1) when an adjusted ratio is calculated (e.g., in step412), the shape of the ticket pricing template is changed relative to the manually set price; (2) the price points are trended between two manually set prices in a manner that maintains the shape of the ticket pricing template (e.g. in step424); and (3) a simple point change that does not affect other points in the ticket pricing template.

FIG.6shows an example flowchart600that illustrates how an override is applied to a ticket pricing template. In step602, the pricing engine114determines that a manual price override is needed. In step604, the pricing engine114determines whether automatic pricing is enabled. If automatic pricing is enabled, step606is executed, where an adjusted ratio is calculated (e.g., as discussed above inFIG.5A) in order to adjust the price. The manual price and calculated ratio are subsequently saved (e.g., in step608) and implemented over time. In examples where automatic pricing is not enabled, calculation of the adjusted ratio is skipped, and step608is executed. At step610, the ticket price is set in the POS system110when it is time to calculate or set an updated offering price for the ticket (e.g., in steps610and612).

FIG.7shows an example method700that improves the efficiency of a computer-implemented, cloud-based ticket broker platform. The method700include step702of maintaining a template database including ticket pricing templates. As discussed above, the ticket pricing templates may be maintained on the cloud-based ticket broker platform and each ticket pricing template specifies a time-series of adjustments for ticket price offerings. The method700includes step704of maintaining a ticket portfolio database including ticket profiles for tickets in a ticket portfolio. As discussed above, the ticket portfolio database may be maintained on the cloud-based ticket broker platform. In some implementations, the ticket profile for each ticket specifies a current offering price on Internet-based ticket sales platforms, ticket attributes, offering price parameters, and one of the ticket pricing templates.

The method700includes step706of executing a ticket pricing engine to determine updated offering prices for the tickets in the ticket portfolio. As discussed above, the ticket pricing engine is executed on the cloud-based ticket broker platform. Furthermore, as discussed above, the ticket pricing engine determines the updated offering price of a ticket by: identifying the current offering price of the ticket; identifying the offering price parameters of the ticket; identifying the ticket pricing template associated with the ticket; and calculating the updated offering price based on the current offering price for the ticket, the ticket pricing template for the ticket, and the offering price parameters for the ticket.

The method700includes step708of communicating ticket pricing instructions that change the current offering prices of the tickets on the Internet-based ticket sales platforms (e.g., secondary ticket market seller servers106) to the updated offering prices determined by the ticket pricing engine. As discussed above, the ticket pricing instructions are communicated from the cloud-based ticket broker platform to application programming interfaces (APIs) of the respective Internet-based ticket sales platforms.

The method700provides several technical improvements and advantages over existing approaches. For example, the method700reduces manual interventions, precisely schedules changes to ticket prices, and allows for the seamless management of higher ticket volumes. For example, the method700manages large amounts of data related to the sale of event tickets, provides for seamless and precisely-timed communications with disparate computer systems, and precisely times the prices of the tickets to a changing market so that the tickets remain competitively priced.

In some aspects, a method is provided of maintaining, on a cloud-based control platform, a database comprising a plurality of data objects for a plurality of remotely-controlled assets. The data objects for each remotely-controlled asset include: a plurality of static hyperparameters associated with the asset, a plurality of dynamic hyperparameters associated with the asset, and a template that specifies values of a variable associated with the asset for a plurality of future time points. The method further includes, by operation of the cloud-based control platform, determining an updated template for one of the data objects. Determination of the updated template involves calculating target values for the variable for the plurality of future time points based on a target criterion, communicating with one or more remote computer systems to determine current values of the dynamic hyperparameters, and determining a ratio based on the current values of the dynamic hyperparameters. Determination of the updated template further involves calculating scaled values for the plurality of future time points by applying the ratio to the target values, determining an adjustment based on the static hyperparameters, and calculating first modified values for the plurality of future time points by applying the adjustment to the scaled values. Determination of the updated template also involves calculating second modified values for the plurality of future time points by applying an override value to the first modified values and assigning the second modified values to the template. The method additionally includes, by operation of the cloud-based control platform, iteratively updating a remotely-controlled system according to the updated template at each of the plurality of future time points. Updating the remotely-controlled system includes identifying a next value of the variable, wherein the next value of the variable is the value specified by the updated template for a time point associated with a current time, and communicating the next value to the remotely-controlled system with instructions to assign the next value of the variable to a setting associated with the remotely-controlled asset.

In a first example, a method of improving efficiency of a computer-implemented, cloud-based ticket broker platform includes: maintaining, on the cloud-based ticket broker platform, a template database including ticket pricing templates, each ticket pricing template specifying a time-series of adjustments for ticket price offerings. The method further includes maintaining, on the cloud-based ticket broker platform, a ticket portfolio database including ticket profiles for tickets in a ticket portfolio. The ticket profile for each ticket specifies: a current offering price on Internet-based ticket sales platforms, ticket attributes, offering price parameters, and one of the ticket pricing templates. The method additionally includes executing, on the cloud-based ticket broker platform, a ticket pricing engine to determine updated offering prices for the tickets in the ticket portfolio, where the ticket pricing engine determines the updated offering price of a ticket by: identifying the current offering price of the ticket; identifying the offering price parameters of the ticket; identifying the ticket pricing template associated with the ticket; and calculating the updated offering price based on the current offering price for the ticket, the ticket pricing template for the ticket, and the offering price parameters for the ticket. The method also includes communicating, from the cloud-based ticket broker platform to application programming interfaces (APIs) of the respective Internet-based ticket sales platforms, ticket pricing instructions that change the current offering prices of the tickets on the Internet-based ticket sales platforms to the updated offering prices determined by the ticket pricing engine.

Implementations of the first example may include one or more of the following features. The method of the first example, in which the ticket profile for each ticket further specifies times to calculate the updated offering price for the ticket, and executing the ticket pricing engine comprises determining the updated offering price for the ticket at the times specified in the ticket profile for the ticket. In some implementations, the times specified in the ticket profile for the ticket are not equally spaced apart. The method of the first example, in which the offering price parameters comprise a target profit to be achieved from sales of the tickets, and calculating the updated offering price comprises setting the updated offering price for the ticket to achieve the target profit (which may be a dollar profit after all adjustments and calculations). The method of the first example, where the offering price parameters comprise predetermined pricing premiums or predetermined pricing discounts to be applied to the offering prices of the tickets, and calculating the updated offering price includes: calculating an interim offering price for the ticket based on the current offering price for the ticket and the ticket pricing template for the ticket; and applying the predetermined pricing premiums or the predetermined pricing discounts to the interim offering price to generate the updated offering price for the ticket. The method of the first example, in which the offering price parameters include minimum prices for the tickets, and calculating the updated offering price includes setting the updated offering price to be greater than the minimum price for the ticket. The method of the first example, in which the offering price parameters include pricing overrides applied by a ticket broker to the ticket price offerings, and calculating the updated offering price includes: calculating an interim offering price for the ticket based on the current offering price for the ticket and the ticket pricing template for the ticket; and applying the pricing overrides to the interim offering price to generate the updated offering price for the ticket. In some implementations, future time points in the ticket pricing template are varied based on the pricing overrides. In some implementations, future time points in the ticket pricing template are left unchanged.

A non-transitory computer-readable medium may store instructions that are operable when executed by data processing apparatus to perform one or more operations described above. A computer system may include one or more processors and memory storing instructions that are configured, when executed by the one or more processors, to perform one or more operations described above.

While this specification contains many details, these should not be understood as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular examples. Certain features that are described in this specification or shown in the drawings in the context of separate implementations can also be combined. Conversely, various features that are described or shown in the context of a single implementation can also be implemented in multiple embodiments separately or in any suitable sub-combination.