RESOURCE OPTIMIZATION

BACKGROUND INFORMATION

Consumer demand for media is increasing. For example, consumers often watch and/or listen to various media at home, while traveling, at work, etc. As a result, the number of communication channels for delivering media content and the number of different types of devices for playing the content has also increased.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 schematically illustrates an exemplary network in which systems and methods described herein may be implemented;

FIG. 2 illustrates an exemplary architecture associated with one of the components of FIG. 1 in which systems and methods described herein may be implemented;

FIG. 3 illustrates an exemplary configuration of one or more of the components of FIG. 2;

FIG. 4 illustrates a more detailed view of the exemplary architecture of FIG. 2;

FIG. 5A illustrates an exemplary configuration table and a total pooled resource table associated with estimating resources available to fulfill work orders;

FIG. 5B illustrates exemplary tables associated with consumption of resources and availability of resources;

FIG. 6 illustrates an exemplary table associated with identifying resources used to estimate and/or fulfill exemplary orders

FIG. 7 illustrates an exemplary table associated with estimating human resources associated with fulfilling orders;

FIG. 8 is a flow diagram illustrating exemplary processing associated with an order;

FIG. 9 is a flow diagram associated with generating an estimate associated with executing an order;

FIG. 10 is an exemplary table associated with generating a billing estimate for an order;

FIG. 11 is a flow diagram illustrating exemplary processing associated with executing a work order;

FIG. 12 is an exemplary timeline associated with executing work orders;

FIG. 13 illustrates functional components implemented in the architecture of FIG. 2 that are associated with performing resource optimization;

FIG. 14 illustrates detailed functional components of the work order level jeopardy handler of FIG. 13;

FIG. 15 illustrates detailed functional components of the task level jeopardy handler of FIG. 13;

FIG. 16 is a flow diagram illustrating exemplary processing associated with determining the availability of resources; and

FIG. 17 is a flow diagram illustrating exemplary processing associated with optimizing the scheduled execution of tasks.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.

Implementations described herein relate to an infrastructure for allowing customers to submit orders for processing content, such as media content. The infrastructure facilitates processing of the orders using workflows that represent tasks to be performed. The infrastructure may also generate schedules associated with processing orders and determine optimum schedules based on customer requirements and business policies associated with the entity processing the order. In an exemplary implementation, alternate schedules may be generated and an optimum schedule may be selected.

FIG. 1 is a block diagram of an exemplary network in which systems and methods described herein may be implemented. Referring to FIG. 1, network 100 includes one or more content creators 110, one or more advertisers 120, one or more digital media retailers (DMRs) 130, one or more consumers 140 and digital data clearinghouse (DDC) 150. The exemplary configuration illustrated in FIG. 1 is provided for simplicity. It should be understood that a typical network may include more or fewer devices than illustrated in FIG. 1.

Content creator 110 (referred to collectively as content creators 110 or individually as content creator 110) may represent one or more creators of content that wish to package and/or distribute the content to other parties, such as consumers 140. For example, content creators 110 may include movie or television studios, music companies, publishers, game developers, parties who generate user generated content (UGC), websites, blogsites, etc. Content creators 110 may provide content to DDC 150 for transcoding, packaging and/or distribution, as described in detail below. The term “content,” as used herein, may include any type of media, such as video, audio, multi-media, textual data, etc. The term “content” may also be referred to herein as “video assets” or “assets.”

Advertiser 120 (referred to collectively as advertisers 120 or individually as advertiser 120) may represent one or more parties that wish to insert advertising into media files. For example, advertiser 120 may contract with a content creator 110 and/or digital media retailer 130 to insert an advertisement into a media stream provided to consumers 140. DDC 150 may insert the advertisement into the stream in accordance with the agreement between the parties.

DMR 130 may represent one or more business entities that receive media content from various parties and resell it to end users. For example, DMRs 130 may include broadcasters, cable companies, direct broadcast satellite (DBS) providers, Internet protocol television (IPTV) providers, mobile phone TV providers, online retailers, etc. DMRs 130 may receive media content from DDC 150 and sell/provide the content to consumers 140.

Consumer 140 may represent one or more consumers 140 that receive content originally generated by or provided by content creators 110 and that has been processed by DDC 150. For example, DDC 150 may format and package content for distribution by DMRs 130 and/or DDC 150 to consumers 140.

DDC 150 may include a server/computing device or a set of servers/computing devices associated with, for example, processing media content. For example, as described briefly above, DDC 150, also referred to herein as DDC platform 150, may provide an automated environment in which content from content creators 110 is transformed and packaged for distribution in any number of formats, based on the particular requirements associated with DMRs 130. In an exemplary implementation, DDC 150 may also aggregate various data and insert advertisements into the media content. DDC 150, consistent with implementations described herein, may also utilize flexible workflows to streamline the formatting and packaging of content for digital distribution.

As described above, the exemplary configuration illustrated in FIG. 1 is provided for simplicity. It should be understood that a typical network may include more or fewer devices than illustrated in FIG. 1. For example, it should be understood that network 100 may include a large number (e.g., hundreds or thousands) of different types of user devices associated with consumers 140, such as televisions, cellular telephones, personal computers (PCs), laptop computers, tablet computers, notebook computers, netbook computers, personal digital assistants (PDAs), etc.

It should also be understood network 100 may include one or more wired, wireless and/or optical networks (not shown) that interconnect the components illustrated in FIG. 1 and enable the components in FIG. 1 to communicate with one another. For example, network 100 may include one or more public switched telephone networks (PSTNs) or other type of switched network. Network 100 may also include one or more wireless networks and may include a number of transmission towers for receiving wireless signals and forwarding the wireless signals toward the intended destination. Network 100 may further include one or more satellite networks, one or more packet switched networks, such as an Internet protocol (IP) based network, a local area network (LAN), a wide area network (WAN), an intranet, the Internet, or another type of network that is capable of transmitting data from a source device to a destination device.

Further, various functions are described below as being performed by particular components in network 100. In other implementations, various functions described below as being performed by one device may be performed by another device or multiple devices, and various functions described as being performed by multiple devices may be combined and performed by a single device.

FIG. 2 illustrates an exemplary configuration of DDC 150. Referring to FIG. 2, DDC 150 may include databases 210, order management system 220, data and security system 230, DDC service operation management (SOM) system 240, DDC resource management system 250, DDC work order execution (WOE) system 270 and DDC support system 290.

Databases 210 may store work unit definitions, workflows, parameters, tables that are associated with various components in DDC 150, intermediate or end results of processing performed by different processes in DDC 150, etc. The term “work unit,” as used herein, may refer to a description of a set of one or more operations that a system may perform on content (e.g., overlaying subtitles on a video, inserting advertisements into a video, reformatting a video, etc.).

Order management system 220 may include one or more computing devices or servers for managing customer orders, generating reports, etc. In an exemplary implementation, order management system 220 may include client components that interface with components on DDC service operation management system 240. The client components (e.g., web browser) may receive customer orders, requests for reports, etc., and relay the received information to the components on DDC service operation management system 240 for the creation, validation, estimation, submission, approval, execution and reporting of activities associated with the customer orders, request for reports, etc. For example, a customer order may be completed by sending, to a component on DDC service operation management system 240, a selection of a particular workflow that will drive the processing of content associated with the order.

Data and security system 230 may include one or more computing devices or servers that provide for authentication and authorization of users having roles in DDC 150 and/or for taking actions that are associated with the authorized roles (e.g., create user accounts, remove user accounts, generate an initial password, etc.). For example, when a user logs in as a DDC operator, the user may be authorized to design work units and/or compose workflows. In an exemplary implementation, data and security system 230 may interface with order management system 220, DDC SOM system 240 and DDC support system 290.

