Distribution main line

FIELD: information technology.

SUBSTANCE: method for digital distribution of media content using a distribution main line system comprises steps of receiving a media content request from a client, the request including the profile of the client; performing inventory check and analysis of source assets by iteratively going through the client profile to generate output data; mapping functionalities, wherein several rules enable to map source assets onto the client profile; and scheduling the production process, which determines work elements and execution steps based on functionalities mapped in response to the media content request from the client.

EFFECT: automation of a process which downloads content in digital format and seamlessly manages said content by delivering to the client.

27 cl, 23 dwg

 

The technical field to which the invention relates.

The present invention relates to digital multimedia data, and more specifically to digital distribution of multimedia data.

The level of technology

With the development of production and distribution of multimedia data, quickly moving towards a fully digital, it would be advisable to provide for the automation of business processes and the compatibility of the various digital formats/devices that require the integration of both software and hardware. However, there are several obstacles to training in Leipzig process and the compatibility of different digital formats/devices in the production of multimedia data. For example, currently there is no comprehensive system of technological process, there are no standards, there is anecdotal decisions about software and hardware, and there has been a General lack of a mechanism to replace manual labor, specific to the process.

Disclosure of inventions

In embodiments implementing the present invention proposed digital distribution of media content using the system bus of the distribution.

In one embodiment, disclosed a method of digital distribution media Conte is the system using mainline distribution. The method includes steps in which: receive a request for media content from a client, where the request includes a client profile; perform inventory and analysis of assets source using iterative pass through the customer profile to generate output data; perform the mapping of opportunities, in which the number of rules allows you to display assets source on the customer profile; and plan the production process, which determines work items and milestones based on the capabilities displayed in response to a request for media content from the client.

In another embodiment, the disclosed system mainline distribution. The system includes: a parsing engine for receiving a request for media content from a client, including a client profile, the analysis of the production is intended to perform an inventory and analysis of assets source using iterative pass through the customer profile to generate output data analysis; and planning production, made with the ability to identify work items and execution phases using the output of the analysis.

In yet another embodiment, a disclosed computer-readable storage medium storing a computer program for digital distribution of media contacts the NTA. The computer program includes executable commands that cause the computer to receive a request for media content from a client, where the request includes a client profile; inventory and asset intelligence source using iterative pass through the customer profile to generate output data; perform the mapping of opportunities, in which the number of rules allows you to display assets source on the customer profile; and to plan the production process, which determines work items and milestones based on the capabilities displayed in response to a request for media content from the client.

Other features and advantages of the present invention will become more apparent to experts in this field of technology after consideration of the following detailed description and accompanying drawings.

Brief description of drawings

Figure 1 - the precedence diagram illustrating the process of digital distribution of media content using the highway distribution, according to one variant of implementation of the present invention.

Figure 2 - block diagram of the system bus of the distribution, according to one variant of implementation of the present invention.

Figure 3 is an algorithm illustrating the digital distribution of media content using the system bus of the distribution, according to one variant of implementation of the present invention.

4 is a detailed diagram of the delivery requirements and customer profiles that contribute to the production planning.

5 is a exemplary case of the example of using the client profile.

6 - multiple sets of preferences source and specifications, which represent the range of results that can be received by the client.

7 is one example of inventory status.

Fig - case model use, where data is extracted from assets source when they are detected.

Fig.9 - the data collected from the assets identified in the request for analysis.

Figure 10 - case specific use display capabilities.

11 - case specific use of production planning.

Figa illustrates the performance of the computer system and the user.

Figw - functional block diagram illustrating a computer system that runs the hosting process for mainline distribution.

Fig is an exemplary diagram showing the relationship of objects depicting how Partners and Customers presumably associated with client Profiles, Specifications, and Configurations.

Fig displays the primary inputs in the module Service Request.

Fig shows an exemplary hierarchy motorassisted between name, which has two alpha (Director's cut and Theatrical version), and a collection of components that are identified for maintenance Directing the alpha Version.

Fig - list of values of image Format that will limit the asset if he will be considered for this component Type.

Fig - describes the role of Master data process using DBB. The shaded blocks represent the election specified by the Requesting party.

Fig shows the processing tasks of the technological process and composition described in functional groupings.

Fig shows how to use the functionality of a Managed tiered storage medium for data (MMSE), which includes the ability to move files between storage tiers.

Fig depicts the Encoding process and Control Loading of content that must be orchestrated using DBB.

Fig is an exemplary diagram showing the relationship of objects depicting the relationship between a customer profile associated with it metadata specifications and supporting data required to build the batch metadata in accordance with this specification.

Fig is an exemplary diagram showing the relationship of objects depicting how the Packages were believed to be linked with customer Profiles and Spa is by the changes.

The implementation of the invention

Embodiments of which are disclosed here, describe systems, methods and apparatus for digital content distribution, which provides automation of technological process, which loads the content in digital format and manages seamless by delivery to the client. After reading this description it will become clear how to implement the invention in various alternative embodiments, implementation and alternative applications. However, despite the various embodiments of the present invention, which will be described in the present invention, it should be understood that these embodiments of presented only as examples and not limitations. As such, this detailed description of various alternative embodiments should not be construed to limit the scope or coverage of the present invention.

Figure 1 shows a diagram 100 of a sequence of operations illustrating the process of digital distribution of media content using the highway distribution, according to one variant of implementation of the present invention. Examples of media content include movies, songs, software and games.

Shown in figure 1 embodiment, the queries are produced and presented Auda in block 110 for licensing content and perform that content for licensees. These requests take many forms depending on the changes of the feeding organizations and types of license agreements. Execution operation performs the necessary analysis to identify key information about the content ID (which is the Name/alpha), the client, which will be serviced, and the terms of service, such as the due date.

The next step in the implementation process is the analysis of the requirements for the inventory unit 120. To generate the production plan, which will lead to the creation of results necessary for the licensee, the inventory analysis is conducted for each Title/alpha. This analysis begins with determining the final results (i.e. products)required by the licensee, and processes at each level of components used for producing products from a master copy in a discrete video, audio and text components to the master of the original, created in the production. For each requirement of the client this process in different forms through the operation of the service or provider.

After becoming known the status of the inventory for each Title/alpha, in block 130 is determined and generated production plan.

This plan may include a small number of stages, such as DL the requirements for copying and shipping or may require more complex production, which may include processes such as transformation with decreasing frequency, the audio and the use of subtitles before copying and shipping. The production plan is determined based on the existing inventory components and knowledge of the manufacturing process. Analysis of inventory and production planning, described in more detail below.

Immediately after the approval of the production plan, it is issued for execution in block 140. This process includes activities that applies to the purchase or own production, which includes automation technology management, content processing, such as file management, transcoding, packaging and shipping, which are operated using standard data interfaces.

The process of packaging and shipping (which is performed in block 150) supports continuous automated process execution. The products are delivered in accordance with the standard with the support of media and metadata in order to use the content management system of the client. Modification of these standards requires flexibility in the management of information and the support of the media.

Figure 2 presents the block diagram of a system 200 highway distribution, according to gnome variant implementation of the present invention. Shown in the figure 2 embodiment, the block diagram illustrates the objects and processes necessary to perform analysis, and develop a production plan. Thus, the system 200 highway distribution includes specification 230 delivered to the customer (including the profile 210 of the client), the mechanism 240 analysis of production, mechanism 250 production planning, inventory auxiliary data 260 and master data 270 of the process. Mechanism 250 planning production runs or uses source 252 asset components, processes 254 and analysis 256 cost and time of the production cycle.

In one embodiment, an automated process based on master data 270 (see Annex 5 for detailed description) and supports several parallel technological processes inventory and content processing. Mechanism 250 production planning uses these master data 270 to develop specific operational plans in response to requests from clients. These production targets are a core set of commands for managing content processing and generation of information items required to estimate the costs and time of the production cycle.

Mechanism 240 analysis of production is DSTV uses master data 270 process and inventory auxiliary data 260 (see Annex 4 for detailed description) along with input from the module requests (see Annex 2 for detailed description), which deals with the relationship partner client and how to develop the queries. Using the specification 230 delivered to the client, the mechanism 240 production analysis identifies the appropriate process. In a process that can identify all the tasks required to create the customer's specification. In addition, determine the use of all necessary types of components for each task. With this information, the mechanism 240 first performs analysis of materials. The system 200 highway distribution queries the inventory for the required components for the specified Name/alpha 220 and specifications 230 delivered to the client. The results of this analysis determine the tasks necessary to complete the required process.

As described in Appendix 5, the technological processes on the basis of the specifications of the client should consider scenarios for inventory. These processes should cover the encoding and downloading the required inventory component through delivery. They should be essentially modular and provide the flexibility to handle scenarios where it is necessary to inventory the local is seeking a greater degree of readiness. Mechanism 240 production analysis performs analysis to determine the specific processes required to create the necessary product.

Process line distribution may include transcoding the file with a higher resolution in the file with a lower resolution, which is then packaged and delivered. In addition, the operation of the highway distribution can create a lower resolution file and save it in a file storage system, as an alternative master resolution restriction. In this case, the process will require a request inventory in order to determine that there is a file with a lower resolution, and to choose an alternative process for copying and file delivery with lower resolution and not to transcode the file with a higher resolution.

Depending on the detailed design may be necessary to re-start production plan in order to evaluate the costs and time of the production cycle before performing the actual technological processes due to the dynamic nature of the inventory of assets.

Figure 3 shows the algorithm 300 illustrating technology for digital distribution of media content using the system bus of the distribution, according to one variant of implementation of the present invention. Shown in figure 3 embodiment, the digital distribution includes the steps in which: perform requirements gathering and delivery of customer profiles in block 310, perform an inventory and analysis of assets source in block 320 using iterative pass through the set of requirements for the creation of the output (see Fig.6 and Fig.7. for the case of particular use in the analysis of materials); perform the mapping capabilities in block 330 (see description Fig - figure 10 for the case of a specific use display features); plan production process in block 340 (see 11 for a detailed description of the production planning); and perform optimization in block 350 (see below).

Requirements to delivery and customer profiles define a specific set of requirements/specifications for content, delivery and the metadata requirements for the client. Customer profiles are used to define the requirements of each client for content delivery. One or more client profiles can be set based on one client to represent numerous business models for this client, to represent requirements, which vary depending on the territory, or other business/those who practical reasons. The specifications define key variables and requirements needed to support automated and manual processes. So how is the master specification, one specification can be associated with multiple clients. Display capability includes a number of rules that allow you to display assets source in the specification of the client. Production planning determines the elements of the work, the stages of implementation and optimization. In another embodiment, the system backbone distribution identifies the necessary assets source and creates a production plan that will deliver the content based on the specifications of the client.

Figure 4 shows a detailed diagram of the delivery requirements and client profiles that contribute to the production planning. As was discussed above, the client profile is a specific set of requirements that define the requirements to the content, delivery and metadata to the client. In one embodiment, the customer profile includes specification 410 package, preferred 420, technical specification 430 and specification 440 for the Assembly. Specification 410 package defines discrete elements that must be delivered to the client for execution of requests made by the client, and includes specification 12 content and specification 414 metadata. Preferences 420 are specific requirements for the client, which guide the choice of assets source and limit or weaken the possibility of production line distribution. Technical specification 430 represents the requirements that are not based on the content that define the codec, frame rate, image resolution and other technical parameters file-based. Specification 440 for Assembly defines any requirements for non-linear editing, such as changing the logo, stretch/change shades of black, or add cards. Specification 412 content includes reusable technical specifications, Assembly specifications and data preferences.

In one case, an exemplary use of the client profile, shown in figure 5 - Fig, customer Conocemos (CinemaSpace) and customer profile for internal end-to-end sales (DST) have been identified by the user for the Name "Plane" alpha "Theatre". Figure 5, technical specifications are given for illustration of the willingness of the client to receive the content aspect ratio of 16×9 frame rate 23, 98. However, additional technical specifications also show that the ability to accept a variety of formats based on the available inventory for the Name/alpha. Specification Assembly provides the AET data directly in the production plan to use when creating a profile transcode, as well as data from the technical specifications.

Specification of the content presented on Fig.6 shows multiple sets of preferences source and technical specifications, which represent the range of results that the client can accept. They also rank in order to Express the preferences of the client. Preferences source used for finding assets source that you can use. The exemplary data shown in the figure, consider the same specification of content to process names, which originally was 4×3 or 16×9. The name "Plane" was selected as the earlier name of the directory, which can only have a master video 4×3.

Preferences of production allow adaptation operators for connecting or disconnecting the possibilities highway distribution on the basis of customer preferences. Thus, in the example shown in figure 6, the preferred production indicates no replacement of 3:2 or decrease the frame rate of the film 23,98 on the frame rate of the video 29,97.

7 shows one example of inventory status 700 for the Name "Plane 702 and alpha "Theatrical" 704. Blocks 710, 712 are assets source that presents for the Name/alpha. Blocks 720, 722 are presented to illustrate the fact that all the assets of the light source is ka correspond to the master specifications. When the analysis is completed, you can find the asset source or specification of the component. Finding the specifications of the component will lead to a demand component that includes the Name, the alpha and the information about the specifications of the component. The demand component is a tool for managing the tasks required to control loading. Set 730 is a grouping of components (for example, an audio component and a video component), which corresponds to and is synchronized so that the components could work together. Components that are defined for collaboration will be organized with the possibility of specifying the type of kit for master data process. Running alpha kit will allow concrete proof of assets that will work together. Typically the kit will have one video component and one or more audio components, where any audio will work with the video in this set. Master data process supported by the client's specifications, will be processed, and their variability audio or auxiliary material used from the kit.

As shown in Fig.6 with regard to Fig.7, the analysis is carried out to obtain the desired output under the control of the technical specifications of the th. As noted above, the analysis is an iterative process, which passes through the preferences of the source and the technical specifications until such time as the assets will not detect, based on the capabilities of the system, the possibility of using produce the desired results. As shown in figure 6, the preferences of the source are sets of criteria that are non-technical preferences or the preferences of the content to the client.

Returning to Fig.6 and Fig.7, the analysis is performed in the case of the exemplary use. First preference source with rank 1 are used to query the inventory 700. In the example inventory 700 shown in figure 7, the system searches for the source video 16×9 and source audio stereo in English. The request also requires that these assets were presented in the form of a kit. However, this query fails because there is no asset video 16×9. Accordingly, the preferred source of rank 2 are then used to query the inventory 700. In this case, the system searches for the source video is 4×3 and source audio stereo in English. The request also requires that these assets were presented in the form of a kit. This time, the request was completed successfully.

You then display capabilities with IP is by the use of the analysis of materials as explained above. Display capabilities is a set of rules that allow you to display the criteria of an asset source criteria in technical specifications. Referring to Fig when assets source was found from these assets retrieve data. Data is also removed from the technical specifications. This payload is served in the mechanism 800 rules. The result is the confirmation that all the necessary transformations can be placed, and identification of necessary reforms. Preferences of production included in the analysis, which may disqualify the capabilities of the system based on customer preferences.

In the exemplary display capabilities, shown in Fig, data collection is produced from the assets identified in the request for analysis of materials in which the source video is 4×3 and the source stereo audio in English identified and presented in the form of a kit. Data is also collected from technical specifications 810 with rank 1 and are fed into the mechanism 800 of the rules of display possibilities. This iteration becomes unsuccessful due to the lack of conversion wizard image from 4×3 to 16×9. It should be noted that the rules that govern changes in the file format can be simplified by creating a dependent rules 840, which globally prohibit is definitely a combination. This eliminates the need to Express all possible combinations of display criteria.

As shown in Fig.9, the data collected from the assets identified in the request for analysis, along with data from the technical specification 820 with grade 2, and served in the mechanism 800 of the rules of display possibilities. This iteration is still unsuccessful for two reasons: (1) as before there is no possibility of conversion wizard image 4×3, 16×9, and (2) the client prefers to receive content that has not been processed through the destruction of 3:2 based on the software or separation 900, which otherwise represents the ability of the system mainline distribution.

As shown in figure 10, data is collected from the assets identified in the request for analysis, along with data from technical specifications 830 with grade 3 and served in the mechanism 800 of the rules of display possibilities. This iteration is successful only by converting 1000 requested from Koh deck master file codec specifications.

Figure 11 shows the relationship communication model requirements 1100 source, set 1110 and technical specifications 1120 to obtain a set of production functions using the system rules and/or logic. Each production function is is an example of the type of production, which then appears in the list of possible templates elements of the work. The production function can generate more than one possible item templates. In the example in figure 11 shows two pattern elements of the work, Service 1 and Service 2 to obtain the solution transcoding media. On the basis of rules defined by the system selects one suitable element, namely 1. Items of work include the information regarding the parameter "From" (for example, 16×9), the parameter "B" (4×3) and the system for use (for example, Service 1). Each template work item is associated with a set of respective stages within the template runtime. The example depicted in figure 11, includes the following steps:

Building a working area; locating materials for the Assembly; and Service 1 profile (MPEG-4). Therefore, based on the display of the item template for the template execution phase, we obtain the required stages of execution.

Immediately after identification of execution phases, the production plan can be optimized in various ways. For example, happened with complex multi-step transformations in the production plan can lead to the identification of numerous templates, work items (over optimization penalty (OOP). These templates can have excess is cnie milestones, such as locating materials for Assembly). These redundant steps can essentially reduce or avoid when optimizing redundancy. In addition, in complex cases, some stages can be performed in parallel or in a single operation, such as "format conversion" and "conversion 6×9 4×3". These stages can be combined into a single operation during the combinational optimization. After optimization is the production plan. After its implementation, the plan is used to generate the necessary orchestration process, which will convert the identified source materials into the desired product delivered to the client.

On figa depicts a computer system 1200 and the user 1202. The user 1202 uses the computer system 1200 to perform the functions of distribution of digital content. Computer system 1200 stores and executes digital processing 1290 distribution.

Figv depicts a functional block diagram illustrating a computer system 1200 that performs digital processing 1290 distribution. The controller 1210 is a programmable processor and controls the operation of the computer system 1200 and its components. The controller 1210 downloads commands (for example, in the form of a computer program) from the memory 1220, or a built-PA is ATI controller (not shown) and executes these commands to control the system. In their implementation, the controller 1210 performs digital processing 1290 distribution in the form of software processing, such as to provide analysis of the materials and production planning. Alternatively, this service can be implemented as separate hardware components in the controller 1210 or computer system 1200.

The memory 1220 temporarily stores data for use by other components of the computer system 1200. In one embodiment, the memory 1220 is implemented as RAM. In one embodiment, the memory 1220 also includes long-term or permanent memory such as flash memory and/or ROM.

The storage device 1230 temporarily or long-term stores data for use by other components of the computer system 1200, such as for storing data used by the system 1290 digital processing distribution. In one embodiment, the memory device 1230 is the hard drive.

Media device 1240 receives the removable storage medium and reads or writes data on the media inserted. In one embodiment, for example, a device 1240 storage is storage on optical disk.

The user interface 1250 includes components for accepting user input from which the user of the computer system 1200 and presenting information to the user. In one embodiment, the user interface 1250 includes a keyboard, mouse, audio speakers and a display device. The controller 1210 uses the input from the user to control the operation of the computer system 1200.

Interface 1260 I / o includes one or more ports I / o for connection to the respective device I / o, such as an external storage device or an additional device (e.g. a printer or a personal digital assistant (PDA)). In one embodiment, interface ports 1260 I / o include ports such as USB ports, PCMCIA ports, serial ports and/or parallel ports. In another embodiment, the interface 1260 I / o includes a wireless interface to support wireless communication with external devices.

Network interface 1270 includes a wired and/or wireless network connection, such as RJ-45 or interface "Wi-Fi", which includes, but unlimited 1202.11)that supports connection over an Ethernet network.