DDC service operation management (SOM) system 240 may include one or more servers or computing devices to control the overall operation, configuration, and management of DDC 150. For example, DDC SOM system 240 may include operation management system 242 and SOM modules 244. Via a client component that communicates with operation management system 242, a user may control the configuration, administration and operation of DDC 150. For example, in one implementation, via a web browser or another client application, a user may control security, compose a workflow, administer accounts that are associated with content creator 110 or DMR 130, submit a work order, add data and storage to DDC 150, manage resources, manage DDC configuration (e.g., create a work unit), manage catalogs of content, run reports, monitor DDC work order (e.g., information associated with a work order), etc.

In providing each of such services to a client, operation management system 242 may employ SOM modules 244. SOM modules 244 may include components/modules that correspond to the above-listed services. For example, SOM modules 244 may include a security manager, workflow manager, account manager, work order manager, data and storage manager, resource management module, configuration manager, asset management module, catalog management module, monitoring and reporting module, etc. DDC SOM system 240 may further include an operational graphical user interface (GUI) for interfacing with SOM modules.

DDC resource management system 250 may include one or more servers or computing devices that support the capacity management of resources associated with network elements (NEs) in DDC 150. As illustrated in FIG. 2, DDC resource management system 250 may include work order (WO) server 252, WO estimator 254, WO decomposer and optimizer 256, WO scheduler 258, runtime resource manager 260 and metrics collector 262. Components 252-262 may aid in scheduling and allocating resources associated with fulfilling customer orders, as described in detail below.

WO server 252 may provide work order-related interfaces to operation management system 242 and/or SOM modules 244, and may communicate with WO estimator 254, WO decomposer and optimizer 256, and WO scheduler 258 to submit, decompose, validate, and save work orders, and to estimate, schedule, and reserve resources during the order submission.

Work order estimator 254 may estimate the cost of completing a decomposed work order across work units of a workflow, based on resources that are associated with the work units for each resource type. Work order estimator 254 may store the cost in one of databases 210 in terms of resource capacity units (RCUs) and duration of time required to complete tasks or processes that are associated with the work order.

WO decomposer and optimizer 256 may break down an order into work units based on the workflow associated with the order. Furthermore, based on the decomposition, WO decomposer and optimizer 256 may generate work unit tasks, or simply “tasks,” assign task parameters, and create task connectors, which are described below.

WO scheduler 258 may match cost estimates for different resource types for a work order to available time slots in an allocation schedule across different network elements (e.g., hardware/software components that perform underlying operations for a work unit). As a result of the scheduling, WO scheduler 258 may output start and end times for each of the work unit tasks and for resource reservations.

Runtime resource manager 260 may allocate network elements/user groups to a process at the time of execution on behalf of a work unit. Runtime resource manager 260 may attempt to honor scheduled reservations of resources. However, if the resources are unavailable, runtime resource manager 260 may attempt to obtain replacement resources.

Metrics collector 262 may determine, for each work unit, actual time of completion and used/consumed resources associated with the execution of the work unit. Based on previous actual execution measurements, metrics collector 262 may modify factors that are used to estimate the resource and time necessary to complete a task associated with a work unit for a particular asset.

In an exemplary implementation, resource management system 250 may represent the functions performed by various NEs used to execute work order tasks as resource types and represent the capacity of the NEs using resource capacity units (RCUs). The term “resource type,” as used herein, may include categories of consumable network resources used to schedule, reserve, bill and manage network capacity. Examples of resource types include bandwidth, storage, and the ability to transcode an asset from one format into another format. Resource types may also include resources associated with humans involved in the processing of assets, such as a human's ability to review a movie asset, etc. The term “RCU”, as used herein, may include the unit of measure for a resource type. Examples of RCUs include megabits for bandwidth, gibabytes for storage, transcoding task units and/or CPU processing time for transcoding operations, etc.

DDC work order execution (WOE) system 270 may include one or more servers or computing devices to manage the flow and execution of work units of a defined workflow associated with a work order. DDC WOE system 270 may include a workflow (WF) command processor 272 (also referred to herein as command processor 272), work unit (WU) adapters 274, and network elements 276. For simplicity, FIG. 2 does not show other components of WOE system 270. Depending on the implementation, DDC WOE system 270 may include additional, fewer, or different components than those illustrated in FIG. 2. For example, WOE system 270 may include a work unit processor (not shown).

Command processor 272 may drive work order execution. Command processor 272 may include a WO manager and WO processor. The WO manager may provide interfaces to resource management system 250 for initiating an execution of a work order, retrieving the status of the work order, suspending/resuming the work order execution, canceling the work order, etc. The WO processor may coordinate work unit tasks for completion of a work order. In coordinating different work unit tasks, the WO processor may sequence the tasks for optimum execution time and resource utilization. The WO processor may communicate with runtime resource manager 260 for allocation and de-allocation of resources. The work unit processor may dispatch processes/threads to perform a work unit task.

Work unit adapter 274 may include interfaces for adapting network elements to perform media content processing corresponding to a work unit. In one implementation, each work unit adapter 274 may be versioned and may include Java code. Each work unit adapter 274 may monitor the corresponding network element to prevent over-allocation of the network element, maintain normal execution of logic associated with the network element, and provide real-time information to metrics collector 262.

Network elements 276 may include physical or logical network devices/components for processing media content.

DDC support system 290 may include one or more servers or computing devices and/or personnel to provide support services, such creation of work units, composition of workflows, etc., billing support, contracting management, pricing, etc.

The configuration shown in FIG. 2 is for illustrative purposes. In other configurations and/or implementations, functions that are associated with one component or system shown in FIG. 2 may be performed by one or more other components in FIG. 2, any of the components may be connected to any other of the components, and functions of one component may be included in another component. Accordingly, in the other configurations or implementations, DDC 150 may include additional, fewer, different, or a different arrangement of components than those illustrated in FIG. 2.

FIG. 3 illustrates an exemplary configuration of one or more devices on which DDC resource management system 250 and/or components of DDC resource management system 250 may be implemented. For example, one or more of WO server 252, WO estimator 254, WO decomposer and optimizer 256, WO scheduler 258, runtime resource manager 260 and metrics collector 262 may be implemented on one or more devices configured as illustrated in FIG. 3. Other components in DDC 150, such as components in order management system 220, data and security system 230, DDC SOM system 240, DDC work order execution system 270 and DDC support system 290 may be configured in a similar manner. Referring to FIG. 3, DDC resource management system 250 (or one or more components of DDC resource management system 250) may include bus 310, processor 320, memory 330, input device 340, output device 350 and communication interface 360. Bus 310 may include a path that permits communication among the elements of DDC resource management system 250.

Processor 320 may include one or more processors, microprocessors, or processing logic that may interpret and execute instructions. Memory 330 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 320. Memory 330 may also include a read only memory (ROM) device or another type of static storage device that may store static information and instructions for use by processor 320. Memory 330 may further include a solid state drive (SDD). Memory 330 may also include a magnetic and/or optical recording medium (e.g., a hard disk) and its corresponding drive.

Input device 340 may include a mechanism that permits a user to input information to DDC resource management system 250, such as a keyboard, a keypad, a mouse, a pen, a microphone, a touch screen, voice recognition and/or biometric mechanisms, etc. Output device 350 may include a mechanism that outputs information to the user, including a display, a printer, a speaker, etc.

Communication interface 360 may include a transceiver for communicating with other devices within system 250 or outside system 250 (e.g., order management system 220, DDC WOE system 270, databases 210) via wired, wireless or optical mechanisms. Communication interface 360 may also include one or more radio frequency (RF) transmitters, receivers and/or transceivers and one or more antennas for transmitting and receiving RF data via network 100. Communication interface 360 may also include a modem or an Ethernet interface to a LAN or other mechanisms for communicating with elements in a network or system, such as network 100 or system 150, or another network/system.

The exemplary configuration illustrated in FIG. 3 is provided for simplicity. It should be understood that devices in system 250 may include more or fewer devices than illustrated in FIG. 3. In an exemplary implementation, one or more components of system 250 may perform operations in response to processor 320 executing sequences of instructions contained in a computer-readable medium, such as memory 330. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into memory 330 from another computer-readable medium (e.g., a hard disk drive (HDD), SSD, etc.), or from another device via communication interface 360. Alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the implementations described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