Computer system 1200 includes additional hardware and software typical of computer systems (e.g., power, cooling, operating system), although these components are not shown in figure 8 for simplicity. In the other implementation options you can use other configurations of the computer system (for example, various bus configuration or storage device or a multiprocessor configuration).

The above description of the disclosed variants of the accomplishments made to any expert in the art could make or use the present invention. Various modifications to these options for implementation will be obvious to experts in the art and the General principles outlined here can be applied to other implementations without deviating from the essence or scope of the present invention. Accordingly, additional implementation or changes are also within the scope of the present invention. In addition, it should be understood that the description and drawings presented herein represent the subject of the invention, which is widely considered by the present invention. In addition, it should be understood that the scope of the present invention fully encompasses other embodiments of which may become obvious to experts in the art, and the scope of the present invention, accordingly, is not limited by anything except the attached claims.

Appendix 1. Basics of chain digital delivery

For the company Sony (Sony) highway allocation (DBB) is a mechanism to expand its presence in the chain of digital to tawki services entertainment. The importance of this mechanism acquires the foreknowledge of how the chain of digital delivery will evolve over time and to use knowledge and experience. The desire to improve the performance of supply chains is manifested in flexibility and Service 2 through the use of key performance indicators (KPIs) (continually improving) chain delivery, guidelines, chain delivery, focus on advanced technology, the lifetime management and effective division of planning and analysis of the results of the execution. The experience of the delivery chain, accumulated in the company Sony and many partners, provides a perspective of how the DBB should move forward after its initial release and apply best practices in addition to the enhanced features of automatic processing of the content.

Managing the lifetime of the product

In addition to internal characteristics, the product will also have a typical service Life, which it will adhere. This Life can be traced from the very beginning of a product all the way to the end of life with the additional possibility of extension. Lessons learned from the physical production of entertainment content on optical media, teach that usually there is a sharp increase in the demand for the product is, followed by a decay with different rates fall. Such knowledge allows you to extend the capabilities of planning.

As a provider of digital services in the delivery chain company Sony will have a strong interest in the life of the products their customers as a point of data entry for input in the planning of activities, which refers to the DBB. This type of awareness is what will allow DBB to operate at very high levels of performance for delivery to the levels of advanced services with reasonable price. B2B and digital aspects DBB modify the dynamics of life management of the product, but similar principles can be applied at different levels. For example, a managed tiered storage environment can benefit from the knowledge version of the Windows product and to prevent the movement of files between tiers in order to minimize delays, and the cost of storage at the storage level in the direct access mode. In addition. Family of products, as described below, may affect the characteristics of the service life of the product. For more information on the service Life can be obtained from attributes, such as whether the name of the extension or background and General context of events such as the file format change at the industrial level.

Product family

analysis of the types of products, processing stages, types, formats, bit rate and requirements specifications shipping can often lead to the identification of the samples. Further study samples will often lead to grouping on the basis of intrinsic characteristics of the product that is currently produced, in both physical and virtual values of this term. These groupings provide a natural segmentation, which can be used for grouping products according to the house for which you can apply different processes and rules execution.

DBB should be flexible and to support customer requirements for orchestrated process in accordance with this family of products. As with most of the segmentation results, the alignment of technological processes for a family of products reduces the total number of unique cases and exceptions. The aim is to modernize the Executive conveyors, creating a flexible. This, in turn, allows you to focus on the underlying processes that increase the value within the chain of delivery.

Presents as an example the analysis of operational data should likely to identify commonality between the two main groups of products: characteristic unlike episodic. Each type about the ukta can have the ideal technological processes, which improves their Processability (as defined below). Similarly, the purchased content allows you to benefit from alternative processes or orchestrated technological processes in comparison with the produced content.

Manufacturability and manage checkpoints

Building digital supply chains involves the coordination of numerous processing steps similar to traditional supply chains. Activity plan before implementation, with an emphasis on laying the Foundation for securing the modernized run immediately after the implementation of the plan. The definition of control points within these plans take into account the discrete modules, which can be much easier to manage and track. Potential delays can be analyzed and monitored for reasons. Therefore, the management of control points increases the adaptability that allows you to avoid recession and exceptional situations during execution.

The availability of technology and support management checkpoints performed using DBB, will be the main Foundation that enables the company to Sony to become a centre of excellence, truly becoming a partner for its customers chain digital delivery. DBB can use Templates that perform the processing steps default is Y. planned schedule, which is adjusted using the input parameters. Set schedule can be compared to actual and to provide an opportunity for collaboration to solve common problems in understanding the results of the adjustment.

DBB will depend on external points of contact, which can have an impact on manufacturability, such as obtaining a Masters from the group Mastering. Checkpoint reception of the Wizard to register the Template with parameters that belong to the product Family, such as changing the terms of mastering between episodic theatrical names. The total cessation of work at the test points can help you to identify the root cause of the applications that were not completed in time. The analysis of these applications can show samples of linking delay with a specific Family of products (for example, the Masters for purchased content can often encounter delays due to uncontrollable or unknown quality of the source materials found in the process of acquisition) and to help to draw attention to Manufacturability, focusing on improving processes or systems for this particular segment, which can be tracked down to a specific Family of products.

P is Tegea and optimization management

Using these important basics together, you can perform additional optimizations. The fundamental elements include the basic points that can then be processed using modern methods of analysis, which lead to additional regularity, as well as people, driven by continuous improvement. These model improvements can be used to define sets of rules at different levels, which served as control Strategies.

Flexibility is a key principle of the DBB, which you must adhere, and it ultimately will enable the efficient use of management Strategies defined above. At the system level, the application of sets of rules that optimize the supply chain, should be the main function of the system and what can ideally be used for all chain systems delivery, even outside of DBB. This ability to increase, which is based on an improved practice of chain delivery, should not be limited to DBB, but must be available for integration in the entertainment Center of the chain delivery of a High quality.

The company Sony plans to combine existing knowledge to enable Strategies and optimizations control possible under any circumstances for the initial deployment DBB. This knowledge will come from the basic points of existing systems and processes and will be combined for future decisions. The immediate impact will be seen from the fact, as will be defined Strategy of migration management, to ensure that the names and clients that provide the highest return will be imported and adapted in DBB. Initially, the resulting rules can be applied semiautomatic in a procedural way, but the long-term goal of the company Sony is valid strategies and optimizations management in a more systematic way using automation included wherever it is profitable.

Annex 2. The relationship between partners and clients

1. Review

Highway distribution DBB requires support certain data types in order to realize his concept provide Partners with the ability to service the needs of the distribution of content. Partners, Customers, customer Profiles, Specifications and Configurations are several key objects for which the data should be stored, and the data must be managed within the DBB.

2. Description

On Fig depicts an exemplary diagram of object relationships, showing how Partners and Customers should refer to client Profiles. is pecification and Configurations. The aim of this scheme is not intended to determine the final design, but will help to describe the types of relationships that are assumed to satisfy the process map of the state.

Partners are content owners and customers DBB. Partners will sponsor users and grant them access to the DBB to develop queries and visibility of the status of the process. Each partner will be able to distribute content to one or many clients.

Clients are companies working under contract with partners for the reception of the content. The customer record defines the information necessary to determine the legal form of management. Although the contact information may exist at this level, the Contacts may also be associated with client profiles, as will be described below.

One client may not work with many partners, such as Amazon with Sony and Paramount. A separate customer record will be maintained for each partner, however, all records of the client, representing the same company under multiple partners should be linked to ensure the idea that the Customer across all Partners. Exemplary Clients include Apple and Amazon (DDI), Comcact and AXN (broadcast). Kli what options will be added in DBB, if necessary, on the basis, in order to fulfill requests of Partner for distribution of the content.

Client profiles are used to define the requirements of each client for content delivery. One or more client profiles can be set based on one client to represent numerous business models for this client, for example, DST, DDI, VOD or, if necessary, to change on the basis of territory or other business/technical reasons. As stated above, the contact information may be associated with the customer Profile, if multiple contacts exist for the client. Client profiles will be created with the help of Administrators DBB.

The specifications define key variables and requirements needed to support automated manual processes. Information about specifications may be common to all of its clients. Master specifications will be supported with the ability to link a single specification with multiple clients. Modification of the Specifications must be resolved at the Client level or at the level of the wizard. Modification at the Client level can result in a new record within the specification wizard. Modification at the level of the wizard will allow you to propagate the changes to all clients associated with this specificity of the Oia. Validation must be performed together to ensure that duplicate specifications are not created.

Although the functional requirement specification is to support the processing and distribution of content, human readable abstraction data specifications will be available for Partner for viewing and communication.

Variables In connection with the Specification, some information can be defined as unique to each profile. This information within the specification can be defined as input variables when communicating with the client Profile. For example, the specification of delivery allows you to define a delivery vehicle, but variables that are specific to the Client may include preferences image format.

Configuration - configuration, which are sets of information that are created individually for each client Profile. Although specifications are reusable sets of information, which may be associated with client Profiles, the Configuration may be specific and unique to the client Profile. In these cases, the "standard configuration" can be reused for all the numerous customer profiles.

Specifications - DBB stores and manages numerous types of specifications with the support of the conversion of the content delivery. Specifications include, but are not limited to the following:

A. Product specification - defines the technical metadata that are required to create a completely distributed product, which may include Video, Audio, Images, Titles, Subtitles, etc. Specification is used with benefit and shared services DBB, such as transcoding, in order to produce the end product in accordance with the technical specifications. Specifications include bit rate, frame rate, file format, etc.

b. Metadata specification defines the information required to generate the delivered metadata/file. When used to achieve the goal of information available within the metadata specification, the system determines the file format metadata in the final state (for example, XML, XL Excel, CSV, etc), as well as specific metadata and values that will be included for a specific Title/alpha. It is important to note that metadata specification acts as the validation data, ensuring compliance with the relevant final structure metadata. May require some areas in which you must enter data presented in a particular format (YYYYMM-DD). You can define other is their area to receive duplicate values and normative vocabulary. Metadata specification ensures compliance with rules and transformations that are necessary to interpret corporate canonical metadata repository DBB. The area limited by the framework of the specification, will be referred to using the corporate ID of the canonical metadata DBB.

C. Other specifications - additional required Specifications can be identified during the design/implementation.

Configuration types - DBB stores and manages numerous types of configurations, with the support of the processing and delivery of content. Specifications include, but are not limited to the following:

A. The build configuration is specifically for processing content, there is a separation between the specification for the Product entity and Configuration for the Assembly. Configuration for the Assembly determines the Assembly and order of appearance and content additions, such as logos, passport details, safety signs with signal black, etc. This information is separated from the Specifications for the Product because of the great diversity of these configurations based on customer needs. Multiple clients can use the same file specification and data transfer rate, but require different build configurations. Examples of configuration items of the collection are the Logos, paspa the local data failures and overlays, insert cards, warning, shadings barcode and safety signs with signal black.

b. The package configuration - defines the information required for generating a package. Information relating to the package may include the location/format packing specifications, the agreement on the name of the content package, the directory path to the content directory path of the output packet and determining the type of the wrapper of the package (for example, MXF, ZIP, directory structure or loose files).

configuratie delivery - defines the information required for package delivery. While the goal is to deliver in a digital format (e.g., Aspera, SmartJog, FTP), the shipping configuration allows you to handle the physical output. An example is the conclusion of the package in the hard drive and send it by physical address. In this example, the Configuration method of delivery is the "hard drive".

It is assumed that the produced shipping Configuration FTP, Selection method, such as FTP, is part of the Configuration. Additional inputs, such as IP address, user Name. Password and Port are entered for the full certainty of delivery method. This information is stored in the form of a set of data associated with the customer Profile.

The second configuration for the media to jesd the x disks or Aspera can be added to the client Profile. The data that is required for each configuration are specific to the selected delivery method.

The status of the Client/Profile - to control the ability DBB to serve the Customer or the customer Profile statuses and associated rules should be configurable.

Communication Profile/Specifications within the Profile of the client, many specifications can be assigned within each category mentioned above. One specification of each type installed by default, but the user can override the default and select another valid specification, which was associated with the customer Profile.

In one example, the specification of the default delivery to the customer Profile is a specification of the FTP, but due to the large size of the particular Request, the requesting party may choose the hard Drive as an alternative specification of delivery.

Type the names of the numerous specifications of products may exist, as described above. During the communication specifications of the product to the customer Profile there is a variable that allows to determine the Type names. This allows you to assign a specification for a particular type of Product, for example, the Feature Episode or Announcement. Each Title selected for processing is of Type default Name in the case of PH and or Episode, or lets you select the Type of Name in case of Announcement by request only. This variable supports the need for processing different types of names with different product Specifications.

User interface

From the point of view of the user interface, management, Partners, Customers and customer Profiles will presumably be handled through the user interface. These features will in most cases be managed with internal business analysts DBB. However, specifications are essentially technical, and they will probably be managed by means of technical resource DBB and, if required, will be managed within the XML.

4. Services

Services are not exposed to DBB, except through PI for managing Partners, Customers, customer Profiles. Specifications and Configurations. The management of these data will be of DBB.

5. The interface system

External systems will not be used for Interfaces partners. Customers, customer Profiles, Specifications, and Configurations.

6. Multipolynomial

The concepts discussed above regarding the relationship Partner/Client, essentially define the requirements for multipolarism for DBB. Administrative program should provide the ability to create hierarchical relationships described above.

Annex 3. Managing queries

1. Overview

For DBB requires a user interface with possibility to enter requests for various forms of processing content. Demand management provides the functionality required to identify customers and their necessary products in their final form. This user interface is the primary interface between the business users responsible for the implementation of DBB. Through this interface manages all the necessary DBB clarifying information, technical or business related. All requirements for the status of the business module are routed through this interface. If possible, the program assumes that the interface uses a data structure, described below, to create advanced logic, which allows the user to enter more General information and allows the system to guide and support the user on the level of specificity required DBB to meet the requirements.

Demand management is a set of user interfaces (UIS), which allow for authorized users access to the PI, as described here, and to more granular levels of detail process DBB, as described below.

2. Description

Fig depicts the primary inputs to the module support queries.

Inputs LOB entries LOB or "SFU is s activities represent Organizer, for example, the sales Department of the company Sony. These branches give the right to use content to different customers and requires the Requesting party, such as the world performing products (WPF). The requesting party will use DBB for the creation and delivery of content. At a high level LOB terms of the transaction, such as the license window, airdate, license type and other relevant information. This information will be included in the request submitted by the Requesting parties. In addition, LOB provides primary inputs for queries. Names and Customers. In General and as it applies to the Partners, this is a business that relates to information that may be required in order to include it in the Batch metadata or to support operations on the statement of accounts.

Clients - the Organizer will specify one or more clients, which will be processed for this request. The requesting party DBB will determine the appropriate customer profiles within the query in cases where one client has multiple profiles. Profiles Customer/Client are the licensors of the content, which has contracted with a LOB for specific Names. Before you create a query assumes that clients were adapted and were all soo the relevant Profiles and Specifications. Information about Specifications should be available only from the point of view of the format of the Requesting party in order to facilitate the choice of the Profile.

Name/alpha - significant Directive as part of the Request consists of the delivery of one or more precisely defined names to one or more Customers. As described in Appendix 4 "Organization inventory", alpha represents a change in the level of the content within the title, which may be specific to a given territory or market. For example, for the name "Over the barriers", the scene where one character hits another character with a brassy, changes for theatrical distribution in Japan. Based on this requirement, all postal theatrical distribution of any Japanese customer uses the same edited version or alpha.

The choice of the Name/alpha is assumed that the choice of a specific alpha in cases where the Name has more than one, will be performed by the Requesting party. However, this choice can assist and/or it can be automated based on business rules, which rely on the availability of metadata on the level of customer profile and level alpha.

The selection specification/configuration specifications and configuration of the Content will be defined and associated with the Profiles. Possible megachi the certain specifications and configurations associated with the customer profile based on the Type name, which will be further delivered. As set out in Appendix 2 "the Relationship between the partner and the client, you can provide numerous specifications and configuration, including the default function. The requesting party may choose an alternative approved specifications as part of the Request. Information is available to provide assistance/automation selection specifications. For example, Numerous product specifications defined for the client, one for Episodic content and other Characteristic of the content. In support of customer Profile defined business rules to select the appropriate specifications. This can be done by using the value "Type names" for the purposes of this example. These same metadata will be associated with the Name selected on request, facilitating the identification of entity description, as this requires a combination of Name/Client.

Request Numerous names/Numerous customer Requests, you can develop in several different ways. Some examples are: One name and One client, One name and Multiple clients; One client and Multiple names and Multiple names and Multiple clients.

The most difficult scenario is Numerous the names of/Numerous clients. To minimize the complexity of the scenario, it is desirable to ensure that when you select Multiple names, all selected titles will be performed for each selected Client. The requesting party will not be able to configure what the names will be associated with which client. In cases where not all the Names for all Customers, will be made numerous Requests.

3. User interface

The application user interface allows users to create, update, cancel, and get the status for different queries. In addition, it is assumed the finding and a brief display. In cases where the definition of the Client Profile and the choice of Names require additional assistance/automation elections, they are processed in the format wizard prompts that guides the user in the decision-making process to the depth necessary to complete the order. This depth should reach the level of a specific Component search and selection and manual selection of the specifications. Depth definition, valid for the user should be configurable. Certain levels of selection, such as for specific Components of the source can be defined as the duties of the operating personnel.

4. Services

It is assumed that the services module the Query will be opened only within the DBB and do not require formal API to permit communication with other systems. However, the architecture should exclude the data flow requests directly from any Partner.

5. The interface system

Query engine will have a functional connection with the Master customer Master title. Master of technological processes and task Management. These datasets will be within the line or can be connected in order to the application architecture. Only exception will be the interface Name GPMS. Information Name/alpha will be interfaced to, and stored within the highway to the extent necessary to support distribution. The Query module may require a direct request in GPMS to view additional information about the name, which is not stored in DBB.

6. Multipolynomial

DBB has a multidomain capabilities, as described in Appendix 2 "the Relationship between partners and customers". Numerous "Partners" will require access to PI request. The user name and security privileges must be supported independently for each user group Partner. Data must be completely separated for all levels of information are described here.

Appendix 4. Inventory control

1. Review

In addition to using technology for the automated processing of content main objectives DBB the extension-based automation rules for all aspects of the running of the process. Modern model metadata inventory of the film industry does not have a strict organization required to support automation in the areas of identification of assets source. The processes of acquiring and holding assets and metadata that are written in the usual way, subject to significant frequency of occurrence of errors. As a result, the manual labor that is required to identify the correct asset source during the production period, was largely a bottleneck in modern digital design. The introduction of more stringent and strict control metadata allows you to automate the selection of assets and significantly reduce manual intervention and increase overall performance.

In order to support unambiguous inventory, identified two basic concepts that require large structures. The concept of "Version" was renamed in the nomenclature of the company Sony in "alpha". This concept represents a change of content that can exist in the inventory for a given title. Adding structure to this concept will allow more precise survey inventory, creating compatible "Kits" inventory under this title. Within the organization alpha, inventory based on the component used is not traditional production discipline by facilitating communication assets source with manufacturing processes, they podderjivaet concept support automated processing of media content in the same way as bill of materials supports the automation of traditional industries.

The amount of visibility of the inventory will cover digital assets within solutions DBB DAM and will also be extended to external physical and digital components in addressing the management of physical assets of a partner. The extent to which organizational principles described here are implemented in physical assets must be flexible in order to meet the needs of business to analyze the cost and time of the production cycle.

2. Description