As described above, resource management system 250 receives orders associated with, for example, content creators 110 that wish to package and distribute the content to consumers 140 via a number of different communication channels and having a number of different formats. Resource management system 250 may estimate the capacity required to complete work orders and reserve capacity to complete the work orders. Resource management system 250 may also schedule and allocate resources in real time to fulfill customer orders, as described in detail below.

FIG. 4 illustrates a more detailed view of resource management system 250 illustrated in FIG. 2. As discussed above with respect to FIG. 2, resource management system 250 may include WO server 252, WO estimator 254, WO decomposer and optimizer 256, WO scheduler 258, runtime resource manager 260 and metrics collector 262. As illustrated in FIG. 4, resource management system 250 may also include databases 400 and jeopardy manager 440.

Databases 400 may include WO schedule planner 410, metrics and statistics storage 420 and resource forecast 430. Each of elements 410-430 may be a separate database. For example, WO schedule planner 410 may store schedule information associated with a number of different work orders, along with resource information identifying resources reserved to fulfill the scheduled work orders. Metrics and statistics storage 420 may include a database storing actual completion times by work unit processes and resource type associated with executed work orders. The information in metrics and statistics storage 420 may have been collected and/or stored by metrics collector 262.

Resource forecast 430 may include a database storing information associated with capacity usage in DDC 150. For example, resource forecast 430 may store information identifying whether capacity usage within DDC 150 is trending upward, whether the percentage utilization of resources (e.g., NEs) is within some system/network tolerance, whether the percentage utilization of resources is decreasing, etc. Runtime resource manager 260 and/or WO scheduler 258 may access resource forecast 430 to generate exhaust dates for NEs/user groups (UGs) by resource type information associated with work orders to be executed.

WO server 252, as described briefly above, may include one or more servers or computing devices that act to coordinate processing associated with a work order. For example, WO server 252 may receive an order from order management system 220. WO server 252 may include interfaces (e.g., application programming interfaces (APIs)) to communicate with WO estimator 254, WO decomposer and optimizer 256 and WO scheduler 258. In an exemplary implementation, WO server 252 may use the information received from WO estimator 254 and WO decomposer and optimizer 256 and provide information to other components in resource management system 250 (e.g., WO scheduler 258) to aid in scheduling and reserving capacity for executing work orders.

As described above, resource management system 250 may represent the functions performed by various NEs as resource types. Resource management system 250 may also represent the capacity of the NEs using resource capacity units (RCUs). WO estimator 254 includes logic to estimate the number of RCUs needed for a decomposed work order across the work units based on the associated assets and/or quantities by asset type. For example, WO decomposer and optimizer 256 may include logic to break down or convert customer orders received by WO server 252 into work orders (WOs). In an exemplary implementation, WO decomposer and optimizer 256 may break down a work order using a work flow and preset parameter settings associated with the order to generate work unit tasks (WUTs), task parameters and task connectors that define constituent tasks and functions that must be executed to fulfill a customer order.

WO decomposer and estimator 256 may forward a decomposed work order to WO server 252, which may save the work order. The WO may include an associated list of assets and/or quantities by asset type. WO estimator 254 may use the decomposed work order and associated list of assets to generate a rough order of magnitude (ROM) estimate for the work order, as described below.

WO estimator 254 may include logic to receive a decomposed work order from WO server 252 and generate an estimate associated with the decomposed work order. In an exemplary implementation, WO estimator 254 may provide an estimate based on an associated list of assets and/or quantities by asset type for the decomposed work order. For example, WO estimator 254 may use the list of assets associated with the WO to generate an ROM estimate. The ROM estimate generated by WO estimator 254 may include RCU estimates and time duration estimates for all resource types and all work units in the selected work flow. These RCUs may then be used with other information (e.g., a rate table) to establish a high level cost estimate to complete the entered order. In some implementations, the cost estimate and/or time estimate for completing the work order may be provided to the customer to allow the customer to determine whether to approve the estimate.

In an exemplary implementation, by classifying an asset into types (e.g., asset types), customers and/or a DDC operator may not have to be aware of the size and duration of assets (e.g., the length of a movie) associated with various customer requests. More specifically, DDC 150 (e.g., order management system 220) provides a list of normalized asset types that can be used. For estimation purposes, WO estimator 254 uses asset type information associated with what a content creator 110 provides during order entry to establish an ROM estimate, timeline information and/or a cost estimate. As an example, an asset type may be CableLabs (CL) compliant, MP2, approximately 2 hours, 4 GB, movie class. In this example, the customer may know that the asset associated with the order is a movie stored in a CL compliant format, is approximately two hours in duration and has a size of about 4 gibabytes (GB). However, the customer (or DDC operator) does not have to be aware of more detailed information regarding the asset.

WO decomposer and optimizer 256, as described briefly above, receives information provided by order management system 220. In an exemplary implementation, WO decomposer and optimizer 256 establishes mappings from the work flow and quantities of assets to resource types and RCU reservations against NEs and User Groups (UGs) needed to execute the work flow. Work units may be instantiated in a database for each work order as tasks to be performed. WO decomposer and optimizer 256 may also generate task connectors that represent configured connectors in the work flow. Using presets/parameter selections across the work unit tasks for a particular work order, along with the selected asset types/quantities, WO estimator 254 may generate estimates by resource type for each work unit task in the work order, as described in more detail below.

In an exemplary implementation, NEs can provide multiple functions and each resource type that an NE can provide may be stored in a table or database. For example, FIG. 5A illustrates an exemplary table 500 storing information associated with two NEs (i.e., transcoder (TC) 1 and TC2) that may be used to transcode assets from one format into another format. Table 500 may be stored in databases 210 (FIG. 2). As illustrated in FIG. 5A, table 500 may include configuration field 502, resource type field 504, quantity field 506, type field 508, time unit field 510, sub-total field 512 and NE weight field 514. Configuration field 502 may represent the configuration of an NE and resource type field 504 may identify a resource/function provided by the NE in field 502. For example, TC1 and TC2 may represent the configuration of two NEs (i.e., transcoders in this example) that provide a common set of functions as illustrated in entries 520-524 and 530-536, respectively. That is, TC1 and TC2 both provide functions associated with transcoding content having an MP2 format into a windows media video (WMV) format (illustrated by entries 520 and 530), transcoding content having an audio video interleave (AVI) format into a WMV format (illustrated by entries 522 and 532), transcoding content having an MP2 format into a CableLabs compliant video on demand (CLVOD) format (illustrated by entries 524 and 534). TC2 may also transcode content having an MP2 format into a H.264 format, as illustrated by entry 536.

Quantity field 506 represents the number of RCUs available for the resource type. In this example, type field 508 and time unit field 510 indicate that the RCUs for TC1 and TC2 are represented as tasks per hour. The RCU value in field 506 may represent a maximum allocation that the NE/TC in field 502/504 can provide if it was only providing that resource type. For example, when NE-TC2 has a reservation for 20 RCUs for resource type AVI-WMV, all of the capacity associated with TC2 is consumed by the AVI to WMV transcoding and the other three resource types that TC2 is capable of providing (i.e., MP2-WMV, MP2-CLVOD, MP2-H.264) are no longer available, as described in more detail below.

Table 500 may also include weighting information for each task. For example, the values in sub-total field 512 for each NE add up to 1.0, and each value in field 512 represents the portion of total RCUs available for the particular resource type. For example, the value of 0.625 in field 512 of entry 520 represents the 20 RCUs available for MP2-WMV transcoding divided by the 32 total RCUs for TC1 (i.e., 20/32). NE weight field 514 is an inverse of the value in subtotal field 512. For example, the value in NE weight field 514 of entry 520 is 1/0.625 or 1.6, as illustrated in FIG. 5A. The weighting information may be used when calculating estimated RCUs needed to perform a task. As an example, if NE-TC2 is reserved for AVI-WMV transcoding, the available 20 RCUs will be multiplied by the weighting factor of 3.7 (illustrated in field 514 of entry 532) to generate a value of 74 as the total number of RCUs consumed. In other words, WO estimator 254 may multiply the weighting factor in field 514 by the RCU value in field 506 to generate a value identifying an estimated total RCUs consumed when performing a task.