Fig shows an exemplary hierarchy that exists between the title, which has two alpha (Director's cut and theatrical version), and a family of components that are identified for maintenance Directing the alpha version.

Alpha - the alpha Concept facilitates two main requirements within DBB, identification of customer needs for the name with the version based on the video or edit video or audio content and organizational principles of inventory assets that are required to maintain these changes.

Usually alpha describes the various versions of the name. These R the differences are usually associated with the where and how you can distribute your Name/alpha. Alpha can be created on the basis of the revision of the Standards and Rules of operation, which is required to display the name in a specific territory, market or media. Because each customer will have the market, media and territorial definition within your profile, link the same data with alpha may assist in the automated identification of the appropriate version for the selected customer. You want to link various concepts of allocation rules with each alpha. For example, the version of the film without age restrictions may be permitted for the world show, but only for digital sales. Editing one and the same film, the removal of specific scenes of violence or profanity may be the only version allowed for television distribution in one or more foreign territories. As a result, DBB can choose Unrated version for the client DST and the edited version for the broadcast of the customer from the United Kingdom.

Alpha will also be used as an organizational tool for inventory assets, both digital and physical. Modern business processes lead to the creation of collections of assets required to service each alpha. The elements depicted the I with the various image formats and standards established for each alpha under the specified name. Audio and text assets then create this image assets. There is a need for processes that support the creation, communication and retention of all assets created to serve a particular alpha. At least, you will need to download the identification of specific alpha-specific assets that are added to DBB.

The concept of alpha is also applicable to the identification Announcements. Identification of the Announcement, which will be used for a specific client should be the same rules that will be applied to the AC full content of the program.

Kits - components defined for collaboration (which correspond to and synchronized) should be organized. This will allow the master data process to specify the Type of kit. Under alpha, the kit will allow specific confirmation of assets that will work together. The kit has one video component or one or many audio components, where any audio will work with video as part of this kit. Will be processed master data process (which is supported by the client's specifications), the variability of which the audio material or support the use of this kit. Modern assets DIAMONDS (mixed audio and video) are the Dean set.

The type of a set must be known to the master data process and must have the attributes that will provide the ability to select the correct set based on key values such as the image format and standard.

Components are separate audio, video, text and/or consolidated assets stored in the asset quality source for content processing. Although the notion of a Component can be extended to archive or protected assets, their main role is to clearly identify those assets that are required for specific production processes. Components can be considered in many respects, like serial number of the product" in the traditional production. Component organization can come from DBB to provide visibility into key physical assets.

Enter the asset in the DBB has three separate parts.

A. The component type component Type is a specification that describes the asset as much detail as possible. The specification will define the acceptable range of values for metadata fields that are key to content processing. It is assumed that all components are loaded into the DBB should be taken with the Types of components in a similar fashion in the reception of the material in Armineh production. For example, the Type of component that represents the asset SD video technology with mailbox 16×9, has a flexible specification that will allow you to restrict each major region to a value that corresponds to what is acceptable for the component. On Fig shows the list of values of image Format, which will be limited to the asset if it will be considered for this type of components. Such definitions technical data will be distributed to all metadata values inventory, which are essential for the processing of the content.

b. Requirement components - Requirement components (TC) is a request for a specific component Type within the specific Name/alpha. It is assumed that TC will be to stimulate the creation and loading of assets in DBB. TC can be created in the result of the Query (see Appendix 2 "the Relationship between partners and clients") or can be created in the planning of production, where the group mastering will perform TC required for the preparation of Title/alpha for distribution. For example, Theatrical alpha for spider-Man 4 is in production in the period after the distribution. The planning team determines the requirement for video assets for the highway to eight video Components. They represent a video asset is s master specification DBB, changing the image format and standard, each of which is necessary to support the production of DBB in the main direction. This leads, eventually, to the creation of the eight TC, which performs group mastering. When assets are created for the specification of components and delivered to load, they will be accepted or rejected before loading on the basis of the validation requirements of the specifications. Immediately after the adoption of the asset will perform TC.

component (done) - after TC will perform acceptance and the paging Component will have access to the DBB for processing. As described in Appendix 5 Master data process", each specification processing of the content allows the identification of one or more components that are required to create the final product. Only when there are Components made for a specific Title/alpha, you can perform the specification processing of the content.

Assets As described above, the Assets of media rich under the line represent the entity(and) Components. Assets are supported by the independent metadata that are common in most systems MAM/FRAMES. In DBB assets are also associated with a specific component, and the swap was executed opposite. The metadata of the Asset will DBB of interpretion the th variables for processing content, which may exist between the names.

The origin is necessary to ensure that the original assets were recorded during encoding and uploading. In addition, you must record this information in order to create new wizard Components within the DBB. This link with information should allow users to track the actual assets used to create any asset DBB back in the coded physical master or downloaded file.

Continuity components, in order to maintain a clear inventory is important to manage the replacement of Components and to prevent the penetration of copies in DBB. When established Requirements for components and there is an asset that is present in DBB under the same Component Name/alpha, the system will manage the continuity by identifying the copies and indicate that the process requires permission.

3. User interface

While DBB is associated with the master Title partner for the creation of the Name/alpha, PI DBB will support the direct creation of names and associated alpha. It should be noted that the parameters associated with Names (for example, the Type name) and alpha (for example. Image format) is required to enter through PI DBB.

User interfaces that support alpha, and require the administrative software configuration needed to create types of alpha. These types allow common types of alpha, such as a theater or registersa version that will be standardized and used for all relevant names. These administrative programs allow the definition of the business rules related to the concept of applicability to the Public and the Market described above. An additional level of administrative programs may be necessary to create alpha templates for common business rules.

Creating specifications Type components closely related to Annex 5 Master data process and can be included in the integrated package PI. For this PI requires the ability to create a record that includes technical requirements, and the media source must meet in order to maintain assigned processes. These records are associated with processes that create integrated inventory and information on the processing of content.

4. Services

DBB must have public services that allow interfacing with the master Name partner. More specifically, these services for the company Sony support Name, the alpha and the associated rules that are described above.

5. The interface system

For the implementation of the plans of the company Sony pictures Intertape is d (Sony Pictures Entertainment) desirable interface for GPMS (global system for master products). DBB will save the data Names/alpha, which is necessary for operation. DBB will support the interface of the GPMS for R1, but can be extended to an API that will allow partners to match these names in DBB. Interface to system GOLD (global order and library database) will be necessary in order to ensure DBB visibility of Components for the basic physical assets. In order to provide visibility for expensive production scenarios, it may be necessary to extend the visibility of the components DBB for major assets such as a master of high-definition video or duplicated audio languages.

6. Multipolynomial

Each partner owns any number of names within the DBB. The inventory is separated on the basis of organization Names under each partner. Users must be sponsored by a Partner and secure the rights to names and related assets on the basis of this Partner.

Annex 5. Master data process

1. Review

DBB supports the possibility of an automated process. A review of the current processes shows that some of the processes, decisions related to the choice of assets source processing requirements of the content and even the packaging may be subject to certain government the AMI. Other processes may require human intervention to clarify ambiguities. In the context of the ongoing consolidation of specifications, delivered to the Client, and simplify inventory source permitted by technology content processing, internationalization policies related to technological processes, it becomes possible and more desirable.

In addition, providing precise details of the specifications for automated content processing is a necessity. Errors made by the model "execution order", do not support greater efficiency provided for in DBB. Creating, testing, and implementation of technological processes of processing content with engineering staff provides an excellent platform for consistent performance. Call these technological processes through the use of simplified rules will provide an efficient division of labor, which will increase as the level of customer service, and processing of content.

Master data process provides metadata about the technological processes that support production planning. This metadata identify the process required to support the client's Specifications. In addition, there is a need for the may information on Recruitment and Components supported outside of the data process, to ensure an effective survey inventory. Using this information, the support, the definition of the Specifications of the client, and the desired Name/alpha will allow the mechanism of production analysis to identify the relevant requirements inventory source and processes needed to create Products. Master data process operates in cooperation with the organization of the metadata inventory (see Annex 4 "Organization inventory") in order to support the requirements of production planning (see Annex 6 "production Planning").

Although it is desirable to have full information, flexibility in the work environment is also a key requirement. Services DBB and technological processes that coordinate them, will be designed according to the modular principle. Although processes can coordinate input parameters, actions, and outputs of multiple services into end-to-end process, they can also provide access to basic services DBB. The main tasks are operations that may have requirements for PI, which does not include the production plan. These tasks, such as searching and retrieving files, transcoding, packaging and other should be based on the parameters defined by the user. This gives the work the staff to make full use of the services DBB, in order to deal with temporary or special technological processes that cannot be fully automated.

2. Description

Fig depicts the role of master data process using DBB. The shaded blocks represent the election specified by the requesting party. Information in the unshaded blocks is retrieved from the inventory stocks DBB and master data process.

Processes - object relationships, shown in figure 17, shows the approach to the management of metadata, where the main requirement is to separate the Content ID and the Client from the definition of the production plan. As the Requestor identifies the customer Profile, DBB can identify the customer's Specification. Using this information DBB can determine the process that will be used for creating deliver the specified product. These processes will be created and managed using the administrative staff and will be checked through the adaptation process.

Technological processes based on customer specification - production planning is based on identification of customer specifications and Names and alpha. Master data technological processes determines the technological process is si, required to complete the customer's specification and defines the requirements for the inventory of each process. These data allow your scripts to run "what if" from the net without control the business rules themselves technological processes.

The technological process on the basis of the specifications of the client will actually be a number of technological processes, which will be marked for compliance with the state inventory for a given Title/alpha. For example, technological process designed to create an output of the MPEG2 8 MB will include the stages of coding and swap the master video file if this file is not present within the DBB. If the file is present in DBB, these steps will be skipped and the process will begin with stage of the search file.

Technological processes on the basis of the PI or Key objectives - tool orchestration process will be a key point of interaction with services DBB. Although it is desirable that the technological processes on the basis of customer specifications were the norm for the distribution scenario, all of the Key tasks within the DBB should be available to operational staff. For example, the production plan for MPEG2 8 MB for the client in German requires appropriate and synchronized the authorized audio track in German. The current set required to service this specification represents the missing track. Due to the rush order, corresponding and synchronized sound track is delivered directly to the working staff, which then performs the Key Task that is designed to give the opportunity to find specific files from DBB, to select and execute the appropriate specification transcoding, packaging and delivering it to the client.

Key Tasks will be specifically designed to support General operations and will support the requirements of production, which cannot be automated based on specific business needs.

Orchestration - it is Assumed that the tool orchestration process will be used for creating, managing, and orchestrating tasks that are required to perform processes. This tool should take into account the inclusion and the survey of business rules, which can be a content, customer, or other specifics and which will materially affect how the process will run and/or what tasks necessary part of the production process.

Auxiliary data - Technological processes will be managed orchestratie Tasks and their subordinates. These techno is logicheskie processes will interact with auxiliary data, which will facilitate selection and inventory requirements for billing and other inputs. These data will include, but not to limit the foregoing.

These processes will normally include the following information:

A. Tasks - a Task is defined as any step in the process that you want to promote from the elements of the master source to delivery of finished product to customer. These tasks will include Coding, Paging, QC, transcoding, Digital watermarks, etc. the Decision of the orchestration process will make it possible for the flexible creation/configuration tasks necessary to support new technologies, content processing, and advanced automation. Tasks represent the primary building blocks of the orchestration of content processing. Each task can be manual or automated and will have the status and the priority associated with it. See Appendix 7, "task Management" for complete descriptions.

b. Operations billing - progress work must be related to services to be billed under the DBB. Operations billing will contain information that you want to query information about the price list using the system for billing. When is ogenyi 13 Financial processes will be described as to control Operations to be billed using the highway. Processes are designed to meet the needs of the financial report in order to create and to receive the report (or "status") for transactions to be billed at the completion of the process.

C. Kits - Components defined for collaboration coordinated and synchronized), United together. This allows the master data process to specify the Type of kit. Under alpha kit allows you to provide specific proof of assets that will work together. The set can have one or more components and one or more audio components, where any audio will work with video as part of this kit. Master data process (supported by the client's specifications) will be processed with the variability with which the audio and auxiliary material is used from the kit. Current assets DIAMONDS (combined audio and video) are one set. The kit can also include closed captions, subtitles, or other types of content.

d. The types of components - If necessary, put the Types of components that are required for the Task must be identified. This information supports the analysis of the inventory of assets, when the Name/alpha precisely defined in the query. This is information is a key requirement for production planning and execution (see Annex 6 "production Planning", 7 "task Management" and Appendix 8 "Managed tiered storage environment").

Variables of the process - Technological processes help to ensure that the configuration variables for content processing. For example, two video asset for different names may be used in conjunction with the General Type of components. However, the metadata level assets may indicate differences that will affect the processing of the content. Variables in the Master data process will make possible the selection of a Task handle different content or set or Task, based on differences in two source files.

Schematic of the process flow, which cover the scope of work managed by Metadata of the process. General categories of technological process, is presented below:

A. Encoding/Download - enter the asset source in DBB.

b. The transformation of a product - automated and manual processing of the content.

sasdania metadata - creation of a specific Client metadata.

d. Search for supporting media - manual or automatic search of the auxiliary images, the advertising staff of the plot, etc.

E. Packaging - use of specifications packeteer the provision for Product metadata and auxiliary media.

f. Shipping - shipping packages to customers.

3. User interface

Creating and maintaining Master data process has a flexible user interface that allows you to identify, enable and bind to specific process specifications content processing. PI makes it possible to create records that represent processes, and must associate each process with the relevant client's Specifications and Types of components (see Annex 2 "the Relationship between partners and customers"). Technological processes and associated master data must be easily copied and reconfigure themselves. It should be noted that R1 does not assume that the information about the organization's inventory was fully integrated with a set of tools/services that support and perform master data process.

User interfaces the Key tasks will require providing direct access to services within the DBB. These PI will be discussed in more detail in Annex 6 "production Planning", Annex 7 "task Management" and Appendix 8 Management tiered storage environment".

4. Services

The mechanism of Production planning is to implement the data access but can do this with a simple call to the database, depending on the final decisions regarding the architecture.

5. Multipolynomial

Sharing master data process can take place for all examples of a Partner, which allow you to use numerous partners technological process, which is used for General delivery. However, this function is inherently administrative. As PI, and the levels of data should be completely separated from the examples of the Partner. Information about the price list, as stated above, must support the change with the help of a partner, and possibly with the help of special norms transactions.

Annex 6. Production planning

1. Review

Automation of technological process must be supported with the help of master data, as described in Annex 4 "the Organization of inventory and Appendix 5 Master data process". These sections and their requirements describe the master data that are supported throughout the inventory and processing content. DBB will use these master data to create specific production plans in response to requests from the module support queries. These operational plans are a set of basically the instructions for the orchestration of content processing, and will develop a point of information, needed to assess the cost and time of execution of the order.

Although it is desirable to create and execute production plans without user intervention, it is clear that surgical manipulation of these plans will be required in unusual cases. This level of information and computing capacity should remain flexible, in order to maintain a high rate of surgical intervention in early life DBB and because these rates are reduced, also to maintain a high rate of a fully automated planning.

2. Description

Figure 2 shows the objects and processes necessary to create a production plan in DBB. The mechanism of production analysis uses the Master data process and Data supporting the inventory described in Annex 4 "the Organization of inventory and Appendix 5 Master data process", along with input from the module requests, which are described in Appendix 2 "the Relationship between partners and customers". Using the specifications of the client, the mechanism may identify the appropriate required technological process a process that identifies all Tasks required to create the customer's specification. In addition, all the necessary types of components for each task, which are defined there, where it is possible. Using this information, the engine first performs an Analysis of the material. DBB queries the inventory DBB for necessary components for the specified Name/alpha and Specifications of the client. The results of this analysis determine the Tasks necessary to complete the required process.

As described in Appendix 5 Master data process", the Specification of the client, based on technological processes must account for all possible scenarios inventory. These processes should cover coding and swapping necessary component inventory through delivery. They can be inherently modular and provide the flexibility to handle scenarios where the inventory is at a higher stage of readiness. The mechanism of production planning is to analyze the material to determine the specific processes required to create the necessary Product.

Process DBB may include transcoding the file with a higher resolution in the file with a lower resolution, which is then packaged and delivered. Operations DBB can create a low-resolution file and store it in the system storage files DBB as the wizard alternative resolution with limited use. In this case, the process will require a request inventory, determining that the file with a lower resolution is present and likely closure alternative process for copying and file delivery with a lower resolution than transcoding from a file with a higher resolution. For example, for "spider-Man 3", the file format MPEG2 8 MB was created and saved in the system storage of files. Within the required process will be optional Tasks to encode download, search and transcoding wizard file video file 8 MB, as there are already a master of the alternative resolution with limited use of 8 MB. In this case, the process will be shortened. For "spider-Man 4" may require the entire process from Coding proactively, as the file for alternative use does not exist.

Depending on the detailed design, you may need to restart the production plan taking into account the cost and time of execution of the order before executing existing production processes. The reason for this is the dynamic nature of the inventory of assets. Production plans can result in costs of fixed assets for Partners, and, as a result, before performing who may require additional permission. Within the approval period may change the conditions within the DBB. May swap required the master file, or an existing master file can be placed in the QC HOLD. As a result, a preliminary analysis can only lead to the assessment of the cost and time of execution of the order, which will be used for the purposes of RUBBISH outside DBB (see Appendix 13 Financial processes"). After approval, the analysis engine production starts the second analysis, the test for significant changes and, if not, execution of the production plan.

Evaluation of the cost - As described in Appendix 5 Master data process and Appendix 13 Financial processes, DBB will be interfaced with the billing system, which will keep price lists. Operations billing will use data from price lists in order to facilitate the calculation of prices. When the Production plan is created, the collection of variables necessary to calculate the price based on the results of the analysis of materials, and pricing is determined as defined by the identified processes. This information will be registered for use in the approved process.

Estimate the time of order execution - the execution Time for each process must b is to be estimated, and should be developed, the total execution time for the process. The calculation method is not yet known. Planning the correct performance may be outside the original scope DBB. However, it is believed that the analysis of the recent historical data can be used to estimate the time of execution of the order.

Interaction module requests This information will be presented to the Requestor for approval. The execution time is compared with an execution period to signal any potential conflicts or the need to establish a higher priority. The cost will be reasonable and will allow the user to initiate the process of Approval.

The version and modification of the production plan and Production plan will consist of Requirements to the components of the source, operations, billing, estimates the execution time of the order and the required production process. It is necessary that the production plan was validated using the business rules, which can mark it for manual review and release by the working group DBB. This may be based on the existence of certain tasks, or may be marked on the query level, based on the specific circumstances. Rules for on-line viewing of production is dstvennogo plans should be flexible and configurable. This step is required so that the plan can be modified by the working group DBB to answer for unique or specific circumstances. For example, given the technological process allows to specify a particular source component. However, if approved by the client, you need to use another source file with lower quality. These alternative source files are present in the DBB. The query is marked for the current view, and during this process, the assets of the source within the plan modified. Immediately after the modification, the Plan is released for execution.

3. User interface

One or more of the PI is required to support viewing, modifying, and operating plans prior to approval of the COFA. The PI will also be required for modifications operations billing before and after approval of the COFA. Cm. Appendix 13 Financial processes" for a complete description of the requirements for operations billing.

4. Services

Data-level queries can be submitted through the web service. Then, the mechanism analysis of production can develop the necessary information and respond to the request. Cm. Appendix 13 Financial processes for possible services between DBB and the listed options System for high is Alenia accounts.

5. The interface system

The process of analysis of production may require requests in the support systems, such as GOLD Sony and/or application CineShare (Kinonovosti use) in order to determine the possibility of using inventory.

6. Multipolynomial

Load level and prioritization of Tasks between partners is desirable to maintain a constant performance.

Annex 7. Task management

1. Review

DBB requires orchestration of Technological processes, which are defined Master data process. Production plans are to build, operational modification/verification, approval and provision of technological processes for execution. Immediately after filing, the function of the task management interacts with the level of service DBB, presenting for the consideration of the Task, getting answers, updating, registering and, if necessary, notifying.

Technological processes and their corresponding Task control Components are Loaded sources in DBB. In addition, DBB has visibility into key Components of the physical inventory, and process Control extends the communication layer to manual mastering or research activities/search assets. Within this broad is on coverage, it is assumed that any task can be configured to provide instructions manual process technology provider DBB or seller.

Analysis of the costs and effectiveness of technologies determines the degree to which you can automate any process. The main requirement is that the status of the Tasks and their interdependencies for all technological processes from the creation of the basic physical assets to confirm delivery were visible within the DBB.

2. Description

The production plan is produced when the order is initiated in DBB (see Annex 6 "production Planning"). After approved the submission of documents, the production plan will be to transfer tasks to the function queue Management. The processing tasks of the process and their composition are described in the functional grouping, shown in Fig. The technical composition of these options may vary depending on detailed design and implementation issues.

Tasks of the process - As discussed in Annex 6 "production Planning", production plan includes the processes necessary to perform the Approved request any time numerous production processes can be in their implementation, many of which Tr is the call for such tasks, which will be completed using the same services DBB. In order to manage the queues, priority control and visibility of security status of the Tasks of the technological process should materialize within the DBB. Tasks of the process are added to the corresponding queue tool orchestration process. Data will be supported in the framework of these tasks related to the status, order processing, the start and end time and operational information necessary to determine the nature of the task and its original Technological process and Request.

Priority - the Priority level of the request can be assigned in the module requests based on configurable user permissions and/or configuration of the Partner. The priority level of the Request can change during modification of the production plan, described in Appendix 6 "production Planning". The priority can be modified at the level of Name/alpha that allows users to assign priority to one or more line items within the Query differently than others. The priority level of the task process can also be modified within the function queue management tasks described below. Interdependence of tasks are set based within upravlenijagromkostju process.

Configuration tasks of the process - Task process control execution of various services present in the frame DBB. Although you can assign priorities to the tasks of technological processes, the analysis of the Task order is executed at the level of services to all Tasks, which form a queue with the specified service was processed in priority order. Configuration Tasks supports monitoring of thresholds that allow the functions of task Management to analyze and report on recent tasks or tasks with their start time has exceeded the duration. Task category include, but are not limited to the following:

A. Manual tasks - PI tasks DBB allows you to communicate manual tasks with service providers Partner/Seller DBB. This PI connected to the world wide web, provides information about the queue works on goals that will be carried out with the support of the technological process DBB. For example, the portal provides the ability to move a file, facilitating the delivery of assets to enter in DBB. This type of task also facilitates non-financial review and approved the process. It is assumed that the notification e-mail will be configured to support the LCD of these processes.

b. Control of technological process of encoding/paging - Requires all Tasks required to put assets in the DBB, which includes the Creation of queries, Components, Coding, Registration and Paging, as described in Appendix 10, "Managing paging/encoding". Some of these tasks can orchestrate through the management of manual tasks described above.

C. delivery of the referenced file and search for the relevant components, in order to maintain the external creation of coordinated assets, files, links to audio or video can be delivered to the seller with an accompanying URL, which will be used for delivery. It is proposed process support, which will provide the framework for a coordinated/synchronized components.

d. Integration of external web services - DBB supports the integration of web services with external systems for numerous purposes. The main purpose prescribed for the initial release, is the image search, advertising frames of plot-level metadata Names and other requirements packages from CineShare (Kinonovosti use), GOLD GPMS for R1 and for other third-party systems the latest releases.

that is, the file Management Task control the search and move files to and from a storage system DBB and p is derivat deleting files from memory WIP based on the policies and requirements of the process.

f. Processing of content - interaction with all identified types of processing devices of the content.

g. Packaging - production batch metadata on the basis of customer specifications and create Packages for delivery.

h. Shipping - shipping packages to Customers using the identified methods.

Financial update - any process can be performed with the possibility of a status and/or other required data to facilitate financial processes (see Appendix 13 Financial processes").

Status query processes should ensure the promotion of the objectives in the Query, as prescribed in the business rules of the process.

The following functions can be embedded within the tool orchestration process, but require performance management tasks through the DBB.

Queue management - management Functions of all controls and maintains the performance of various queues within the DBB and determines the order of execution on the grounds of priority and dependencies. This function controls the speed/flow of tasks through interaction with the level of services DBB.

Update task - Level services DBB provides the status for each Task. After receiving the status, function Update task update task to fit the existing status and provides the functions of registration and notification.

Control objectives - This function controls all functions of Task management and queues, providing a count of errors, analysis of processing time and, in General, support the integrity of the processing queue.

PI current control tasks as administrator DBB requires control of technological processes and tasks that are both manual and automated. Management priorities and objectives represents one of the administrators of the core functionality for maintaining an efficient chain management content delivery.

Notification - the notification E-mail is configured on the Task level. These notifications are sent using rules based on operational needs or needs help Request (Notification Requester/Client).

Key tasks As described in Annex 4 Master data process", Key tasks are processes that can be executed directly by the operating personnel. These processes require the PI, which provides direct input parameters. PI requires direct identification inventory source for processing in the framework of the Key tasks. Some examples of Key for the Ah are searching for a file, content processing and delivery, and they may include any activity associated with the processing of the content.

3. User interface

PI, valid for task management, provides advanced ways of viewing and analysis personnel. Tasks you can perform with the tolerance levels, which when exceeded, trigger warnings, and then checked for operations. Select and view tasks by using various criteria, such as the type of task, process, conglomerate device processing content Client, Partner, or the Request will be necessary in order to quickly identify and solve problems.

The key goal of PI is based on the modularity of technological processes and provides direct access to the input parameters. These programs can use the same template as the inventory search, and identification and search are common to most of the Key tasks. PI of additional processes can be attached to this base PI.

4. Services

Tool orchestration process can be used to interact with the level of service DBB submitted tasks, special situations management, registration, notification, etc. This tool requires a variety of services to violetgreen above tasks.

5. The interface system

Reference architecture depicts all planned interfaces for R1, but the task management can also border on CineShare to search for images, advertising frames of the plot and other media with the absence of rich opportunities, as well as GPMS for level metadata Names. For processes that govern financial transactions, and to the visibility of the inventory DBB borders with the implementation XytechCoHH, GOLD.

6. Multipolynomial

Preferably, the PI control of technological processes and tasks and services are one example and version, at least the group and would have the ability distribution. This allows DBB to prioritize work for numerous Partners for separate sets of equipment for processing content in cases where the equipment allocated to one Partner or shared among many Partners. Rules process to account for the different behavior based on the behavior of the Partner that initiated the Request.

Annex 8. Managed tiered storage environment

1. Review

DBB requires the ability to manage and store large amounts of data in a digital memory. Digital files can be a video, audio, images, text or any other type of media that can is about to pakketservice for distribution to client DBB. Given the current cost of storage and the expected volume/size of files, it is assumed that the storage system, which includes managed tiered storage environment (MMSE) will be the norm. It should provide a Central point of storage, which is more economical than the full solution in the direct access mode, because the files can be stored on the changing levels/types of storage devices.

2. Description

Since DBB has a digital store files that require services that relate to the management of files. One such device is a service boot/swap (see Annex 10, "Managing paging/coding"). In order to fill DBB files, the paging process is required to move the file from an external source localized in the item storage device DBB. All files must be moved into the storage device Level 1 after the initial boot up until the approved request will not be generated to move the file in the storage device WIP, or politics will not move the file to other levels within the MMSE.

Another necessary service DBB is the search process In the production process (WIP). In order to maintain services, content processing, the files are permanently stored in MMSE will first be necessary on what I'm up in the area of the storage device WIP, where they will directly get access to the content processing (e.g., transcoding and packaging). Install this file in the storage device WIPDBB should be performed immediately after full approval of the operating Procedure and add the task of the production plan for serving content to a queue for processing.

DBB should be aware of each element of the file regardless of the level at which the storage device .DBB must be aware of what files are required in its production phase in order to reduce an optional tape activity (that is, if a particular source file is required by order No. 12, and the same file was required by order No. 215, removal policy should take into account the second order).

In order to maintain capacity within the storage device WIP, you must install policy save, and delete. These policies of removal will be unique to the storage device WIP and can be based on several key factors, including the following:

A. The end of the term After the file was served, and approved production tasks that are not in the standby mode, require the use of this file, you should enable the removal event, planned by BP is like. This is a timed event may, for example, to establish that after 30 days the file remained untouched, and the file should be deleted.

b. Types of order status work is the completion of the event service can be identified using a pair of different types of orders, and you can start the analysis of retention policies (that is, more than likely the start of expiration). The type of work order Cancel shows that work is no longer going to continue and, therefore, the file is no longer needed to complete the work. Secondly, the status of the work order Completion will show that all activities, including the delivery and receipt of digital content, has been completed. It should be noted that other types of orders can be identified to run on completion of the service, and they should be configurable within the application.

C. Pending approved maintenance task At any time approved by the challenge of production/service, requiring the use of an existing file permanently stored in the storage device WIP, can reset the timer expires. Then this file will remain in memory WIP, not caring about the destruction, until then, until it is assigned a priority for the task, and it will fail.

d. The metadata file is to Manage the floor, the ticks can save by using metadata associated with the file. In this example, announcements or other media may have a longer retention policy than long form video. The use of this can be numerous, but policy graduation/retention should be able to use a metadata file, as a criterion. It should be noted that only the components have the ability to use this feature, as they have the required metadata.

DBB uses the MMSE solution for providing cost-effective scaled solutions to store your digital content. Entertainment and media work with large files, potentially in excess of 500 gigabytes per file depending on the encoding/bit rate/time. For this reason, the cost and scalability are the most important. DBB requires the use of standard functionality MMSE, which includes the ability to move files between storage tiers (for example, the access mode on request → direct access mode, the mode is the lack of access → direct access mode), and set a scheduled maintenance policy file within the MMSE solution to assist with planning. The retention levels for DBB are: Level 1a - direct access mode - rapidly rotating di is to; Level 1b - direct access Mode - slowly rotating disk; Level 2 - Mode of access on request - tape Library with automatic search; Level 3 - Mode not available - Out of the tape library with a manual search. Cm. Fig for more information.

Rules control the content on a global level in DBB. Set the rules for planning the movement of files between tiers of storage based on file type/component. Each file type/component set with a duration of completion for each level of storage, as well as digital watermark high quality disk usage. It is expected that this functionality will be expanded through the user interface for modification by the preferences of the Partner.

One area within the Level 1 storage System must be selected storage device "production Process" (WIP) and managed using DBB. Storage device WIP used by various services, content processing, such as transcoding. Although the equipment used for these services periodically first moves the content to the local storage device before processing the data, the hope is to clarify the processing time by eliminating the need of moving these large multigigabyte files IU the control data warehouses. For successful implementation requires a very high speed connection between the storage device 1 and the server for processing content.

MMSE integrated services management infrastructure to ensure more active feedback regarding the performance MMSE. These services are also integrated with other hardware DBB (for example servers for processing content) to assist in the evaluation of the CPU, bandwidth and other criteria to help DBB better orchestrate their services and administrators warnings about possible problems.

The MMSE solution takes into account a number of rules regarding the content that is stored on the tape: the Ability to prevent the spread of assets across multiple tapes unless absolutely necessary for storage of the asset (i.e. an asset exceeds the size of a blank tape in the pool); separation of content types on the tape (i.e., selection in order to have only certain types of items grouped on the tapes), thereby preventing the need to be compliant tape, filling the space for tapes for easy access to one small item. The ability to have multiple copies of the tapes to the DR to take place during idle time and in specific boxes technical service is.

3. User interface

Depending on the design may be little need for the end-user interface. There is the expectation that system administrators will have the ability to set the default rule to control the media through the environment DBB. Because these controls are available only for the administrator, this feature does not have strict standards for the user interface and, mainly, the usage of the functionality of the complete solution. However, there are some features that show through the interface for partners DBB. For example, depending on the preferences of the Partner, some content owners may require that the entire content remained in the storage device in the direct access mode, and move the memory device into a mode of lack of access or lack of access. Accordingly, may require some "hot names" in order to remain in direct access mode for longer periods of time than standard names. By setting these preferences, DBB will have the opportunity to interact with MMSE to pass values/parameters that make solutions possible.

A large part of the activities is eljnosti management files should be seamless to the end user DBB and requires no user interface. Move the file between the level in the framework of the MMSE and moving in a storage device WIP should be an automatic way. Only information that the user should be aware of, is the expected processing time required for training (for example, move in the environment preproduction), and file maintenance (e.g., transformation). One scenario where it is assumed the user interface is used to load/swap auxiliary media. It should also be noted that there are several mechanisms for zagruzki/podaci, FTP, download, web-based and other delivery tools (e.g., Aspera, Signiant).

4. Services

There are some features MMSE, which should manifest itself in DBB in the form of services. Features that are expected to occur in the form of facilities, are:

A. Moving files between storage tiers

b. Setting policies expiration based on metadata (rewrite rules by default).

All activities control files should be managed through services provided in DBB. To handle the requirements of the control file, discussed earlier in this section, you must provide the following services:

A. Service file download - This service should move the file from the place which the provisions, precisely defined by the partner, in the storage device level 1 for the specific separation of domain Partner. The entrance to this service must accurately determine if the file name must remain the same or follow the terms of the conversion of the file name.

b. File search service WIP - This service should take as input file pointer, precisely defines the file that will move, and the resulting backup file. The destination will be a section of the client storage device WIP.

C. Service manual removal - This service should take as input file pointer. In the case of the partner initiating manually request the removal of your content, this service must delete all the corresponding content is permanently stored in MMSE after confirmation of operations.

d. The service of self-preservation - MMSE need to manage your storage device using retention policies. Is this functionality MMSE or provided by the service, both the storage environment must evaluate numerous criteria before you start moving/deleting content. These criteria, described earlier in this document, shall constitute the inputs to this service and include the types of the status of the work order, the metadata file, the existence of incomplete assertion is authorized maintenance tasks or expire.

5. The interface system

MMSE should be integrated through services with DBB. These services are integrated into the DBB in order to ensure that the challenges of systems, including DBB DAM or, for example, the production plan DBB management system.

Depending on the build DBB interfaces do not necessarily exist to support the larger part of the features of file management. Although there are a large number of dependencies on metadata as a criterion of preservation, these data should be sidestory in DBB, and the external interface, as suggested, not required. Loading/swapping is the only features that will require interfaces, but these interfaces will be processed through digital delivery tools (e.g., SmartJog, Signiant) and, mainly, by using the set configuration.

6. Multipolynomial

MMSE and the total storage solution should support a dedicated infrastructure for the partner, as well as a shared model, under which DADC serves numerous clients in the shared memory pool. Given the sensitive nature of digital files, which are operated under DBB, many custom architecture must be designed and installed to handle all the potential moves of the files required to service the con is enta. Storage device MMSE should be able virtual and logical partitioning to prevent mutual contamination and the management of files should always be informed about the used appropriate partitioning.

7. The total cost of ownership and operating costs MMSE is a basic authorized DBB basis. MMSE provides total cost of ownership and maintenance costs that do not reduce the financial benefits aimed at DBB. It is also in the same direction with third-party business, aimed at DADC.

Annex 9. Search

1. Review

DBB requires search functionality across their infrastructure. The search should be conducted by internal data DBB (for example, partners, Customers) and for all interfaces in external data stores. However, future applications of Search must adapt to other interfaces, which include, but are not limited to the DAM system and the system of intellectual property management. Mechanisms that satisfy these requirements are not defined and should be taken different decisions.

2. Description

Search in relation to the DBB can be divided into two types: the search specified by the end user and the search specified by the system.

Search, asked p what the end user is, what usually think of when they describe how people search.

End users conduct a through search in DBB for numerous various reasons. Below is a list of the alleged features of the search specified by the end user:

A. Search Title/alpha is used by partners to select the appropriate requesting names or Names/alpha. It queries the interface in the control system name/IP partner and asks for a large number of criteria, including, but not limited to the following:

A. Name (full text search group characters);

b. Type the name (for example, the feature episode) - managed list of values;

Spock specifications - used with administrators DBB to find the appropriate specifications. Specifications contain a large amount of detail, where the differences between the specifications can be very minimal. The ability to quickly search and filter specifications to find an exact match is very important, so use relevant specifications.

d. The search component is used by Partners to study components available in DBB. Components contain multiple metadata that uniquely describes each component. The search engine componentvalue to provide opportunity for thorough search of all areas of metadata and filtering results to uniquely identify an exact match of components.

that is, the search Support materials - used by Partners to search for additional materials, added to DBB. These support materials have minimal metadata in comparison with the Components. The level of metadata depends on how the document repository manages this type of media. Minimum search should include any available metadata, such as file name and directory structure of the folder.

f. Search customer Profile - used by Partners to find the corresponding profile of the query. This functionality can be achieved through a text search or screening search, where the partner can navigate Profiles through the hierarchy (for example, Client > client Profile).

g. The search Client - the Client uses to select the Client for execution. This should be a simple text search for the name of the Client or viewer to scroll through existing Customers within the DBB.

h. The search query used by the requesting parties to find the executable in the current time or the submitted requests.

i. Search for a production plan is used by the operators or by the requesting parties, when production plans are defined/created, and after the presentation, which will occur at the level of Tehnologicheskogo the process and Objectives (particularly with respect to status).

The quest system managed hosts using the DBB for execution of its construction on the grounds. The best example of this helps to explain by browsing through the functionality of the production plan DBB. For example, to generate the query. Partner specifies the Name/alpha and customer Profile for delivery. Given this input, DBB need to conduct a thorough search of existing components, as a file, and the physical, and follow numerous business rules. These searches must be configured by system administrators and executed after the evaluation of the production plan.

Below is a list of prospective search system DBB:

A. Search components - requests DBB to find the component that best matches your criteria metadata. Data provided as input data to search for, can be extracted from many sources, but are usually given Query and linked information. The input data include, but are not limited to the following:

- ID-Name - is Partner data in the Request process.

Alpha is the data selected by the partner in the process of Query.

- Partner ID - This should be used as a filter for a specific search Components that create a specific partner. Should the tmetal:

Components not shared by the partners.

- Additional metadata specification is data that is accurately defined in the Specification associated with the customer Profile. This information is known as a query, which will require a Partner to select a customer Profile. Information about the model specification will include technical metadata, such as bit rate and form.

3. User interface

Regardless of the design of some of the input data for the search criteria require the end user. This interface should require the minimum possible user interaction. Depending on the screen PI, several design concepts should, if possible, to ensure the effective PI. For all types of search must be accessible using "special characters" or a partial match (e.g., "PAH" returns results for all results "spider-Man").

A. Basic search is the most common search interface, where one text box is used to enter text, but the search is carried out on a number of predefined fields.

b. Advanced search - search by source(s) data by assigning the search parameters for a number of metadata fields before running to create more specific Crete is IEV search (for example, the data ranges, multiselect).

C. Search based on facet - search option, which provides additional, relevant attribute that allows you to filter the result sets dynamic way. The counting of the results obtained should be listed next to each "facet".

d. Refine search - ability to search in the criteria for adding sets of returned results in order to Refine the results.

E. Proposal is an opportunity for fuzzy matches or logic, characterized by the logic of the type "did You mean..." ideally, will be available index, based on the "leading" proposals.

f. Navigation results - ability to move through the result set of a Search using a specific taxonomy/groupings.

The search results should return to the set, which can be viewed in full or using the technique of numbering pages. In addition, if the result set exceeds the threshold that is defined, the system will prompt the user to Refine their search criteria.

In addition, the responsiveness of the Search services is crucial for the practicality and effectiveness of DBB.

4. Services

In order to allow the search to internal and external systems must be created search services required and is about to expose the DBB for each internal/external data source. The reason for impacts on these search interfaces in the form of services is that the interfaces will most likely be used in numerous scenarios for a variety of purposes throughout DBB. By creating shared services, they will be much easier to use for each data source, the service should be exposed to request for each data type. In addition, this can be a query that will create indexes that cover data sources and services in order to provide the necessary response time.

Services should be extensible for querying and data retrieval of all available metadata for a particular data type (security). For example, if the service is created for issuing a request to the external system of intellectual property management (for example, GPMS for the company Sony), the input must be intelligent enough to provide numerous criteria for input (for example, Name Names and Type Names). The service should also provide a means to accurately determine areas of metadata, the desired output (e.g., Title, Year).

5. The interface system

It is assumed that several systems/subsystems will perform queries to ensure data sharing. Some identifiable system are the following:

A. Management of media assets - internal management subsystem media assets DBB components and services required to execute queries in the analysis of materials for evaluation of the production plan.

b. Management of GOLD/Asset - DBB system needs to interface with external existing asset management system, GOLD for sources to search for metadata assets during production planning.

stakes work - DBB system needs to save the data that relate to the work of DBB in order to properly assign tasks and then to couple data to facilitate billing Partners for completing work. In order to minimize double-entry Partners, DBB performs a scan for the reception element/queries the range of work orders through the integration of the system where possible.

6. Multipolynomial

There are no special multiplayer requirements to search outside needs, which will filter the search results by using the Partner as viewed values.

Annex 10. Manage paging/encoding

1. Review

DBB controls the technological process of processing for Encoding (or capture) and then by swapping Components. In this orchestration layer, run the query to create the new component in the Production plan through their adoption in DBB, metadata will be inherited captured and verified through manual and automated processes to support and create a clean data and, thus, uniquely for inventory.

Coding, also known as a takeover, is largely a manual process of creating master files are usually from the physical tape, but they can also be created from a file. It is important that it was a controlled process in order to know the status regarding specific or sets of coding. In addition, as the external provider will then enter the required metadata and transferred to the file to start the next phase in the process of paging, as well as a managed process the process is to consider that will be tracked as coordinated.

The process of Paging, which is defined within this document begins with receiving the Encoded Component or Set of Components, probably within the packer. It is assumed that outside a rare exclusive process, the component will not be able to swap in DBB without waiting Requirements for components, which was created using the Production plan (response) or from a query mastering file (in the process, Proactive creation). From the stage of receiving the file(s) adopted the file(s) is rehadat through a series of automated and manual steps to confirm the integrity of the file perform quality checks, execution of technical registration process and then formal paging file(s) in the storage system DBB and update/create the necessary metadata for the component while waiting Requirements of the component.

2. Description

On Fig depicts a process control coding and paging, which must be orchestrated using DBB.

Specification based on Coding and paging, managed through the requests and managed process is a basic concept for DBB, as it relates to maintaining a well-formed inventory with the necessary metadata and relationships to facilitate automation. The specification of a component Type can be created and used to support operations. The specification of a component Type can be created and used to support operations as determined by the group Management mastering/assets as a General template and management for creation request and then receive incoming assets. Requirement to a component represents a request for a specific Component type(s) next to the Name/alpha and creates an entry for the shell, which will be opposite the feature Requirements. This allows rules to be introduced, and will ensure consistency of metadata inventory the AI.

Requirements for components are created using queries in two main ways:

A. Response of Production plans, which allow you to encode Components and then Swap to use expectant orders, and

b. Proactively on the basis of the plans of mastering, which lead to the creation of components for the new digital editions (Features and TV content).

The seller has a certain amount of content QC before initiating transfer of the file(s)that are defined in the Master specifications for DBB through the application interface, with an extension for the provider, which begins the process of Paging. Service performed by a provider or remotely, will also make the way for the provider to enter the required metadata relative to the Component(s), as well as to ensure checksums, which will be calculated for the file(s) to verify data after the transfer to ensure the move file(s)that do not introduce distortion or interruption.

The Paging process begins with the initial receipt of the file(s), usually after the completion of coding. The process of Paging automatically checks the checksum, which includes the deployment of content if necessary (pending final determination of the package specification is the supplying from suppliers Encoding).

After checksum verify the quality of the metadata Component and the file(s) to ensure that certain characteristics of the asset are within tolerance specifications component type. Technical features automatically extracted from the file(s) and metadata are confirmed on the basis of what is achieved in an automated Technical QC and QC Content. Registration record of any automated QC process should be recorded and stored in the system for future use.

Immediately after verifying the integrity of Component(s) renegotiate for a received file(s) with the expected Demand for the components based on the metadata entry Requirements to the components in the system opposite the metadata that should accompany the file(s) from the supplier. This is an auxiliary manual process, whereby the connection only requires confirmation in most cases, but also requires the recording of an asset can be manually reconciled with the Requirement of the component in the list, in which the multiple options should be systematically identified (usually the result of bad received metadata) or, if the option is not identified by the system through the search.

The following process is designed for high-quality the CSOs play access module with frame accuracy, to be used in the following steps. Using the access module will be some additional manual inspection file(s), such as control of audio tracks and format images and their metadata before the final swap in DBB.

The next step is a technical check for the Component. Currently, it is only supposed for video Components and (related audio Components, if they are in the same process Paging) and is regarded as a manual activity. The function of technical registration includes capturing identification segment Components (i.e., strokes, shades, signs, security alarm black color, logos, program), along with information about the time codes for each segment (in and out points) and, if necessary, the coordinates of the crop. In addition, it is preferable that the process of technical registration was carried out in the module access with frame accuracy in contrast to the actually existing file as file size, especially for HD, will become cumbersome. In addition, although it was planned as a manual task, it is also desirable that a certain amount of indexing and automation/identify segments was proposed so that the button you can reduce manual work largely for verification/data options technical registration.

Fingerprinting is a process which is then executed against the file(s) to create a unique signature for a file that will later be used to uniquely identify the Name/alpha. In fact, it may or may not occur after the file is actually located inside the storage system DBB, because it may be more effective because production plans can be in the queue, waiting for this asset.

The final step in the process of Paging includes the verification of the integrity of the file, comparing the originally captured checksums and then transfer the file from the location of the Paging process in the storage system DBB to control. Final confirmation of the data Requirements for components and incoming metadata accompanying file(s) Components will be performed and can confirm that using the operator. In addition, in the framework of the system Requirement components will update completed status and to provide this visibility across the entire system.

There are some changes in this process in cases where the Components of the audio only or closed captions (CC) are connected through a managed process of Paging compared with when coordinated video and audio Components are loaded together. As p is IDE, they represent the results of queries in and out managed the Encoding process. The main difference in this process is that in order for these components have been agreed with the video asset, assuming that they are associated with him, you need to reference a copy of the audio. This can happen on the server side using specific access module created for verification of conformity for audio and/or SS. On the other hand, it can be run locally, although this is less preferable because of the requirement for moving the reference video from DBB in the workstation.

Immediately after the paging component audio only or SS in the storage system you want this type of asset is associated with one or multiple sets. This process is expected to be manual and will be carried out either as part of Management functions Inventory using Requirements to the components or after the Swap, when the Requirements to the components.

In the end, there will be specific options "Replace" these technological processes, which take into account the necessary business logic and system for assets that are already in the system, but are replaced due to the rejection or attempted re-mastering.

3. User interface

To iowatelecom interface (PI) must be available, as operator of Coding and Paging, which can be of different vendors, which may or may not be, including internal. Thus, it is required that in the presence of rich features and interactivity, interface was reliably represented by external users, and was also intuitive, since it can be assumed that training foreign sellers will change. Different sellers using this PI should not have access to the files that are used by others. In addition, the service, as mentioned above, preferably, with the PI, you will need to assist sellers Coding with the initial preparation of the preliminary transmission Component, such as entering metadata and calculate checksum.

In addition, to meet the requirements of create/update Kit mentioned above, the PI must communicate with Components and component Requirements for assets only audio and SS in Sets.

4. Services

There are a number of services that are necessary for the support of technological processes of Encoding and Paging. In fact, a large base, as these processes control of technological processes, services Orchestration of technological processes should be used to facilitate tasks in the frames of the Ah this process and metrics capture process. Services Coding not directly addressed as part of the DBB and expected to be the third party tools used by the seller to create the file(s) Components, as defined in the definition of the Master file. However, the Service/Application pre-transfer Encoding will be required in order to enable the seller to create a checksum before moving the files in the Paging process to ensure the integrity of the file.

As part of the process of Paging, you must have several features, some of which will be centralized or other that must be done locally. These services include the checksum, the file is moved. Removing fingerprints, automated technical QC and QC content. Content processing (if required), validation of the metadata and technical registration.

At the end of the priming process Management services for File Management, Storage and Management of Metadata is called to place the file(s) running DBB within its storage system and its relevant metadata.

Function connection Kit will be used primarily services management metadata.

5. The interface system

Currently, there are no front-end system that Tributs is for this functionality. However, it is understood that the inventory in the DBB will be reflected in GOLD, the metadata for the needs of incoming Components will be synchronized/updated in the system.

In addition, it would be ideal to Components/Sets technical means that are used in this process that are not directly part of the DBB, were associated more closely to integrate the entire system and any remote data and interactions.

6. Multipolynomial

Currently, there are no specific requirements for multipolarism except system, which should provide support for content encoded and downloaded from many locations, and the ability to identify (through metadata), which Partner owns the content.

Annex 11. Batch metadata

1. Review

This document describes the processes and functionality that is required to build different types of metadata that are required to deliver as part of the package.

2. Description

On Fig presents an exemplary schema object dependencies, depicting the relationship between the customer Profile associated with it metadata specifications and supporting data required to build the batch metadata, according to this specification. The objective of this scheme for prisoners who W not to determine the final design, but to help describe the types of dependencies that are assumed to satisfy cards processes future States of the SPE.

Client profile the client Profile acts as a source of coordination throughout the entire production process DBB to ensure that what is created that meets the requirements of the client.

Metadata specification defines the requirements for metadata for a particular customer Profile. Metadata specification indicates which requires metadata, where each data item is as it appears in the metadata DBB canonical forms and what if this is the case, conversion is required in order to provide metadata in a format preferred by the client.

Auxiliary data Auxiliary data form all the information required for delivery as part of the package. These data can be found in various data stores, DBB, i.e. Store Requests, Names/Wizard and Files, and they should appear in the metadata Specification. If you require additional information outside DBB, they will be provided in the form of additional material to each request through the interface (such as facing the user or system to system).

Master-data name-the Name represents the master data describing intellectual property, which is supported within the DBB as the highest level of organization for their content, which allows you to search, retrieve, and produce in order to fulfill the Request. Examples include title, abstract, talent, genre, rating and ruler of copyright.

Data request Data request contain information specific to the transaction terms which were used to generate the query. Examples include the date of sale, the date of sale and price.

Technical data - define metadata for specific assets and/or the files included in this package and contain elements such as asset type, file name, file size and checksum.

Declaration of service - specifies the contents of the package. It may include a list of all assets completed for each title.

Other data - different customers may have additional metadata requirements that were not discussed as the metadata is divided into chapters. For this reason, the metadata specifications must be fully flexible with the ability to add or remove data to support the needs of the client.

Metadata in canonical form.

DBB requires metadata in canonical form, which eliminates izmenchivost and impose strict vocabulary to ensure that that ordinary language metadata was used for expression, both at the regional level and at the level of values. Specifications metadata partner appears next to this canonical form to provide a consistent reference point which, ultimately, will facilitate the display of metadata specifications of the individual client. Metadata in canonical form must support multiple languages and other formats of regional specific data (such as date, currency, etc).

Mapping metadata

Each metadata attribute DBB source and the associated values of the metadata specification of the Partner should be displayed metadata in canonical form. Similarly, each specification client metadata should be displayed metadata DBB in canonical form. This allows effective only when there is a display of the client once unlike once for each partner, which distributes the content. It also adds a level of abstraction that protects the display from changing the data model over time.

Converting metadata

Each client may have specific requirements, covering how the particular data item. This can be as simple as the format specific data, or more complex, such as specific rules t is aslali. For example, the client may have their own genres to categorize content. In this case, the value of the genre will be broadcast from the genre of DBB. These conversion rules should be easily managed and should be restricted whenever possible, non-technical development.

Production versions of metadata

It is necessary to control the change of the metadata and maintain historical data. It is important to know that the metadata has been sent to the client as part of the package. However, the client may reject the package because of the "bad" metadata. You need to understand exactly what was sent, to ensure the same "bad" metadata were not re-sent. Conversely, you can request to re-send exactly what was originally sent, even though the data could subsequently be changed. Because the packages are not supported indefinitely, restoration of metadata that have been sent should be a function of finding all the metadata that were originally sent to the customer. Some clients, depending on their customer Profile, may require more current metadata for further shipment.

3. User interface

The user interface must exist to control the display of elements specific metadata in the DBB in metal is the R canonical form. Similarly, the method must exist to display items in a specific batch client metadata in canonical form. In addition, the user must be an interface that allows you to add or edit metadata, which exist only in the DBB.

4. The interface system

DBB will maintain their own data warehouses for data type that will be included in the batch metadata. However, DBB should have interface with additional systems to ensure batch metadata (for example, GPMS).

5. Requirements multipolarism

Future users may have requirements specific batch metadata that will affect the Metadata canonical form, Displaying metadata and Conversion of metadata.

Annex 12. Create/Manage packages

1. Review

This document describes the processes and functionality that are required to create and support packages. The package is a compilation of one or more products designed to customer specification, along with any additional materials that are required, according to the agreement between the partner and the client.

2. Description

On Fig shows an exemplary schema object relationships, showing how the packages will be soldiers who tion associated with customer Profiles and Specifications. Objects in blue are defined in other technical descriptions, while they will be introduced in this document with a greenish-blue shade. The objective of this scheme is not the final build, and in helping to describe the types of relationships expected to meet the card processes future States of the SPE.

Customer profile - defines a set of specific deliverable requirements to customers and supports automated processes for delivery, tracking, billing and create a product/service, and also includes a configuration specification (type name) and level metadata profile.

The package defines a compilation of one or more of the products plus any additional materials or content that is required in accordance with the agreement between the Partner and the Client, which will ultimately delivered as part of the Query.

The package specification defines the content or elements of the package that are required for the package to be considered complete. The package specification will be changed on the basis of two main criteria: the type of the delivered product and the client to whom it is delivered. For example, the package specification to features, which may differ from that PR is naznachen for TV episode. Similarly, the package specification features for iTunes may differ from that which is intended for broadcast to the client.

Item package defines a discrete piece of content that is requested as part of the client package. Each element of the package will have its own specification based on its content type or element Type. For example, an item of Metadata packet will have the specification of the metadata, and the Picture of the advertised product foreground will have a Specification for the image.

The type element specifies the type of element, that is, announcement, advertising frame story, a Picture of the advertised product. Metadata, Music videos, etc.

The package Creation process can be logically divided into three sub-processes, which are presented below: the Collection of content; the Assembly of the package; and Support package. The collection of content is an activity, which is responsible for the identification or localization of all required elements of the package inside the query. Building the Package ensures that all required elements of the package were collected, performs any processing that is required for confirmation of package elements in the specification of the client (i.e., transcoding, supply watermark, XML conversion, DRM etc), and organizes the elements of the package in sootvetstviis the package specification. The support package is the processes that govern the package after it is created.

The collection of content is an activity, which is responsible for identification and/or localization of all required elements of the package for the products inside the query. The package specification is presented in the form of a mechanism for informing the process of Collecting content that you want to collect. The package specification should contain the following information:

A. What should be included in the package, that is, announcement, image, metadata, etc.

b. How much is required for each element of the package, i.e., two announcement, four images, some metadata.

sgde you can find each of the elements of the package, and what criteria are used for its location (the location of the system files, search criteria DAM, calling web services, and so on).

d. Agreement customer name each element of the package.

that is, the Organizational scheme of the elements of the package (i.e., loose files, archived using the product-specific directory structure and so on).

The collection of Content begins with determining whether or not the members of a package for a given request. DBB should detect the status of each element of the package inside the PI request, allowing the respective user(s) to view what you need to do SB the RA and execute the Query.

Where DBB really is viewing collection elements of the package will be a design. One option may be a query based on the WIP area, where all of the content that you want to Query, divided into stages. Another option is to store only the required content in the DAM. This will require a standard metadata in canonical form in order to allow DBB to post content based on a combination of Query and Template attributes package, such as the name of the query, the query and the content Type Template package (that is, Title=quantum of solace, Territory=US & Type content=Picture of the advertised product shot). The process should be automated by using the minimum number of movements of the content. Accordingly, the decision of the DAM has a distinctive advantage in that the content can be loaded once and reused for multiple requests, then manually filled areas WIP necessary for further re-populate for each Request that is being processed.

As just defined above, agreement regarding the name of the file will also be necessary for further automatic generation in certain cases under DBB, in order to meet the requirements of delivery to the Customer. These soglasovatelno names of the files changed between distributed clients and usually consist of a number of abbreviations and the United metadata values, describing the asset. Agreement regarding the name should be specific to a particular client, but must also be configurable to customer needs. In order to determine the naming conventions of the files, the user DBB must choose the number of fields of metadata (e.g. Title, image Format, fixed-line, for example, "_" "-"), or other defined variables (for example, current date, current time). The text resulting from inputs metadata can be modified on the basis of a number of different criteria, precisely defined by the user DBB. Each of these criteria can be used separately or together in order (for example, removing vowels, then cut to a maximum length of 10 characters).

The following criteria can also be used to enter specific metadata or full expression:

A. Cut to length - for example, to reduce the field Names to 10 characters. "Transformers" will look like "Convert".

b. Removing vowels (e.g., removal of vowels from the field Names. "Transformers" will be "Pbrsus").

C. In the case of uppercase/uppercase - for example, in the case of capital in the field Names. "Transformers" will be "converters").

d. Remove special characters (e.g., removal of the colon from the Title. "C is ednie gates: infinity" will be "Stargate Infinity")

Given the flexibility required for this data manipulation, complex manipulations can be better processed by CPU usage of Regular expressions (e.g. RegEx).

The collection of content is complete when all the required elements of the package have been identified and/or are divided into stages. However, some level of operational control must be maintained in order to be able to create the package, and, therefore, run the query, even when certain elements of the package is not available. This means that an authorized operator requesting the start of the Package Build process even if the process of Gathering Content has not been completed. Some of these requirements can be performed using business rules that indicate which elements of the package really need to deliver. At the highest level, the operator must have the ability to send an "as is" regardless of what instructs the package specification.

The Assembly Package, you can start immediately after the collection of elements of the package. Its purpose is to organize the content, as described in the package specification. Each element of the package will have its own specification. For example, the announcement may be required to deliver in a specific format, the image format and bit rate; metada the data can be converted to a specific format of the client. DBB is expected to use relevant specifications in order to know what transformations must be performed in the future. When assembling the package, DBB will perform some combination of the following, based on the package specification and specifications item package:

A. Determine whether, and at what level encryption (package or package element) and apply where needed.

b. Convert the image to support the elements of the video (i.e., announcement, music video etc) and metadata.

C. Use of forensic watermarks, if required.

d. Apply DRM to the products, if required.

E. Apply the agreement as to the specific name of the client for the packaging of the items on demand.

f. Arrange the elements in the package directory structure.

g. Combining or packaging elements of the package, i.e. Zip compression program stuffit. Package MXF, ends when all of the required elements of the package have been processed to their respective specifications. However, some level of operational control must be maintained to ensure the possibility of creating a package and, therefore, the request to perform even when certain elements of the package were not collected and/or completed.

Support package consists of the following is x processes required for control poslebrachnoi packaging:

A. The packing stage for QC - relocate package location QC and notify the relevant part, which is ready package for QC.

b. Split into stages of service delivery move assembled and, if necessary, qualitatively tested the package in a location with a phased delivery.

C. Saving package - ensure compliance with policies deleting/saving packages. These policies can be a client or a specific partner.

d. Management service - allows the administrator to manually access or remove packages.

3. User interface

The user interface must exist to control all aspects of the specifications package from the creation of the element type to build the package specification. Create, view and publish specifications package are considered part of the complete adaptation process.

In addition, the request and/or the portal Administrator/Partner will detect the status of each element of the package within a specific query that allows authorized users to see what still needed to collect, which allows you to continue running the Query.

Finally, create a Batch, you could potentially send a notification to the parties responsible is output for providing elements of the package, and then run QC package.

4. The interface system

DBB must interact with DAM or file system, which places the package elements that are required for packages.

5. Multipolynomial

DBB must interact with DAM systems partner in order to collect the necessary elements of the package. However, another option is to secure Partner portal, which allowed the direct swapping of items package in DBB.

Annex 13. Financial processes

1. Review

DBB requests interaction with financial systems company Sony or partners in order to ensure the cost estimates to facilitate financial statement, to perform billing or transfer process cost and to facilitate the reconciliation of financial transactions where necessary.

Model DBB financial processes must support the business relationship with the SPE, inter-firm model, and the model of the partner model is the most traditional customer/vendor. The concept of self-service, discussed in Appendix 3 Management requests" can be used as inter-firm model, and third-party models, which will also be described. However, it is also considered necessary to include requirements for the level of services to the customer DBB on which Partners can provide traditional RO. This level of service the customer will C the same time to interact with DBB through the Module request, as described self-service model.

All financial models DBB will take into account the interfaces with PI or financial systems partner to use the basic functionality of these systems and to address the key financial requirements of the right DBB where possible. The Department DBB as a content management platform for the distribution of the requirements of GAAP or managed financial systems SOX desirable.

Specific architectural options, including GOLD, Xytech Medicinals and System DADC CATFISH, presented in the form of options, System Architecture below. They include an image of the interface and implementation DBB.

2. Description

The concept of financial integration

The following sections document the functional components of the financial flow DBB. There are numerous options available some of these components. These options are discussed at the end of this section.

Price list - As discussed in Annex 6 "production Planning" and in detail in Appendix 5 Master data process" and 7 "task Management", it is assumed that the DBB will be able to maintain the price within their architecture or will be paired with a system that supports pricelist. This preisgarantie to take into account different scenarios of pricing, General for Commerce, content processing. These scenarios should include, but not limit to the following:

A. The price, according to the Partner price list should be configurable to perform a unique pricing with the help of a partner, and the partner may be SPE or a third party. The price list should keep a copy, and modify pricing partner and apply the changes to the standards with full percentage or with an individual price changes. Required grouping and modification of a large number of prices of services.

b. Pricing is pricing replaces price list Partner, when you agree on the terms of specific transactions.

C. Types of pricing - the following types of pricing must be supported.

Pricing quantity involves the application of discounts on large quantity.

Pricing fixed compensation - includes services for which the amount or part are not considered when calculating rates.

Pricing minimum quantity - Fixed fee is payable until then, until you reach the minimum number, then use the number or the pricing of standard modules.

d. Variable pricing - the Following variables which should be used when displaying the price list.

Number - the number of created elements, for example, five Mpeg2 files.

Modules number of modules that can or cannot be multiplied by a number, for example, 10 suppliers 5 Mpeg2 files. They are also used for any of the services on the basis of the General module.

The execution time is the execution time of the content.

The source and type of output type of the source file, for example, HD depending on the source SD output format transcoding.

Order type - the required level of services and the type of transaction for the order, for example, rush orders, unpaid.

Service type - the type of service (services)performed for a query, for example, transcoding, the weakening of 3:2, etc.

The bit rate is the bit rate of the content.

File size - the file size of the processed content.

Operations statement of accounts - Through display between Tasks DBB and price list. Operations billing will be developed using DBB. These operations can be produced using the production plan in an automated manner or by modifying the production plan, as described in Annex 6 "production Planning" and " Appendix 5 "Master data process". However, operations billing will contain components of the valuation of the Production plan and will support the VAT invoicing or processes of transfer value.

Interface RO production plan In the framework of the model, a Sony production plan after approval by the Requesting party in DBB will produce invoicing that are supported by the required financial data. Then it will export this information into the system execution WPF GOLD. This interface will lead to the creation of an Order to purchase media in GOLD. Required auxiliary information such as the name of the SPE/ID alpha, and the other financial information may be included in the Module design of the query (e.g., territory, market) and will also be presented in the interface. In order to support the demand of the Partner, this interface will support the standard scheme and the functionality of the web services that you can configure and move multiple partners. Manufacturing instructions and Assets source can be included in the interface only for information purposes. GOLD PO (or RO partner)created using DBB, is intended as a vehicle for billing purposes, and not as instructions for performing the work. A report on the details of the allocation process will be a requirement DBB, and not a system RO partner. Item, to which reference will be required in both systems.

Immediately after creating a production plan of the sending interface messages the plan will be delayed pending approval through the interface. Approval SORA cost of the production plan will be executed in GOLD (or in the system RO partner). After approval, the message will be sent back to the DBB, deblocare Production plan.

Requirements R1 include an interface in GOLD and extensibility to third-party systems RO. Design and construction of a third party interface RO is not in the scope for R1.

The interface of the execution of the production and transfer of the cost Immediately after receiving approval SORA through the interface will execute the production plan. Significant changes in the Production plan that can occur at run time, can lead to subsequent iteration interface RO. Review you can send and approve in order to support the invoicing process. After completing the DBB will send the message in GOLD, performs the function of transferring value. This function will reflect the current manual process in the system of GOLD, with which to create a check account of the current and deferred for export to SAP. Because of the internal nature of operations and guarantees using the interface that the Operation billing DBB will be equal to the operations GOLD RO, this process can be fully automated. Automation of this the process is within the scope of R1, but assume that you will use your current GOLD Interface in SAP, and the new interface in SAP is not required.

Take account DADC - Regardless of the options selected for models partner, it is assumed that the Operations billing within the DBB will involve Financial system DADC, CATFISH, to accept bills and universal accounting books. In the model SPE these operations A/R will be used to support approval of the transfer of value between the SPE and the DADC. In the model, Partner, SOM will provide a standard billing and receiving function of accounts.

Financial model variables

Variables that may exist between the Model SPE and Model partner include, but are not limited to the following:

Pairing RO with the production plan - based production, which evaluates Partners, is an option, but is not a requirement of this model. As briefly discussed above, the Partners may or may not directly use the query engine. If they can't use, they'll have to deal with representatives of customer Service DADC, who will directly interact with the module request DBB on behalf of the Partner. In this case, before performing the work may require the need for traditional RO partner. This will be a more traditional interaction is the influence of the buyer/seller. Although this process does not directly affect the requirement R1, you should consider the use case.

Transfer of accounts/cost - Partner Interface of the production plan and transfer value, as described above in the model SPE, will be impossible without a dedicated integration project, which is not included in the scope for R1. It is assumed that the processing of traditional accounts will be conducted using DADC from the system COM. All internal transactions between the Price list, Operations, billing and SOM A/R can remain in this state, as described above.

Options system architecture

Price list and Operations statement of accounts - Current options include integration implementation Xytech Medicinals, which will be located in some part of the infrastructure DBB. The rich functionality of the price and billing product Xytech will be used for the processing of financial transactions and to pair with GOLD on the side of the SPE and CATFISH on the side DADC, as described above.

The second option is that the price and billing can also be supported within the system COM. This will require for the COM support all pricing, which refers to the concepts, and to pair with GOLD, as described above.

Option support Price list in CATFISH and Surgery is billing Medicinals looks impractical. If it is used solely for financial purposes, these systems will be considered as an auxiliary system, and requirements for DBB project will be based on the interfaces required to support the financial model. The integration of these systems will be in the field of Rl. More specifically, it excludes the implementation of the example Medicinals as only the billing system.

The third option is that the Xytech Medicinals will be used in the main processing functions of the content DBB, such as the query Module, production Planning, task Management and inventory Control. Medicinals should be presented as solutions in these areas, functions and Price list Operations billing will be in scope because of their tight integration within the architecture Medicinals.

3. User interface

It should be possible modifications invoicing at any point in the workflow process. This interface is also disclosed in Annex 6 "production Planning" regarding the modification of the plan. More specifically stated for clarity that the operating personnel must have the ability to view and modify operations to be billed before the end of the production plan is as or before any iteration interface RO production plan or for Partners before billing.

4. Services

Depending on the final design, more specifically, with respect to any use of Xytech Medicinals, DBB will require services for data interface Operations billing. This service should have access to information about price lists, apply display for assessed tasks and create the resulting transaction billing. This service must be performed within the DBB for evaluation purposes only, if necessary, not only to support the distribution.

5. The interface system

Depending on the resolution options, system architecture, interface DBB in the GOLD system will require support approval of the COFA and Transfer value, as described above. If Medicinals included as part of the DBB for operational purposes, it affects the nature of the interface in the system DADC COM. This interface may include the full scope of the Price list, Operations, billing, Claims CATFISH and Transfer value, or may simply require pairing Operations billing from Medicinals.

6. Multipolynomial

Throughout the Section draws attention to the questions of the partners that relate to changes in the financial flow. In all areas where you are collecting or processing financial data, otnositelnosti facilities of the Partner and the Partner, it will be possible to use processing variables, which are described here.

1. The way digital distribution of media content using the highway distribution containing phases in which:
receive a request for media content from a client, where the request includes a client profile;
perform an inventory and analysis of assets source by iteratively passing through the customer profile to generate output data;
perform mapping capabilities, in which the number of rules allows you to display assets source on the customer profile;
plan production process, which determines work items and milestones based on the capabilities displayed in response to a request for media content from the client.

2. The method according to claim 1, wherein the customer profile specifies a specific set of specifications as regards the requirements of the media content or metadata to the client.

3. The method according to claim 2, in which a certain set of specifications defines the key variables and requirements needed to support automated processes.

4. The method according to claim 1, wherein the customer profile specifies the customer requirements for delivery of media content.

5. The method according to claim 1, which is set for each client one or more client profiles, in order to present numerous the business model for the client and/or requirements varying depending on the territory.

6. The method according to claim 1, additionally containing a stage, on which:
perform optimization of work items and execution phases defined in the production process.

7. The method according to claim 1, additionally containing a stage, on which:
produce a query using operations, responsible for the licensing of media content in respect of operations, responsible for the implementation of media content to licensees.

8. The method according to claim 1, additionally containing a stage, on which:
perform analysis to identify key information regarding the identification of media content, the client, subject to the service and terms of service that includes the due date.

9. The method according to claim 1, additionally containing a stage, on which:
perform activities related to the delivery, which include automated management technologies content processing.

10. The method according to claim 9, in which automated technology management, content processing includes steps for managing files, transcoding, packaging and delivery, which are operated using standardized data interfaces.

11. The system bus of the distribution that contains:
the mechanism of production analysis for the reception of the request from client media content that includes profilecount,
analysis of production provides an inventory and analysis of assets source using iterative pass through the customer profile to generate output data analysis; and
the mechanism of production planning, configured to determine the work items and execution phases using the output of the analysis.

12. The highway system of distribution according to item 11, in which the mechanism of production planning contains modules for execution or use of the source asset components, processes and analysis of the cost and time of the production cycle.

13. The highway system of distribution according to item 11, in which the client profile includes:
package specification, specifying particular items for delivery to the client to query media content;
preferences of production, which are the specific requirements of the client, determine which assets source and limiting production;
technical specification that is not content-based requirements that specify the codec, frame rate, image resolution and other technical parameters based on the files; and
the specification of the Assembly, specifying requirements to non-linear editing.

14. System highway distribution is s indicated in paragraph 13 in which the requirements for nonlinear installation include the replacement logo, the imposition of a blackout or adding messages.

15. The system bus of the distribution of item 13, in which the package specification includes a specification of the content and the metadata specification.

16. The system bus of the distribution indicated in paragraph 15, in which the specification content includes reusable technical specifications, build specification and data about the preferences.

17. The highway system of distribution according to item 11, in which the output of the analysis include the requirement to components, which is a tool for managing the tasks required to control paging.

18. The highway system of distribution according to item 11, in which the analysis engine production includes modules for receiving specifications delivered to the customer, supporting inventory data and the master data of the process.

19. System highway distribution p, in which the mechanism of production analysis is performed with the opportunity to identify the appropriate process using specifications that are delivered to the client.

20. System highway distribution p, optionally containing the kit includes the components grouped and coordinated and synchronized the first collaboration components, the components are determined to work together, arranged to provide an indication of the master data process mentioned set.

21. System highway distribution claim 20, in which the kit includes one of a video component and one or more audio components.

22. The computer-readable storage medium containing a computer program for digital distribution of media content, and computer program includes executable commands that cause the computer to:
receive a request for media content from a client, where the request includes a client profile;
the inventory and analysis of assets source by iteratively passing through the customer profile to generate output data;
display performance opportunities, in which the set of rules provides a mapping of assets source on the customer profile; and
planning of the production process, defining the work items and milestones based on the capabilities displayed in response to a request for media content from the client.

23. The computer-readable storage medium according to article 22, further containing executable commands that cause the computer
performing optimization of work items and execution phases defined in the production process.

24. Machine-readable but Itel information on p.22, additionally contains executable commands that cause the computer
the production request using operations, responsible for the licensing of media content in respect of operations, responsible for the implementation of media content to licensees.

25. The computer-readable storage medium according to article 22, further containing executable commands that cause the computer
perform analysis to identify key information related to the identification of media content, the client, subject to the service and terms of service that includes the due date.

26. The computer-readable storage medium according to article 22, further containing executable commands that cause the computer
actions related to the delivery, which include automated management technologies content processing.

27. The computer-readable storage medium according to article 22, in which the executable commands that cause the computer to perform automated technology management, content processing, include executable commands that cause the computer
perform file management, transcoding, packaging and delivery, managed using standardized data interfaces.



 

Same patents:

FIELD: radio engineering, communication.

SUBSTANCE: information on characteristics of weapons of each party is switched; the information is stored in a first memory unit; the information is supplemented with characteristics of a backup group with variable input time; information on weapons of all groups is used to pre-evaluate characteristics of their difference and determine coefficients of independent combat superiority of party A over groups B1, B2; the obtained information is used to select a strategy of combat operations; the remaining weapons of all groups are determined; intermediate characteristics of groups and the outcome of combat operations are stored in a second memory unit and read therefrom, and then transmitted to inputs of a display unit, where information on the outcome of combat operations of party A is displayed: win, loss, draw; the remaining weapons in groups: type of strategy, delayed backup, type of difference, values of coefficients of combat superiority and coefficients of distribution of weapons.

EFFECT: high combat efficiency and effectiveness of operations with different groups, rapid planning of the selection of the optimum target distribution strategy.

2 cl, 5 dwg

FIELD: chemistry.

SUBSTANCE: average daily concentration of an i-th substance Ci is established in an investigated area (point) for one year; the average arithmetic value is determined from the monitoring data (contact indication and (or) remote probing) or from data obtained by simulating scattering of impurities in the atmosphere for one year according to recommendations and the obtained risk values are compared with WHO-recommended risk criteria.

EFFECT: high accuracy of determining concentration of pollutants in atmospheric air.

FIELD: information technology.

SUBSTANCE: in the method, video is prepared by dividing it into fragments and describing each fragment with key words, a set of key words or phrases which, during advertising, are shown in context of the display of the advertisement. A control means consisting of two units is used: a decision unit and a mixing unit, wherein the mixing unit includes algorithms for inserting or superimposing an advertisement on video; the decision unit determines for the mixing unit what advertisement should to be added at what points; the UI can operate on both the transmitting side: Internet server, television studio, disc recording factory, and the receiving side: viewing program, browser, hardware player, television.

EFFECT: high accuracy of managing advertising or audiovisual information while specifying various mixing parameters during video display.

4 cl, 3 dwg

FIELD: information technology.

SUBSTANCE: data base is created for commodities on demand on the market, manufactured and non-liquid, ordered, based on technical, price characteristics and geographic location of the commodities, commodity flow is generated based on the criterion of the least end price of the commodities; fulfillment of each order is evaluated by assigning each contractor a reliability coefficient which is taken into account when determining the end price of a commodity, and the paying capacity of the contractor during financial transactions.

EFFECT: combining processes of supplying, manufacturing and consumption to ensure uninterrupted operation of companies, the highest quality of servicing clients at the lowest cost and shortest time of fulfilling an order.

1 cl, 1 dwg

FIELD: machine building.

SUBSTANCE: monitoring system of capacity of a set of machines operating on a common workstation is proposed, which contains the following: at least one data acquisition module having the possibility of tracking the capacity of the set of machines; and a controller interacting with at least with one of the above data acquisition module and having the possibility of acquiring the data on capacity of machines from at least one of the above data acquisition module; detecting disturbance of normal capacity based on acquired data on the capacity of machines; comparing the acquired on machine capacity; and of determining, based on comparison, which of the following factors: state of machines, state of the operator or state of the place has the greatest influence on disturbance of normal capacity.

EFFECT: improving determination accuracy of a factor having maximum influence on disturbance of normal capacity.

10 cl, 4 dwg

FIELD: information technology.

SUBSTANCE: portable medication dispensing system comprising: a portable medication container, configured to be carried by a user, comprising at least one secure compartment configured to hold medication; a controller, responsive to access information, configured to assign a patient to the at least one secure compartment such that medications for the patient are authorised for placement into the at least one secure compartment; selectively permit the user access to the medications for the patient in the at least one secure compartment when the access information indicates that the user has access to the at least one secure compartment; and restrict access to retrieval of the medications for the patient in the at least one secure compartment when the access information indicates that the user does not have access to the at least one secure compartment; and an information output module configured to: output usage information regarding access to the at least one secure compartment.

EFFECT: providing control and reliable loading of medication into a reliable portable device for the patient.

29 cl, 10 dwg

FIELD: information technology.

SUBSTANCE: system for generating content downloads from a shared database of user actions, comprising: an interface for communication with a set of users; and a processor which supports communication with a set of users through the communication interface, the processor being configured to: collect an individual user catalogue of information on user actions for each user in the set of users; aggregate the individual user catalogues of information on user actions for the set of users in a database; from the aggregated individual user catalogues based on an indication from a first user, selectively retrieve information on user actions from one or more of the individual user catalogues of one or more other users belonging to at least one group of uses in the set of users; and transform the selectively retrieved information on user actions for delivery to the first user.

EFFECT: enabling users to mutually and transparently offer commodities, services and content on a context-dependent or device-independent basis.

65 cl, 10 dwg

FIELD: information technology.

SUBSTANCE: when making manufacturing schedules, orders and scheduled maintenance are ordered according to the opposite of increasing importance by applying ranking rules; primary resources for performing operations are selected from a plurality of available primary resources by applying ranking rules; operations to be performed are selected from a queue of operations on primary resources by applying ranking rules. The order of performing the operations by the defined manufacturing technology, availability of resources, availability of component parts, efficiency of primary resources, the need to perform readjustment operations for primary resources and the need to transport components are taken into account. The system implements said method.

EFFECT: broader functional capabilities, high efficiency of processing data, more optimum use of hardware and software resources by cutting time spent on processing data and by reducing the number of human errors in source data.

8 cl, 43 dwg

FIELD: information technologies.

SUBSTANCE: interactive learning complex comprises a teacher's computer with an operating system and software having facilities of connection to an interactive board, and also a multimedia projector of training materials connected to the teacher's computer and designed to project multimedia data to the interactive board. Besides, the interactive learning complex is equipped with a projection screen as the interactive board, and also an infrared cone emitter, equipped in its turn with an infrared light diode, with the help of which the graphical interface cursor is moved in the plane of the projection screen in the form of a size and intensity alternating spot, with a web-camera with a narrowband infrared filter, which reads the radiation spot of the conical radiator, the operating system of the teacher's computer with the help of software executes control operations on interaction of the infrared conical radiator with the web-camera and the projection screen.

EFFECT: invention provides for indication of cursor movement on a screen with a user's graphical interface, and also control of the user's graphical interface on the basis of a 3D positioning of an indicator without usage of additional buttons and elements of the graphical interface.

5 dwg

FIELD: information technology.

SUBSTANCE: medical communication system includes a plurality of end-user audio/video recording and playback devices (40) located at recipients of medical assistance, and a medical server (10) configured to receive audio/video messages (90′) generated by the end-user audio/video devices and to generate and transmit audio/video responses (94) to targeted end-user audio/video devices. The medical server includes an audio/video recording and playback device (12) configured to playback received audio/video messages and to record audio/video responses, and the end user audio/video recording and playback devices are configured to playback audio/video responses (94′) received from the server. In some embodiments, each end-user audio/video device includes: a video recording lens (62); a microphone (64); and an automatic lens cover (63) configured to physically block the video recording lens except during recording of audio/video content. In some embodiments, each end-user audio/video device includes a user entertainment device (50, 52).

EFFECT: improved communication between medical professionals and patients.

13 cl, 6 dwg

FIELD: radio engineering, communication.

SUBSTANCE: information on characteristics of weapons of each party is switched; the information is stored in a first memory unit; the information is supplemented with characteristics of a backup group with variable input time; information on weapons of all groups is used to pre-evaluate characteristics of their difference and determine coefficients of independent combat superiority of party A over groups B1, B2; the obtained information is used to select a strategy of combat operations; the remaining weapons of all groups are determined; intermediate characteristics of groups and the outcome of combat operations are stored in a second memory unit and read therefrom, and then transmitted to inputs of a display unit, where information on the outcome of combat operations of party A is displayed: win, loss, draw; the remaining weapons in groups: type of strategy, delayed backup, type of difference, values of coefficients of combat superiority and coefficients of distribution of weapons.

EFFECT: high combat efficiency and effectiveness of operations with different groups, rapid planning of the selection of the optimum target distribution strategy.

2 cl, 5 dwg

FIELD: information technology.

SUBSTANCE: method creating an audio scene for an avatar in a virtual environment comprises the following steps: creating a link structure in a virtual environment between a plurality of avatars; reproducing an audio scene for each avatar based on its connection with other avatars connected by the links; wherein the created link structure is configured to determine the angle for reproducing the audio scene and/or the attenuation coefficient for applying to audio streams on input links. The angle for reproducing the audio scene corresponds to angles of links between said each avatar and other avatars connected by links; the link structure includes a minimum spanning tree. Loops are introduced into the minimum spanning tree such that the minimum length of the loops is shorter than a predetermined value so as to prevent echo in the reproduced audio scenes.

EFFECT: solving a task such as creating voices which really seem to originate from avatars in a virtual environment.

12 cl, 6 dwg

FIELD: information technology.

SUBSTANCE: information on unit indicators of compared means is switched, recorded in a first memory unit, sent to a worst quality and best quality reference forming unit, which forms the corresponding beginning and end of a straight line which defines a quality estimation scale; planes perpendicular to that straight line are made through points of the compared means in the space of the unit indicators; parameters of the points of intersection with the estimation scale are found, values of which form complex quality indicators of the compared means, the maximum value of one of which corresponds to the preferred means.

EFFECT: high security of devices.

2 cl, 2 dwg

FIELD: information technology.

SUBSTANCE: system for hosting interactive audio/video (A/V) streaming with short waiting time includes a plurality of servers on which one or more applications are executed. The system also includes a network with input routing, which receives packet streams from users and routes these packets to one or more said servers, wherein said packet streams include user control signal input, wherein one or more said servers is configured to calculate A/V data in response to user control signal input. Furthermore, the system includes a compressing unit which is connected to receive A/V data from one or more servers and derive therefrom streaming compressed A/V data with short waiting time. The system also includes an output routing network which routes streaming compressed A/V data with short waiting time to each user over a communication channel through an interface.

EFFECT: high quality of A/V data transmitted over a communication channel.

29 cl, 40 dwg

FIELD: information technology.

SUBSTANCE: device for simulating the process of choosing a commodity has an array of m*n first registers, second registers whose number equals the number of rows of the array, adders whose number equals the number of rows of the array, AND element units whose number equals the number of rows of the array, third and fourth registers whose number equals the number of columns of the array, an array of m*n divider units, an array of multiplier units, a unit of OR elements, a maximum code selecting unit, a decoder, four delay elements and a flip-flop.

EFFECT: broader functional capabilities by providing selection of the best version of a commodity based on given consumer criteria.

1 dwg

FIELD: information technology.

SUBSTANCE: at least some of illustrated versions of implementation relate to systems having a flow computer configured to monitor a physical process which is external with respect to a data processing unit, an archive server connected to the flow computer over a computer network and configured to receive data related to physical process and store said data in nonvolatile data storage, and a human-machine interface connected to the archive server over a computer network. The human-machine interface is configured to extract values of archive data related to the physical process from the archive server, calculate statistical data not stored in the archive server based on the values of archive data and display the statistical data on a display device.

EFFECT: reduced amount of data stored in archive servers.

32 cl, 8 dwg

FIELD: information technology.

SUBSTANCE: content and metadata associated with the content may be provided to a number of users. The content may be displayed on a display device while the metadata may be transmitted to a remote device corresponding to a receiving user. The user may further request desired information or metadata pertaining to the content and the requested information or metadata may be transmitted to the user's remote device. Different users may request different information on the same or different objects being displayed or presented on a display device. Each requesting user may receive requested information on the same or different objects via corresponding remote devices.

EFFECT: providing content and metadata associated with consumption of the content, providing content and metadata which do not prevent consumption of the content.

27 cl, 6 dwg

FIELD: information technology.

SUBSTANCE: disclosed is a method of generating a customised data viewer in a computer system, where the viewer is configured to display data at any level in a data model. The disclosed method includes a step of receiving a user request indicating that one or more portions of data are to be displayed in a user-customised manner using a data viewer. Further, according to the method, the requested data portions that are to be displayed using the data viewer are accessed. A dynamic data viewer configured to display the accessed data portions in the user-customised manner indicated in the received user request is then generated. The generated dynamic data viewer is also applied to the accessed data portions, such that the generated viewer displays the requested data portions in the user-customised manner.

EFFECT: automating setup of a data viewer for using a user-selected defined data type.

20 cl, 4 dwg

FIELD: information technology.

SUBSTANCE: image container file has at least first and second multimedia streams (MS). The first MS includes first image data representing an image. The second MS includes arbitrary data which can correspond to: a different representation of the same image; annotations to the first image data; second image data that together with the first image data form a new image with greater dynamic range, resolution, field of view or other attributes that can be derived from processing two or more independent images; or an executable file related to the first MS. The image container file can also include extensible metadata to hold information describing one or more multimedia streams of the image container file, as well as DRM information for obtaining a license to access encrypted data or verifying the authenticity of encrypted or unencrypted data.

EFFECT: providing, when creating an image container file, functional linkage of multiple multimedia streams, one of which is received by a receiver and the other includes arbitrary data.

26 cl, 6 dwg

FIELD: information technology.

SUBSTANCE: device for measuring depletion of copper-nickel sulphide ore further includes two voltage stabilisers, the outputs of which are connected to two variable resistors, the movable contacts of which are connected to inputs of analogue-to-digital converters, built into an AVR microcontroller, the output of which is connected to the gate of a MOSFET transistor, the drain circuit of which includes the radiating coil of an inductive sensor, which is concentric with a receiving coil, the output of which is connected to a shaping amplifier, the output signal of which is fed to the input of a precision amplitude detector, the output of which is connected to the input of a scaling amplifier with the possibility of controlling the origin and the maximum of the measuring scale; the output of the scaling amplifier is connected through a voltage repeater to the analogue input of the AVR microcontroller.

EFFECT: enabling rapid analysis of the depletion of copper-nickel sulphide ore in a measured volume for further use of the measurement results to reduce loss in quality of the mined ore.

2 dwg

FIELD: message boards and mail servers.

SUBSTANCE: electronic message board is provided with database in form of several known words, which are selected in specific order, while each word is connected to respective URI. Message text from user computer is checked using a plurality of known words. When message text does not include a known word of plurality of known words, message is placed at electronic board. Each known word is found in text, known in text is converted to hypertext format with URI connected to word, as destination of link, and message is placed at message board.

EFFECT: higher efficiency.

7 cl, 4 dwg

Up!