WO estimator 254 may also calculate the total pooled RCUs by resource type. For example, WO estimator 254 may calculate values available for each resource type across a number of different network elements, and store this information in table 540, illustrated in FIG. 5A. Referring to FIG. 5A, table 540 may include resource type field 504, quantity field 506, quantity/total field 516, NE weight field 514 and RCUs available field 518. As illustrated, entry 542 may store the value 60 in quantity field 506, indicating that the combined total of RCUs associated with the use of TC1 and TC2 to perform MP2 to WMV transcoding is 60 RCUs. Similarly, entries 544, 546 and 548 store the values 30, 6 and 10, respectively, representing the total RCUs available from TC1 and TC2 to perform AVI to WMV transcoding, MP2 to CLVOD transcoding and MP2 to H.264 transcoding, respectively.

Quantity divided by total field 516 represents the percentage of available RCUs for each resource type, and NE weight field 514 represents the inverse of field 516. For example, the value of 0.28 in quantity/total field 516 of entry 544 represents the 30 RCUs available for AVI/WMV decoding divided by 106 total RCUs available. RCUs available field 518 represents the total available RCUs per resource type. As illustrated in table 540, 106 total RCUs are available across all resource types.

In an exemplary implementation, reservations for NEs are made against particular NEs since NEs are multi-functional with respect to resource type, as illustrated in table 500. As a result, use of one function will impact the capacity of other resource types. For example, when NE-TC2 has a reservation for 20 AVI-WMV, all of the capacity is consumed and the other three resource types illustrated in entries 530, 534 and 536 of table 500 are no longer available. For example, assume that 20 RCUs have been consumed for AVI-WMV transcoding by TC2, as illustrated in entry 552 of table 550 in FIG. 5B. Further assume that no other resources associated with TC1 have been consumed during this time. As illustrated in entry 552, 74 RCUs are consumed during the transcoding (20 multiplied by the weighting factor of 3.7 (table 500, entry 532, field 514). As a result, when NE-TC2 has a reservation for 20 RCUs for AVI-WMV transcoding, the availability associated with MP2-WMV transcoding for NE-TC1 and NE TC2 is reduced from 60 to 20, as illustrated in entry 562 in available resources table 560 in FIG. 5B. That is, the 40 RCUs identified in field 506 of entry 530 in table 500 (FIG. 5A) are no longer available. Table 570 in FIG. 5B illustrates the revised pool of available RCUs per resource type as a result of TC2 performing the transcoding associated with AVI to WMV transcoding discussed above with respect to table 550.

WO estimator 254 may also establish a mapping between configured asset types and RCU quantity and duration required to complete processing of the resource type. For example, FIG. 6 illustrates a mapping performed by WO estimator 254. In FIG. 6, table 600 illustrates asset type information used to generate an estimate for an order. Table 600 includes asset type field 602, asset class field 604, format field 606, estimated duration field 608, unit type field 610, estimated size field 612, resource type field 614, RCU quantity field 616, reservation duration field 618 and pool availability field 620.

Entry 630 in table 600 stores information indicating that a CL compliant movie provided in MP2 format has an estimated duration of 2 hours and an estimated size of 4 GB. Entry 630 also indicates that transcoding the CL compliant movie from MP2 format into a WMV format will consume 1 RCU for a 1 hour duration and that the available pool of RCUs is 20 per hour. Similarly, entry 632 in table 600 stores information indicating that a CL compliant movie preview originally provided in MP2 format has an estimated duration of 0.1 hours and an estimated size of 4 GB. Entry 632 also indicates that transcoding the CL movie preview from MP2 format to WMV format will consume 1 RCU for 0.25 hours and that the available pool of RCUs is 80 per hour.

Continuing with this example, suppose that a work order from a customer indicates that 65 CL compliant movies are to be transcoded from MP2 to WMV format, as indicated in entry 640 in FIG. 6. In this case, WO estimator 254 indicates a resource reservation requirement of 65 RCUs (i.e., 1 RCU for each of the 65 movies) and reservation duration of 4 hours, as illustrated by entry 640. That is, since 20 RCUs per hour are available, in each of hours 1-3, 20 movies may be transcoded (as illustrated in FIG. 6), resulting in consumption of 60 RCUs. In hour 4, the last five movies may be transcoded, for a total of 65 movies being transcoded in four hours.

Similarly, suppose that a work order from a customer indicates that 245 CL compliant previews are to be transcoded from MP2 to WMV format, as indicated in entry 650 in FIG. 6. In this case, WO estimator 254 indicates a resource reservation requirement of 245 RCUs and reservation duration of 4 hours, as illustrated by entry 650. That is, since 80 RCUs per hour are available, in each of hours 1-3, 80 movie previews may be transcoded, resulting in consumption of 80 RCUs. In hour four, the last five movie previews may be transcoded, for a total of 245 movie previews being transcoded in four hours.

In an exemplary implementation, WO estimator 254 may also take into consideration human resources (referred to herein as users) when generating estimates. For example, users may be associated with user groups (UGs) that perform various functions associated with executing work flows. For example, one UG may perform tasks, such as reviewing and approving work orders. Another group may be associated with performing assemblies associated with work flows that may require concatenating assets, as well as performing reviews and approvals. WO estimator 254 may map UGs to resource types for completing the necessary tasks to complete a work order.

For example, FIG. 7 is an exemplary table 700 illustrating resource to resource type breakdown associated with human resources. WO estimator 254 may access table 700 (e.g., a human resource task table) to establish a normalized capacity for the functions (e.g., resource types) that a human resource can complete per unit of time. In an exemplary implementation, a one hour time unit may be initially configured with respect to table 700. Table 700 may be used to estimate RCUs associated with human resources.

Referring to FIG. 7, table 700 includes resource field 702, resource type field 704 and plan quantity field 706. Resource field 702 may identify individual users, field 704 may identify resource types (e.g., functions) that may be performed by the user in field 702 and plan quantity field 706 may identify the estimated RCUs for each resource type.

For example, entry 710-1 indicates that resource/user Bob performs approvals and reviews and that the RCUs for these resource types take an estimated 50 and 20 RCUs, respectively. As further illustrated in entry 710-3, resource/user Joe performs approvals, reviews and assemblies and that the RCUs for these tasks consume an estimated 50, 20 and 10 RCUs, respectively. The total plan RCUs for the five users illustrated in table 700 are 280.

In addition, WO estimator 254 may establish a plan weight by function associated with UGs (similar to that described above for NEs). However, allocation of human resources may be at the UG level instead of being associated specific users. In this manner, tasks can be performed by any user of the User Group as long as his/her access is sufficient. For example, one user group may include Bob, Mary and Joe, and a second user group may include Joe, Susan and Reza. In this case, Joe may overlap into both of the UGs

WO estimator 254 may also review schedule information and based on the RCUs and duration required, provide estimated start and end date times for each work unit task, and as a result, provide an estimated start/end time for the entire work order. In an exemplary implementation, WO estimator 254 does not make any resource reservations regarding NEs/UGs. That is, resource reservation may be performed by other components (e.g., WO scheduler 258, runtime resource manager 260, etc.). WO estimator 254 may also generate estimated cost information, as described in more detail below.

WO scheduler 258 may include logic to match the estimates of each resource type required for each work unit for a work order into a timed schedule of allocations across network elements and user groups. For example, WO scheduler 258 may generate scheduled start/end times for each work unit task and resource reservations per its priority. WO scheduler 258 may store this information in WO schedule planner 410.

Referring back to FIG. 4, runtime resource manager 260 may include logic to interface with command processor 272 (FIG. 2) when allocating network elements/user groups at the time of execution. For example, runtime resource manager 260 may allocate network elements/user groups to a process at the time of execution on behalf of a work unit. Runtime resource manager 260 may also attempt to honor scheduled reservations of resources stored in WO schedule planner 410. However, if the resources are unavailable, runtime resource manager 260 may attempt to obtain replacement resources, as described in detail below.

Metrics collector 262, as described briefly above, may include logic that receives actual completion times by work unit and resource type from WO execution module. This information may be stored in metrics and statistics storage 420 and used to refine estimates for future work orders.

Jeopardy manager 440 may include logic that monitors ongoing work order processing. For example, jeopardy manager 440 may monitor actual completion metrics against expected completion rates/metrics. In one implementation, jeopardy manager 440 may trigger alarms and/or notices if the completion rates are beyond an acceptable threshold or will impact completion date/times of work orders in process or those that are scheduled for later execution.

As described above, resource management system 250 may break down customer orders into work unit tasks associated with a workflow and estimate time and/or costs associated with executing an order in accordance with the workflow. Resource management system 250 may also manage resources and scheduling information associated with network elements (NEs) and UGs in DDC 150, as described in more detail below.

FIG. 8 is an exemplary flow diagram illustrating processing associated with resource management system 250. Processing may begin with resource management system 250 receiving an order (act 810). For example, WO server 252 may receive a customer order from order management system 220. WO server 252 may forward the order to WO decomposer and optimizer 256.

WO decomposer and optimizer 256 may decompose the order (act 820). For example, as described above, WO decomposer and optimizer 256 may break down the customer order into a WO based on the associated work flow and preset parameter settings. In an exemplary implementation, WO decomposer and optimizer 256 may generate work unit tasks, task parameters and task connectors based on the work flow. After decomposing the work order, WO optimizer and decomposer 256 may forward the decomposed work order to WO server 252.

WO server 252 may receive the decomposed work order and save the decomposed work order. WO server 252 may also forward the decomposed WO to WO estimator 254. WO estimator 254, as described above, may generate an estimate associated with executing the work order (act 830). For example, FIG. 9 illustrates exemplary processing associated with generating an estimate.

Processing associated with generating an estimate may begin with WO estimator 254 identifying asset(s) or quantities by asset type associated with a work order and identifying resource types needed to fulfill the work order (act 910). For example, WO estimator 254 may identify a list of assets and/or the quantities of each asset type captured during order entry. Referring to the example described above with respect to entry 640 in table 600 in FIG. 6, WO estimator 254 may identify that 65 CL compliant movies are to be transcoded from MP2 to WMV format.

WO estimator 254 may use the list of assets and/or quantities of each asset type to generate an estimate of the number of RCUs needed for each work unit task (act 920). For example, continuing with the example described above with respect to entry 640 in table 600, WO estimator 254 may determine that 65 RCUs are needed to transcode the 65 CL compliant movies from MP2 to WMV format. As another example, WO estimator 254 may determine that 245 RCUs are need to transcode 245 CL compliant movie previews from MP2 to WMV format, as illustrated in entry 650 in table 600. In each case, WO estimator 254 may generate a value representing the total number of RCUs needed per resource type to execute each work unit task in the work order.

WO estimator 254 may also determine time requirements associated with executing each of the work unit tasks in the work order (act 920). For example, continuing with the example in FIG. 6, WO estimator 254 may determine that it will take four hours to transcode 65 CL complaint movies, as illustrated in entry 640 in FIG. 6. WO estimator 254 may also determine that it will take four hours to transcode 245 movie previews, as illustrated in entry 650 in FIG. 6

WO estimator 254 may also review the schedule of work orders awaiting execution. For example, WO estimator 254 may access WO schedule planner 410 and review a schedule of work orders awaiting execution. Based on the number of RCUs and duration required for the work order being estimated, WO estimator 254 may provide an estimated start and end time for each work unit task, and as a result, provide an estimated start and end time for the entire work order (act 930).

In an exemplary implementation, WO estimator 254 may also estimate or generate a risk factor associated with a work order (act 940). For example, during order entry, DDC 150 may allow a customer to request an order start date and time associated with when the customer would like the customer order completed. The customer requested completion date may drive a “priority” setting with respect to the work order. That is, the requested completion date may correspond to a standard/normal work order, an expedited work order or an emergency work order. WO estimator 254 may access business rules associated with estimating a work flow, including estimating whether the work flow can be completed within the desired time frame. If all the tasks in the work order are within defined business rule thresholds and can be fulfilled in the requested time frame at the requested priority, WO estimator 254 may assign a low risk factor to the work order. Orders with a low risk factor may be automatically approved. That is, no human intervention is required to approve work orders with a low risk factor.

In situations where the order may be done within a calculated risk factor (e.g., medium risk factor), WO estimator 254 may place the order in a review queue for “manual approval” by a DDC operator/administrator. In situations where the order cannot be completed within the requested time frame, WO estimator 254 may reject the order and request that the order be updated and resubmitted with a new requested completion date/time.

WO estimator 254 may also store the estimates (e.g., RCU and time estimates) and risk factor for each work unit task in, for example, WO schedule planner 410 (act 950). In an exemplary implementation, the estimated start and end times for each work unit task will not “lock” in the date/time for execution of the work units. That is, no resource reservation entries are made in a resource reservation schedule by WO estimator 254.

WO estimator 254 may further provide an estimated cost for the WO using, for example, a rate table, such as rate table 1000 illustrated in FIG. 10. Referring to FIG. 10, table 1000 may include billing plan field 1002, rate group field 1004, rate element field 1006, rate field 1008 and unit type field 1010. Billing plan field 1002 may include information indicating whether the task is performed on a standard basis, expedited basis, emergency basis or some other basis. The particular billing plan information stored in field 1002 may be based on the time frame with which a customer wishes to have an order fulfilled.

Rate group field 1004 may indicate the task or work unit to be executed, such as ingest, transcode, quality assurance, etc. Rate element field 1006 may include more particular information associated with rate group 1004. For example, rate element field 1006 may indicate particular tasks to be performed, such as transcoding, storage, inspection, etc. Rate field 1008 may include a rate per RCU. In this example, the rate may be in dollars per RCU. Unit type field 1010 may include units associated with the rate element, such as task or storage units (e.g., megabytes). As an example, entry 1020-4 indicates that an expedited transcoding from MP2 to WMV format has a cost of $4.00 per RCU.

WO estimator 254 may use rate table 1000 to generate a cost estimate for each task in a work order, and total the costs for each task to generate an overall cost estimate for the customer order (act 960). The cost estimate may be provided to the customer prior to the customer approving the order (act 960). In addition, the estimated schedule information associated with fulfilling the order may be provided to the customer to allow the customer to approve/reject the order based on the estimated completion time (act 960).

Referring back to FIG. 8, WO server 252 may also forward the work order to WO scheduler 258. WO scheduler 258 may receive the work order and check capacity associated with NEs and UGs needed to execute the work order (act 840). For example, WO scheduler 258 may access WO schedule planner 410 to identify and allocate resources for executing the tasks/work units of the work order (act 840).

WO scheduler 258 may then schedule execution of the WO (act 850). For example, WO scheduler 258 may match the estimates of each resource type required for each work unit into a timed schedule of allocations across the NEs and user groups. WO scheduler 258 may generate scheduled start/end times for each work unit task and reserve resources based on its priority. WO scheduler 258 may store the schedule information in WO schedule planner 410. WO scheduler 258 may also change the state of the work order to submitted/scheduled after all tasks have been scheduled. In some implementations, a DDC operator may approve the work order prior to the state of the work order changing to submitted/scheduled. After a work order is scheduled, runtime resource manager 260 may interact with DDC WOE system 270 to facilitate execution of the work order, as described in detail below.

FIG. 11 illustrates exemplary processing associated with execution of a scheduled work order. Processing may begin with runtime resource manager 260 accessing a schedule of work orders (act 1110). For example, runtime resource manager 260 may automatically access WO schedule planner 410 at regular intervals to identify any work order that is ready for execution at or near the current time. In this case, assume that a work order is ready for execution. Runtime resource manager 260 may initiate the execution of the work order (act 1110).

For example, runtime resource manager 260 may allocate NEs/UGs at the time of execution. In one implementation, runtime resource manager 260 may determine if the planned/schedule resources stored by WO scheduler 258 in WO schedule planner 410 are currently available (act 1120). That is, runtime resource manager 260 may attempt to honor the resources that were reserved by WO scheduler 258 during scheduling. For example, runtime resource manager 260 may check the current capacity to determine if planned resources are still available to fulfill the tasks in the work order. In some implementations, runtime resource manager 260 may also determine if the available resources minus the sum of the allocated resources plus the resources required for the particular task is not a negative value. If the reserved resources are available (act 1120—yes), runtime resource manager 260 may execute the work order (act 1130). That is, runtime resource manager 260 may signal WOE system 270 to execute the work unit tasks of the work order using the reserved resources. Runtime resource manager 260 may also update a calendar and the state of the corresponding resource reserve schedule with the actual start time of the execution.

If, however, the resources are not available at the time of execution (act 1120—no), runtime resource manager 260 may check current capacity associated with NEs/UGs and attempt to allocate alternate resources as necessary (act 1140). For example, suppose that a task associated with transcoding an asset has reserved TC1 as the transcoder to be used. Further assume that TC1 is busy/unavailable at the scheduled time, but that TC2 is available. In this case, runtime time resource manager 260 may identify TC2 as being the transcoder to be used for the transcoding task, as opposed to TC1. In each case, runtime resource manager 260 may allocate alternative resources if possible. In other instances, runtime resource manager 260 may schedule the work order, or tasks associated with the work order at a different time.

In this example, assume that runtime resource manager 260 has identified alternative resources and reserved the alternative resources. Runtime resource manager 260 and/or WOE system 270 may execute the work order (act 1150). For example, runtime resource manager 260 may signal WOE system 270 to execute the work order using the reserved resources.

In an exemplary implementation, WO scheduler 258 and/or runtime resource manager 260 ensures that schedules are established to provide high utilization of network elements. For example, FIG. 12 illustrates an example in which two NEs (i.e., TC1 and TC2) are scheduled to execute tasks associated with 11 different work orders (i.e., WOs 1-11). As illustrated, TC2 may execute tasks associated with WO1, WO4 and WO5 in hour number one. Concurrently, TC1 may execute tasks associated with WO2, WO3 and WO9 in hour number one. In hour two, TC2 may execute tasks associated with WO6 and WO7 and TC1 may execute tasks associated with WO10 and WO11. In hour three, TC2 may execute tasks associated with WO8. In this manner, WO scheduler 258 may overlap schedules to allow TC1 and TC2 to be used in an efficient manner. As illustrated, the total allocated capacity associated with use of TC 1 and TC2 in hour number one is close to the total native or overall capacity of TC1 and TC2. The total allocated capacity, of TC1 and TC2 however, varies more greatly from the total native capacity in hours two and three in this example.

As described above, resource management system 250 may decompose, schedule and estimate work orders. In addition, in some implementations, WO decomposer and optimizer 256 may take into consideration optimizations that may be performed with regard to asset re-use within a work order. For example, WO decomposer and optimizer 256 may re-use assets that have been previously processed and that are still available in working storage or are available to be pulled from an archive to avoid re-processing a task through quality assurance, transcoding, encryption, etc. That is, if an asset has already been processed and may be used by another workflow/task, or by the same workflow task (when a problem has occurred during processing), the asset may be re-used.

WO decomposer and optimizer 256 may also take into account work units that may be performed in parallel, as opposed to work units that must be performed in a pipelined or serial manner. WO decomposer and optimizer 256 may use any such parallel processing to compress the overall execution time of a work order. In this manner, WO decomposer and optimizer 256 may streamline work order processing.

As described above, DDC 150 may optimize the overall use of resources, such as network elements 276 and user groups/human elements, to fulfill customer orders. FIG. 13 illustrates an exemplary portion of DDC 150 that may include components to aid in optimizing resource usage. Referring to FIG. 13, DDC 150 may include resource manager event handler 1310, resource manager 1320, resource manager scheduler 1330, event scheduler 1340, resource allocator 1350, schedule evaluator 1360, work order level jeopardy handler 1365, work order estimator 254, task estimator 1370, schedule searcher 1375, calendar 1380, task jeopardy detector 1390 and task level jeopardy handler 1395. All or some of the components illustrated in FIG. 13 may be implemented in resource management system 250 (e.g., by processor 320, FIG. 3) or other portions of DDC 150. In addition, the functional blocks illustrated in FIG. 13 are exemplary. In other implementations, additional or different components may be included in DDC 150. In addition, in other implementations, the functions described below as being performed by one component in FIG. 13 may be performed by another component. Further, the functions described as being performed by one component may be performed by multiple components, and vice versa.

Resource manager event handler 1310 may handle mapping of request parameters to various resource manager objects. For example, resource manager event handler 1310 may construct work order objects and task objects based on received parameters in customer order related requests. Resource manager event handler 1310 may also map calendar objects associated with, for example, calendar 1390, to response parameters to be used by other components illustrated in FIG. 13.

Resource manager 1320 may interface with resource allocator 1350 and schedule evaluator 1360 to schedule or re-schedule a work order or selected tasks included in a work order. For example, resource manager 1320 may determine that a scheduled work order may not be able to be executed within the initially estimated time frame. In such a scenario, resource manager 1320 may re-schedule the work order, as described in more detail below.

Resource manager 1320 may also interface with resource allocator 1350 to perform run-time allocation and/or de-allocation of resources. Resource manager 1320 may further construct a calendar entry in calendar 1380 associated with work orders for the time period to be used by a particular work order.

Resource manager scheduler 1330 may schedule the use of resources (e.g., NEs and UGs) involved in executing a work order. Event scheduler 1340 may schedule the actual execution of work orders. Event scheduler 1340 may also change the state of a work order after the work order is initiated and after the work order is completed.

Resource allocator 1350 may allocate the resources to be used during execution of an actual work order. Resource allocator 1350, as described above, may communicate with resource manager 1320 to allow resources to be allocated to particular work unit tasks.

For example, resource allocator 1350 may access a schedule of tasks to determine whether a particular task is scheduled. Resource allocator 1350 may also be aware of resources allocated to the particular task and includes logic to find all resource allocations of a particular type in a particular time window, as well as identify available resources at any calendar interval. For example, resource allocator 1350 may search for a next free slot in calendar 1380, determine the available RCUs in the free slot for each resource type, reserve a calendar slot and create a new calendar entry in calendar 1380.

Schedule evaluator 1360 may store a list of primary and alternate schedules associated with a work order. Schedule evaluator 1360 may also store business policies/rules that allow schedule evaluator 1360 to derive the best schedule out of a list of potential schedules. For example, schedule evaluator 1360 may store a business policy indicating that when allocating a network element (NE) for a task, the amount of RCUs available from a particular NE (e.g., an allocation level) is considered when scheduling. For example, one business rule may indicate that a particular NE may only be scheduled for 90% of its capacity. Another business/scheduling policy may indicate that a high capacity NE is to be used before a lower capacity NE. Using a higher capacity NE may allow DDC 150 to compensate for any problems associated with an NE executing the task. That is, using a higher capacity NE may provide for more tolerance when a problem occurs, as opposed to using an NE with a lower capacity. Still another business policy may indicate that contiguous calendar intervals are to be used for various tasks in a work order, or that split calendar intervals may be used, depending on the type of tasks and/or priorities associated with the tasks.

Work order estimator 254, as described above, receives information identifying the tasks and work units associated with a work order. Work order estimator 254 may also access calendar entries associated with scheduled work orders and generate a calendar entry regarding a work order. WO estimator 254 may also access primary and alternate schedules for the same work orders using different policies.

Work order level jeopardy handler 1365 may communicate with schedule evaluator 1360 to determine if a particular work order will require revising or optimizing. For example, work order level jeopardy handler 1365 may modify the scheduling of a high priority work order by re-scheduling one or more lower priority work orders. In some implementations, work order level jeopardy handler 1365 may identify unscheduled lower priority work orders, and schedule such lower priority work orders after scheduling the higher priority work orders.

Task estimator 1370 may determine the total resources required for a task. Task estimator 1370 may also impose a maximum account percent limit for estimation purposes. For example, task estimator 1370 may not load a particular NE above a maximum level associated with the available RCUs when estimating the availability of the particular NE. This may provide some tolerance with respect to the actual execution phase using that particular NE.

Task estimator 1370 may also determine a next available slot in which a task can be scheduled (start-time and end-time) and/or determine if the task needs to be split into multiple sub-tasks if the needed resources are not available in contiguous calendar time intervals.

Schedule searcher 1375 may access calendar 1380 and identify schedules that meet requested resource requirements without revising any existing, pre-scheduled resource allocations.

Calendar 1380 (also referred to as calendar node 1380) may store schedules associated with a number of work orders that are scheduled for execution. Calendar 1380 may also store information identifying resources to be used for each of the scheduled work orders, capacities of various network elements (e.g., in RCUs) per resource type that are available in various intervals, etc. Calendar node 1380 may also obtain the percentage utilization of the associated NEs for a resource type, reserve RCUs for a particular calendar interval, obtain the list of NEs that are used in the calendar interval, update the list of NEs that are used in the calendar interval, obtain the list of resource types that are used in the calendar interval, and update the list of resource types that are used in the calendar interval.

Resource allocator 1350, and other functional components illustrated in FIG. 13, may use the information stored in calendar node 1380 (e.g., available capacities per resource type in a given time interval) to determine the remaining capacity for any resource type in any interval of time. Resource allocator 1350 may also use this information to allocate resources for a particular task during any interval of time interval.

Task jeopardy detector 1390 may communicate with task estimator 1370 and determine whether a task can be completed before the estimated task end time. If a scheduled task cannot be completed by its scheduled end time, task jeopardy detector 1380 may interact with task level jeopardy handler 1395. Task level jeopardy handler 1395 may perform various functions associated with analyzing various optimizations associated with various tasks, as described in more detail below.

As described above, work order level jeopardy handler 1365 may determine whether a particular work order will require revising or optimizing. FIG. 14 illustrates work order level jeopardy handler 1365 in accordance with an exemplary implementation. Referring to FIG. 14, work order level jeopardy handler 1365 includes jeopardy detector 1410, reschedule opportunity analyzer 1420, cancellation generator 1430, trial calendar 1440 and rescheduling policies 1450.

Jeopardy detector 1410 may be implemented by jeopardy manager 440 (FIG. 4) and may determine whether a work order will be able to be completed in the scheduled time. Reschedule opportunity analyzer 1420 may determine whether enough RCU capacity (actual available RCU capacity or available RCU capacity based on cancellable jobs) exists in a given window to allow a work order to be scheduled for the desired time window. In an exemplary implementation, reschedule opportunity analyzer 1420 may not compute the schedule, just the feasibility of finding a schedule.

Cancellation generator 1430 may identify and order items that should be cancelled to find a workable schedule. For example, cancellation generator 1430 may communicate with reschedule opportunity analyzer 1420 to identify and prioritize cancellations to minimize the number of cancellations and allow high priority work orders to be scheduled.

Trial calendar 1440 may model or generate a possible calendar for handling work orders that are in a jeopardy condition. For example, trial calendar 1440 may initially include a copy of existing calendar entries stored in calendar 1390 and indicate temporary or possible cancellations of already scheduled low priority orders.

Rescheduling policies 1450 includes a memory or database storing business policies or rules associated with rescheduling tasks of a work order, or a complete work order. For example, one business rule may indicate that only low priority work orders may be rescheduled to accommodate expedited or high priority work orders.

The functional components of work order level jeopardy handler 1365 illustrated in FIG. 14 and described above may perform various processes associated with work orders that may be in a jeopardy condition. Work order level jeopardy handler 1365 may attempt to find alternate schedules that will accommodate and meet the business rules associated with operation of DDC 150.

As described briefly above, task level jeopardy handler 1395 may interact with task jeopardy detector 1390 to perform various processes associated with handling tasks that may be in the jeopardy condition. In other words, task level jeopardy detector 1395 may operate on a lower granular level (e.g., task level) with respect to jeopardy conditions than work order level jeopardy handler 1365.

FIG. 15 illustrates task level jeopardy handler 1395 in accordance with an exemplary implementation. Referring to FIG. 15, task level jeopardy handler 1395 includes task opportunity analyzer 1510, non-optimizing analyzer 1520, optimizing analyzer 1530, preemptive analyzer 1540, cancellation generator 1550, rescheduling policies 1560 and trial calendar 1570.

Task opportunity analyzer 1510 may include logic for determining whether enough RCU capacity and/or time (actual RCUs available or RCUs available via cancellable jobs) exists in a given window to allow one or more tasks of a work order to be scheduled. In an exemplary implementation, task opportunity analyzer 1510 does not compute the schedule, just the feasibility of finding a schedule that meets the desired goals. For example, task opportunity analyzer 1510 may determine if there is an adequate availability of RCUs for the identified resource type in a given window to meet a particular scheduled task or request.

Task opportunity analyzer 1510 may also compute the maximum free space that could be available in the current time window if tasks were moved/re-scheduled. Task opportunity analyzer 1510 may further compute how much a window of time needs to be enlarged to accommodate tasks that may need to be rescheduled outside the current time window. Task opportunity analyzer 1510 may further determine if cancelled resources can be rescheduled in expanded windows. In some instances, this expansion determination may be computed iteratively. That is, task opportunity analyzer 1510 may expand a window via several discrete time steps/expansions to determine how much the time window needs to be expanded.

In one implementation, task opportunity analyzer 1510 may generate an “optimization delta”. The optimization delta may identify a schedule change that may need to be made. For example, the optimization delta may identify all allocations that need to be cancelled, as well as all tasks associated with cancelled allocations. As part of the optimization delta, task opportunity analyzer 1510 may determine what new allocations will be scheduled for the “new” task and what new allocations will be needed to reschedule the cancelled tasks. In an exemplary implementation, task opportunity analyzer 1510 may maintain an externally specified order on the allocations and cancellations that are identified. The externally specified order may correspond to priorities associated with the tasks/work orders that are to be executed.

In an exemplary implementation, task opportunity analyzer 1510 may communicate with a number of different types of analyzers. For example, as illustrated in FIG. 15, task opportunity analyzer 1510 may interface with non-optimizing analyzer 1520, optimizing analyzer 1530 and preemptive analyzer 1540. Non-optimizing analyzer 1520 may include logic that identifies schedules that meet the requested resource requirement without revising any existing resource allocations. In one implementation, non-optimizing analyzer 1520 identifies a best/first fit schedule, if one exists. Non-optimizing analyzer 1520 may also determine whether a non-optimized fit is not possible in the selected time window. If a non-optimized fit is not possible, non-optimizing analyzer 1520 may apply scheduling policies to select from among resources of similar capabilities to attempt to generate a workable schedule.

Optimizing analyzer 1530 may include logic that identifies schedules that meet the requested resource requirement and that involve rescheduling or moving previously scheduled tasks. In one implementation, optimizing analyzer 1530 may identify proposed schedules that allow all tasks, new and previously scheduled, to be serviced within the originally scheduled time and in accordance with other order-related requirements.

Optimizing analyzer 1530 may also identify and cancel tasks that need to be rescheduled to meet the scheduling constraints of the new task. Optimizing analyzer 1530 may also rank potential schedules based on business policies, such as how many orders will be disturbed/changed, and identify a first/best fit for a new task and rescheduled tasks in an appropriate order. Optimizing analyzer 1530 may also construct an optimization delta and apply scheduling policies to select from among resources of similar capabilities.

Preemptive analyzer 1540 may include logic to identify schedules that allow a new task to meet order requirements even if it causes certain other previously scheduled tasks to no longer be schedulable in a way that meets all their order requirements. Preemptive analyzer 1540 may determine when a preemptive action that conforms to preemption policies is not possible. Preemptive analyzer 1540 may also rank potential schedules based on business policies, such as what is the total penalty for jobs “dropped” in a proposed schedule, and determines how to apply scheduling policies to identify and cancel tasks that may be considered “expendable” when an acceptable preemptive schedule is possible. Preemptive analyzer 1540 may also identify a first/best fit for a new task and rescheduled tasks in an appropriate order. Preemptive analyzer 1540 may further construct an optimization delta, and apply scheduling policies to select from among resources of similar capabilities.

Cancellation generator 1550 may identify and order items that are to be cancelled. Cancellation generator 1550 may also prioritize cancellations to improve the probability of minimizing the number of cancellations.

Rescheduling policies 1560 includes a memory or database storing business policies or rules associated with rescheduling tasks. For example, one business rule may indicate that tasks associated with a low priority work order may be rescheduled to accommodate tasks associated with higher priority (e.g., expedited) work orders.

Trial calendar 1570 may model or generate a possible calendar (or partial calendar) for handling tasks that are in a jeopardy condition. For example, trial calendar 1570 may initially include a copy of the existing calendar and indicate temporary or possible cancellations of already schedule low priority tasks.

The functional components of task level jeopardy handler 1395 illustrated in FIG. 15 and described above may perform various processes associated with tasks that may be in a jeopardy condition. Task level jeopardy handler 1395 may attempt to find alternate schedules that will accommodate and meet the business rules associated with operation of DDC 150, as described in more detail below.

As discussed above with respect to FIG. 11, runtime resource manager 260 may perform various functions with respect to allocating resources at runtime. As also discussed above with respect to FIGS. 13-15, DDC 150 may perform resource optimization prior to runtime to allow DDC 150 to perform tasks associated with large numbers of customer orders in an efficient manner and in accordance with business policies associated with the entity operating DDC 150.

FIG. 16 illustrates exemplary processing associated with performing resource optimization. Processing may begin with resource allocator 1350 accessing a schedule and identifying a task and the resources scheduled to fulfill the task (act 1610). For example, prior to runtime, resource allocator 1350 may access a schedule of tasks stored in calendar 1380 and determine if the scheduled resources are available to complete the tasks in the scheduled intervals (act 1620). If all the tasks are able to be completed in the scheduled time frames, resource allocator 1350 may perform no additional action and the tasks will execute at the scheduled times (act 1630).

If, however, the scheduled resources are not available to perform a particular task (act 1620—no), resource allocator 1350 may determine if alternate resources are available for the task (act 1640). For example, resource allocator 1350 may check the available RCUs associated with other NEs that may be used to perform one or more of the scheduled tasks. As an example, assume that the task includes transcoding a movie from an MP2 format to a WMV format and transcoder 2 (TC2, FIG. 5A) was originally assigned to perform the transcoding. Further assume that TC2 is no longer available to perform the transcoding. In this case, resource allocator 1350 may identify TC1 as having adequate available capacity to perform the transcoding in the scheduled time frame (act 1650). In some instances, resource allocator 1350 may split a single task into sub-tasks for execution in the desired time frame. For example, if a movie could be transcoded from an MP2 format into another format, followed by transcoding the movie into the WMV format, resource allocator 1350 may identify the appropriate sub-tasks and identify the resources to be used for each of the sub-tasks. In each case, if alternate resources are available, resource allocator 1350 may schedule the alternate resources (act 1660). Runtime resource manager 260 may then utilize the assigned resources at runtime and work order execution system 270 may execute the tasks at the scheduled time (act 1660).

Referring back to act 1640, if alternate resources are not available in the scheduled time frame, resource allocator 1350 may reschedule one or more of the tasks for a different time period (act 1670). In this case, the rescheduled tasks will be executed at the newly scheduled times.

As discussed above with respect to FIG. 15, task opportunity analyzer 1510 may interface with a number of different analyzers (e.g., non-optimizing analyzer 1520, optimizing analyzer 1530 and preemptive analyzer 1540) based on the particular tasks and/or work orders associated with the tasks. For example, task opportunity analyzer 1510 may communicate with optimizing analyzer 1530 to identify an optimal schedule for a particular task/work order, as described in more detail below.

FIG. 17 illustrates exemplary processing associated with optimizing analyzer 1530. Processing may begin with task opportunity analyzer 1510 analyzing a schedule associated with tasks of a work order (act 1710). For example, task opportunity analyzer 1510 may access calendar 1380 and identify a schedule for a work order. Task opportunity analyzer 1510 may then determine whether any optimizing is required (act 1720). For example, task opportunity analyzer 1510 may determine whether one or more of the tasks may not be able to be executed in the desired time frame. If no optimizing is required, work order execution system 270 (FIG. 2) may execute the tasks at the schedule times (act 1730).

If, however, task opportunity analyzer 1510 determines that some optimizing is required (e.g., one or more of the tasks may not be able to be executed in the scheduled time frame), task opportunity analyzer 1510 may communicate with one or more of analyzers 1520, 1530 and 1540. In this example, assume that task opportunity analyzer 1510 communicates with optimizing analyzer 1530 based on the type of tasks to be scheduled/executed.

Optimizing analyzer 1530 may identify tasks that need to be rescheduled to meet the scheduling constraints of a task that is in the “jeopardy” condition (act 1740). Optimizing analyzer 1530 may then identify or generate one or more potential schedules that allow all tasks, new and previously scheduled, to be serviced within the originally scheduled time frames and in accordance with any other order-related requirements (act 1750). Optimizing analyzer 1530 may also rank the potential schedules based on business policies, such as how many orders will be disturbed by the rescheduling. For example, optimizing analyzer 1530 may rank a potential schedule with the least amount of rescheduling to be the most desirable schedule. In each case, optimizing analyzer 1530 may identify a first/best fit for a new task and/or rescheduled tasks in an appropriate order (act 1750). Optimizing analyzer 1530 may also construct an optimization delta and apply scheduling policies to select from among resources of similar capabilities to fulfill rescheduled or new tasks.

Task opportunity analyzer 1510 may then select the best schedule for execution (act 1760). Task opportunity analyzer 1510 may then store the schedule in calendar 1380 for later execution. In this manner, task opportunity analyzer 1510 may optimize the use of resources (e.g., NEs and UGs) in DDC 150 to allow DDC 150 to function according to business policies/rules of the entity operating DDC 150.

Implementations described herein provide an infrastructure for allowing customers to submit orders for processing content, such as media content. The infrastructure may also generate schedules associated with processing orders in accordance with business policies and determine optimum schedules based on customer requirements and the business policies.

The foregoing description of exemplary implementations provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the embodiments.

For example, features have been described above with respect to resource management system 250 performing various tasks to schedule and reserve resources for executing tasks of a work order. In other implementations, other components, systems, platforms, etc., in DDC 150 may perform these tasks. In addition, in some implementations, network 100 may include multiple DDCs 150.

In addition, tasks associated with a work order that involves transcoding a media file have been described above. It should be understood that other types of orders may be processed by DDC 150. For example, other types of orders may include inserting advertisements, logos or watermarks into a media file, concatenating a second media file to the media file (e.g., concatenating episodes of a series together), inserting black space into at least a portion of the media file, performing audio transcoding on the media file, performing image/audio overlay on the media file, etc.

Further, while series of acts have been described with respect to FIGS. 8, 9, 11, 16 and 17, respectively, the order of the acts may be varied in other implementations. Moreover, non-dependent acts or signal flows may be implemented in parallel.

It will be apparent that various features described above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement the various features is not limiting. Thus, the operation and behavior of the features were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the various features based on the description herein.

Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as one or more processors, microprocessors, application specific integrated circuits, field programmable gate arrays or other processing logic, software, or a combination of hardware and software.

In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

RESOURCE OPTIMIZATION

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims