WO2009114559A1 - Agent-based digital cinema management systems - Google Patents

Abstract

Provided is, among other things, a digital cinema management system that includes a number of separate screen management systems, each screen management system managing content played on a digital cinema projector, with a SMS agent attached to each screen management system. A theater management system, separate from the screen management systems, monitors and controls operations for a theater that includes the screen management systems, with a TMS agent attached to the theater management system. The TMS agent is configured to communicate with each SMS agent, and each SMS agent is configured to communicate with the TMS agent. Each SMS agent includes a finite state machine listening for an occurrence of a predefined digital cinema platform event on the attached screen management system that changes a state of the finite state machine and, upon such an occurrence, issues an asynchronous SMS event communication to the TMS agent.

Description

AGENT-BASED DIGITAL CINEMA MANAGEMENT SYSTEMS

[01] This application claims the benefit of United States Provisional Patent Application Serial No. 61/068,893, filed on March 10, 2008, and titled "System and Method for Integration of Distributed and Heterogeneous Cinema Management Services using Hierarchically Clustered Semi- Autonomous Agents to Implement Common APIs in a Service Oriented Architecture", which application is incorporated by reference herein as though set forth herein in full.

FIELD OF THE INVENTION

[02] The present invention pertains to the management of digital cinemas, i.e., cinemas that display movies and similar video content using at least some digital, rather than film-based, projectors.

BACKGROUND

[03] The following discussion presents certain background information pertaining to the present invention, including discussions of both prior-art information and observations made by the present inventors.

[04] The film industry is transforming from 100-year-old film technologies and methods of managing and distributing rolls of film to an end-to-end digital and automated system. One desirable step of this transformation is a standardized digital format for the film content. Another desirable step is a standardized platform for managing and distributing the digital content in a reliable, efficient, feature-rich and flexible manner.

[05] Ideally a standards body such as the Society of Motion Picture and Television Engineers (SMPTE) would initiate the development of a top-down industrywide platform standard for managing and distributing the digital content "scene-to- screen". However, so far only general requirements documents have been published. For example, DCI Digital Cinema System Specification v.1.1 , published by Digital Cinema Initiatives, LLC and approved April 12, 2007 (the DCI Specification) describes certain requirements for the mastering of, distribution of, and theatrical playback of digital cinema content from the distributors' perspective. Figure 14 in chapter 7.5.9.1 of the DCI Specification illustrates one example of a multiplex theater system architecture. In addition, Digital Cinema System Requirements Release 1.0, published by the National Association of Theatre Owners in 2006 (the NATO Requirements) sets forth additional requirements from the exhibitors' perspective.

[06] Although specification of a formal workflow model for digital cinema is, in fact, being defined by 2020 3D Media, a European Union initiate, the market and the introduction of products is outpacing efforts to define a top-down standards. Consequently, the development of standards, as usual, likely will be defined bottom-up in an ad hoc manner. Such standards are typically inferior to top-down designs.

[07] Different vendors are fielding Screen Management Systems (SMSs) on different platforms to manage individual screens inside theaters. The SMS provides a user interface to theater management for local control of an auditorium, such as controls to start, stop, select a Show Playlist, and edit a Show Playlist. In addition to control, the SMS typically can monitor and run diagnostics on equipment within the auditorium and provide such status information to the exhibitor. The SMS is required to operate in one or two modes, local or remote.

[08] Other vendors are fielding Theater Management Systems (TMSs) on different platforms to connect and manage site servers, players, projectors and other systems from various vendors including the individual SMS. The TMS should provide a user interface to theater management for centralized control of multiple auditoriums to perform all of the SMS functions as well as others, as described in the DCI Specification chapter 7.5.9.3.2.

[09] The TMS must interoperate with equally independent SMS implementations. To be DCI compliant, the SMS must be able to function with and without the TMS. This means that the SMS must be able to take over some responsibility from the TMS when the TMS is absent, but work in conjunction with the TMS when the TMS is present. The problem is that, in general, an off-the-shelf TMS built by vendor A does not talk to an off-the-shelf SMS built by vendor B, much less a plurality of SMS built by different vendors.

[10] One intermediate solution is to define a unique Application Programming Interface (API) for each TMS/SMS pairing in order to facilitate interoperability. However, the task of creating the API is time-consuming and expensive. The industry is struggling with who bears the burden of providing the API and who bears the burden of implementing the API. Furthermore, the API can result in a loss of functionality for either the SMS or the TMS, or for the digital cinema platform in general. [11] The introduction of exhibition management systems (EMSs) to the cinema management hierarchy, in order to connect and management multiple TMSs, will result in the same technical and industry difficulties. As the data and communication flow increases and becomes more sophisticated and the size of the network continues to scale up, the sophistication, interoperability and scalability of the overall hierarchical digital cinema platform should follow suit.

SUMMARY OF THE INVENTION

[12] The preferred embodiments of the present invention provide an architecture that acts as a kind of "central nervous system" for the digital cinema platform, in order to posit an intelligent, interoperable, federated environment for all players in the digital cinema industry. Such an architecture preferably provides the benefits of a top-down design, as if the EMS, TMS and SMS units were designed for interoperability, with the benefit of allowing units with vendor-specific communication protocols to participate in the platform.

[13] In the preferred embodiments of the present invention, these goals are accomplished through the use of a "fractal-enabled" common API that is recursively defined at the different levels of the platform hierarchy from SMS to TMS to EMS, and perhaps further. This common API preferably defines abstractions of the minimal functionality required of a child cinema management system (CMS) unit (e.g. SMS, TMS or even EMS) to participate in the platform and establish service-level agreements between CMS units in parent-child relationships in order to mediate the parent-child protocols and vendor-specific child protocols to allow the child CMS unit to communicate in its protocol with any parent CMS unit programmed to the common API. In the preferred embodiments, the common API also publishes the functionality of a given CMS unit to external non-agent clients. A common event hierarchy is provided as part of the common API abstraction that translates vendor-specific events to digital cinema platform (DCP) events

[14] The fractal-enabled common APIs preferably are implemented by a hierarchy of semi-autonomous clustered agents attached to the CMS units that provide the services in a service-oriented architecture (SOA) utilizing asynchronous messaging between agents within the platform and to external non-agents outside the platform. Generally speaking, the agents may be located on the child or parent CMS unit or remotely. The agents preferably are configured to both listen to and generate DCP events to implement the common API abstractions in a recursive parent-child relationship so that behavior of CMS units is recursively defined and aggregated to provide the services defined by the service-level agreements. Agent platforms preferably cluster agents to aggregate the functionality and behavior of child CMS units into the parent CMS unit, in order to facilitate both local and centralized control of the platform. The preferred embodiments also include a messaging service that allows the agents to communicate using asynchronous messaging of DCP events to maintain a consistent internal state of behavior and data between CMS units when operating in a co-dependent manner managed from a central location and to synchronize the states following independent operation managed from a local child CMS. The SOA preferably provides registration and discovery by external non-agent clients of the services and integrates agent platforms with external non-agent clients and service providers through a transport mechanism.

[15] In addition, the agents preferably are context-aware, e.g., having intelligence to identify and then suppress transmission of state information that no longer is relevant, such as information that could not have been transmitted when relevant due to network problems, network congestion or device malfunctions. Still further, the agents preferably are user-configurable, permitting the users to specify: (1) what information should be returned, when and in what format (e.g., as to the latter, entire log dumps or just summary statistical information only); (2) what information is to be prioritized; and (3) what kinds of alerts are to be delivered and under what circumstances.

[16] By appropriately monitoring the states of the devices to which they are attached, monitoring incoming messages from agents attached to other devices, and working together in a coordinated fashion, the agent structure of the present invention can achieve efficiencies not previously possible with conventional systems. Such monitoring can involve, e.g., listening to events generated by a CMS and/or reading log files generated by the CMS.

[17] In one particular respect, the present invention addresses the problems identified above by using agents to listen for and communicate digital cinema platform events. Thus, one embodiment of the invention is directed to a digital cinema management system that includes a plurality of separate screen management systems, each screen management system managing content played on a digital cinema projector, with a SMS agent attached to each screen management system. A theater management system, separate from the screen management systems, monitors and controls operations for a theater that includes the screen management systems, with a TMS agent attached to the theater management system. The TMS agent is configured to communicate with each SMS agent, and each SMS agent is configured to communicate with the TMS agent. Each SMS agent includes a finite state machine listening for an occurrence of a predefined digital cinema platform event on the attached screen management system that changes a state of the finite state machine and, upon such an occurrence, issues an asynchronous SMS event communication to the TMS agent.

[18] Another embodiment is directed to a digital cinema platform (DCP) that includes a plurality of cinema management system (CMS) units deployed in a hierarchical network with parent-child relationships to manage hardware and software elements and distribute digital content, with each parent CMS unit capable of performing the tasks of each child CMS unit and managing and integrating a plurality of child CMS units, with each child CMS unit capable of functioning in conjunction with the parent when the parent is present and without the parent when the parent is absent, and with at least some of said parent and child CMS units having different vendor-specific communication protocols that are incompatible to support the parent-child relationship. A common application programming interface (API) is provided for the child CMS unit at each level of the hierarchy, the common API defining abstractions of the minimal functionality required of a CMS unit to participate in the platform and establish service level agreements between CMS units in parent-child relationships in order to mediate the parent-child protocols and vendor-specific child protocols to allow the child CMS unit to communicate in its protocol with any parent CMS unit programmed to the common API, the common API publishing the functionality of a given CMS unit to external non-agent clients. Also included is a common event hierarchy as part of the common API abstraction that translates vendor- specific events to DCP events. Semi-autonomous agents are attached to the CMS units in the hierarchical network and configured to both listen to and generate DCP events to implement the common API abstractions in a recursive parent-child relationship so that behavior of CMS units is recursively defined and aggregated to provide the services defined by the service level agreements. Agent platforms at levels of the hierarchy cluster agents to aggregate the functionality and behavior of multiple child CMS units into the parent CMS unit so that each agent is accessible to facilitate centralized control of the platform as well as local control of elements. A messaging service allows the agents to communicate using asynchronous messaging of DCP events to maintain a consistent internal state of behavior and data between CMS units when operating in a co-dependent manner managed from a central location and to synchronize the states following independent operation managed from a local child CMS. A service oriented architecture (SOA) provides registration and discovery by external non-agent clients of the services and integrates agent platforms with external non-agent clients and service providers through a transport.

[19] The CMS units preferably include at least one theater management system (TMS) unit and a plurality of screen management system (SMS) units in the parent-child relationship, the agents implementing a common TMS API attached to the TMS unit and a plurality of common SMS APIs attached to respective SMS units. In certain sub- embodiments, the agents implement the common SMS API to provide at least IContentTransfer, IContentManagement, IKey Transfer, IKeyManagement, IScreenValidation, IScreenProjection, IScreenSchedule, IScreenOperation and IScreenLog services, e.g., with the services provided by the common SMS API being replicated into the common TMS API.

[20] The CMS units preferably also include at least one exhibition management system (EMS) unit and a plurality of said TMS units in the parent-child relationship, the agents implementing a common EMS API attached to the EMS unit and a plurality of common TMS APIs attached to respective TMS units. In addition, the agents preferably replicate the common SMS API into the TMS API and the SMS and TMS APIs into the EMS API.

[21] At least first and second of the SMS units can have different first and second vendor-specified communication protocols, one such agent implementing a common SMS API between the TMS and said first SMS unit and another such agent implementing the common SMS API between the TMS and said second SMS unit. The common event hierarchy preferably includes events that span the hierarchy of services provided by the hierarchy of CMS units. The common event hierarchy preferably includes events categorized by increasing specialization with respect to the event concern.

[22] The common event hierarchy preferably includes an infrastructure branch that includes events that emanate from DCP-unaware technological components such as generic hardware, software, storage and networking elements that make up the DCP and a domain branch that includes events that emanate from DCP aware components build to solve the DCP problem. More preferably, infrastructure events contain sparse simple information stemming from low-level machine elements and domain events contain more rich elaborate information from rich contextual environments. In certain sub- embodiments, the infrastructure events use SMPTE terms and domain branch events use terms consistent with the common API. Also, in certain embodiments the infrastructure and domain branches are each subdivided into multiple classes including content, security, scheduling, playout and automation.

[23] Preferably, the taxonomy of events in the common event hierarchy models the DCP; the agents communicate in an onto logical-based exchange of messages where the ontology is a model of the DCP to share knowledge and improve decision making; agents that implement a common API for a child CMS unit may be located on the child CMS unit, on its parent CMS unit or remote to either CMS unit; any agent programmed to FIPA standards can register in the DCP one; services are passive and stateless and agents are active and state-based to function beyond the common API to help maintain the integrity of the CMS unit in relationship to its parent; and/or the agents are computing entities (e.g., each said agent includes a finite state machine that listens for DCP events and changes state to generate DCP events for local management and/or each said agent is responsive to signals generated by remote state machines to change state for centralized management).

[24] The DCP platform also can include an additional plurality of unattached agents that provide a higher level of functionality based on the shared knowledge of agents. In that case, the unattached agents preferably are located at the highest level of the hierarchy.

[25] Another embodiment is directed to a central nervous system for a digital cinema platform (DCP) including a plurality of cinema management system (CMS) units deployed in a hierarchical network with parent-child relationships to manage hardware and software elements and distribute digital content, with each parent CMS unit capable of performing the tasks of each child CMS unit and managing and integrating a plurality of child CMS units, each child CMS unit capable of functioning in conjunction with the parent when the parent is present and without the parent when the parent is absent, and at least some of said parent and child CMS units having different vendor-specific communication protocols that are incompatible to support the parent-child relationship. The central nervous system includes a common application programming interface (API) provided for the child CMS unit at each level of the hierarchy, the common API defining abstractions of the minimal functionality required of a CMS unit to participate in the platform and establish service level agreements between CMS units in parent-child relationships in order to mediate the parent-child protocols and vendor-specific child protocols to allow the child CMS unit to communicate in its protocol with any parent CMS unit programmed to the common API, the common API publishing the functionality of a given CMS unit to external non-agent clients. A common event hierarchy is included as part of the common API abstraction that translates vendor-specific events to DCP events. Semi-autonomous agents are attached to the CMS units in the hierarchical network and configured to both listen to and generate DCP events to implement the common API abstractions in a recursive parent-child relationship so that behavior of CMS units is recursively defined and aggregated to provide the services defined by the service level agreements. Agent platforms are included at levels of the hierarchy that cluster agents to aggregate the functionality and behavior of multiple child CMS units into the parent CMS unit so that each agent is accessible to facilitate centralized control of the platform as well as local control of elements. A messaging service allows the agents to communicate using asynchronous messaging of DCP events to maintain a consistent internal state of behavior and data between CMS units when operating in a co-dependent manner managed from a central location and to synchronize the states following independent operation managed from a local child CMS. A service oriented architecture (SOA) provides registration and discovery by external non-agent clients of the services and integrates agent platforms with external non-agent clients and service providers through a transport mechanism.

[26] Another embodiment is directed to a central nervous system for a digital cinema platform (DCP) including a plurality of cinema management system (CMS) units deployed in a hierarchical network with parent-child relationships to manage hardware and software elements and distribute digital content, each such parent CMS unit capable of performing the tasks of each child CMS unit and managing and integrating a plurality of child CMS units, each child CMS unit capable of functioning in conjunction with the parent when the parent is present and without the parent when the parent is absent, and at least some of said parent and child CMS units having different vendor-specific communication protocols that are incompatible to support the parent-child relationship. The central nervous system includes: a common application programming interface (API) provided for the child CMS unit at each level of the hierarchy, the common API defining abstractions of the minimal functionality required of a CMS unit to participate in the platform; a common event hierarchy as part of the common API abstraction that translates vendor-specific events to DCP events; a plurality of semi-autonomous agents attached to the CMS units in the hierarchical network and configured to both listen to and generate DCP events to implement the common API abstractions in a recursive parent-child relationship so that behavior of CMS units is recursively defined and aggregated; a messaging service that allows the agents to communicate using asynchronous messaging of DCP events to maintain a consistent internal state of behavior and data between CMS units when operating in a co-dependent manner managed from a central location and to synchronize the states following independent operation managed from a local child CMS; and a service oriented architecture (SOA) that provides registration and discovery by external non-agent clients of the services and provides services to external non-agent clients and service providers through a transport.

[27] Another embodiment is directed to an architecture for providing a central nervous system for a digital cinema platform where hierarchical agents create a central system of control, with distributed, recursive behavior, which guarantees the scheduled distribution of massive digital content, the management and timely distribution of Key Delivery Messages corresponding to content that is to be played at a specific time and location, the management and distribution of show playlists and schedules that reference content secured by Key Delivery Messages, the management and distribution of infrastructure and application events consistent with an onto logical model of the digital cinema platform, the capture and distribution of security logs to verify the security of the system, the invocation of digital content playout and the capture of playout progress from anywhere on the platform, where: (a) agents are organized in an hierarchical fashion, so that behavior comprising elements of the digital cinema platform are recursively defined and aggregated; (b) agents are configured to be semi-autonomous so that they can act both under central control and in a completely autonomous manner, independent and isolated from centralized control; (c) agents communicate in a language that expresses behavior and properties inherent in the digital cinema platform; (d) agents can be local or remote to the entity being represented; (e) events are defined and categorized across the digital cinema platform spectrum; (f) an event hierarchy subsumes both infrastructure (system) and domain (application) concerns; (g) events distribute state between each of the constituent parts of the digital cinema platform, and whereby consistent state must be maintained when elements work in a co-dependent manner and must be synchronized following uncoordinated independent behavior; (h) events are interceded and forwarded by hierarchical agents; (i) asynchronous messaging implements point-to-point and publish- subscribe communication of events; (j) finite state machines are used to define and execute both remote and local agent behavior, including event generation and handling; (k) finite state machines governing agents can be centrally managed, scheduled and distributed; (1) finite state machines and agents can be combined, such that more complex behavior derives from simple behavior in fractal fashion; (m) agents externalize behavior to non- agent actors through formal service contracts; (n) formal service contracts are implemented by various agents and/or hierarchical agent clusters; (o) a service-oriented architecture is used to provide the registration and discovery of services implemented by agents; (p) access to services must be made accessible through many different wire and message protocol combinations; (q) service interfaces support the fractal behavior of the parent-child relationships inherent in the platform, and that are implemented by agents; (r) work and data flows through the system are implemented and supported by fractal-enabled interfaces; and (s) service-oriented architecture and event-driven architecture integrate platform agents with external clients and service providers.

[28] The foregoing summary is intended merely to provide a brief description of certain aspects of the invention. A more complete understanding of the invention can be obtained by referring to the claims and the following detailed description of the preferred embodiments in connection with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[29] In the following disclosure, the invention is described with reference to the attached drawings. However, it should be understood that the drawings merely depict certain representative and/or exemplary embodiments and features of the present invention and are not intended to limit the scope of the invention in any manner. The following is a brief description of each of the attached drawings.

[30] Figure 1 is a block diagram illustrating a digital cinema platform according to the present invention within a typical environment.

[31] Figure 2 is a block diagram illustrating certain inter-process communication strategies employed by agents in a distributed, heterogenous system environment.

[32] Figure 3 is a block diagram illustrating a hierarchical arrangement of clustered, semi-autonomous agents.

[33] Figure 4A is a block diagram illustrating access of a TMS API for invoking SMS functionality, and Figure 4B is a block diagram illustrating access of a EMS API for invoking SMS functionality.

[34] Figure 5 is a block diagram illustrating an example of agent and hardware topology. [35] Figure 6 is a block diagram illustrating parent-child relationships of CMS units to allow roll-up and drill-down behavior.

[36] Figure 7 illustrates a portion of an event classification hierarchy.

[37] Figure 8 is a block diagram illustrating translation of an event classification hierarchy.

[38] Figure 9 is a block diagram illustrating the use of finite state machines to provide independent local control of agents as well as centralized remote control.

[39] Figure 10 is a block diagram illustrating representative communications between a SMS Agent and a TMS agent.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

[40] The following disclosure describes, among other things, an architecture that can act as a "central nervous system" for the digital cinema platform to posit an intelligent, interoperable, federated environment for all players in the digital cinema industry. Such an architecture preferably also can provide the benefits of a top-down design, as if the EMS, TMS and SMS units (or, more generally, a variety of different CMS units) were designed for interoperability, with the benefit of allowing units with vendor-specific communication protocols to participate in the platform. The individual CMS units, either by themselves or with the assistance of an agent, preferably provide a certain minimum functionality defined by a "fractal-enabled" common API to participate in the digital cinema platform.

[41] A common application programming interface can be, for example, extremely beneficial for both TMS and SMS vendors. It allows TMS systems to easily integrate different digital players, and SMS vendors need only provide a single API in order to hook into any theater management system. The same relationship would hold true for both EMS and TMS vendors.

Digital Cinema Platform.

[42] The present agent architecture preferably is designed to act as a "central nervous system" for the digital cinema platform. More preferably, this architecture entails the hierarchical clustering of agents managed by finite state machines and working in a coordinated fashion to implement fractal-enabled common APIs at each level of the hierarchy to fulfill all the steps required to manufacture, prepare, manage and distribute digital content from "scene-to-screen". [43] Agents such as a SMS agent, TMS agent and EMS agent preferably are "attached" to the SMS, TMS and EMS units (or, more generally, to various CMS units), respectively. The agents may be located on either the parent or child CMS unit in any parent-child relationship, or may even be located remotely. Moreover, it is noted that the individual agents described herein preferably are, but need not be unless specifically stated otherwise, implemented as separate components; rather, the functionality of two described agents may be merged into a single component when such agents are hosted on the same device, and an agent may be incorporated into an application program, such as the application program performing the CMS functionality to which the agent is attached. Still further, additional "unattached" agents can be provided within the hierarchy, typically at the top level, or even outside the hierarchy to provide additional processing of shared- knowledge for higher-level functionality.

[44] A service-oriented architecture (SOA) preferably is used for providing a public or external interface to the world outside the cloistered, i.e., inner circle, agent world. The preferred embodiments of the present invention integrate state-of-the-art open- source solutions under an SOA model that has service component architecture (SCA) affinity, but fills in the missing pieces. These missing pieces pertain, e.g., to service registration and discovery, the relationship between a lookup service and a service implementation, and the use of leasing concepts to maintain system robustness.

[45] Asynchronous messaging has been described in other documents with emphasis on an event-driven architecture. However, the main reason for the use of message-oriented middleware (MOM) in the present digital cinema platform is integration, particularly with reference to work and data flows.

[46] With a "fractal-enabled" API and design and with hierarchically clustered agents, it is possible to scale and implement the independent/co-dependent relationships that distinguish the present digital cinema platform. Agents preferably maintain system coherence and consistency in such an environment.

[47] An exemplary environment for the present digital cinema platform is illustrated in Figure 1. As shown, each screen management system (SMS) 5, the basic unit in the digital cinema platform (e.g., controlling and managing content played on a digital cinema projector 7 and in some cases controlling other systems within a corresponding auditorium), has attached to it an SMS agent 10 that monitors the state of the SMS 5 and communicates in a coordinated manner with TMS agent 15 which, in turn, is attached to the theater management system (TMS) 17 (e.g., handling overall theater functions such as content transfer, security/key management, event monitoring, reporting, content library, show playlist, problem escalation and site management). Although not shown in Figure 1, TMS agent 15 preferably also communicates with other SMS agents that are attached to other SMSs within the same theater. The same TMS agent 15 preferably also communicates in a coordinated manner with EMS agent 20 that is attached to the exhibitor management system (EMS) 22 (e.g., handling functions such as booking, showtime publishing, programming, auditing, scheduling, trailer placement, accounting and payments). Although not shown in Figure 1, TMS agent 15 preferably also communicates with other TMS agents that are attached to other TMSs managing any number of theaters that are under common ownership/control.

[48] Typically, the higher-level systems within the hierarchy (e.g., TMS 17 and EMS 22) communicate with DTS Digital Cinema 25 or other entities providing the software applications for implementing the digital cinema, as well as service vendors 30. For example, DTS 25 can provide, among other things, infrastructure services 26 (e.g., including lookup, security, notification and order processing), administration 27 (e.g., including organizations, contacts and billing/accounting), brokerage 28 (e.g., including release schedule, negotiation service and catalogue), and content management 29 (e.g., including preparation, inventory, KDM management, upload and delivery). The other service vendors 30 provide, e.g., production facilities 31, showtime publication 33 and theater operations 34 (e.g., including online ticketing, box office/ticketing, concession management and back office). Service vendors 30 also include DTS Support 32 which can include, e.g., service tickets, customer service, field service, encyclopedia and network monitoring. In addition, various distributors 35 typically communicate with the exhibitors in order to negotiate sales of 37 and communicate with DTS 25 and service vendors 30 in connection with those sales efforts.

[49] The present invention focuses primarily on the components of the digital cinema system, e.g., the SMS 5, TMS 17 and EMS 22. It is again noted that the agents of the present invention do not have to reside on the host/machine in order to fulfill their obligations. The preferred architecture allows for relocation of components, message forwarding, proxies, etc. In addition, the hierarchy need not be limited to three levels (EMS <-> TMS <-> SMS), but preferably can incorporate many more levels if desired. For example, it might be the case that the EMS deals with a regional or country office that manages the theaters. In addition, or instead, there might be a Network Operations Center (NOC) that maintains SMS units directly. [50] It is also noted that the individual CMS components (e.g., the SMS 5, TMS 17 and EMS 22) need not be bound by any particular geographic location, except to the extent specifically and expressly stated otherwise; rather, each CMS component is intended to be defined solely by its functional capabilities and other limitations specifically set forth in the claims. For example, a TMS 17 need not necessarily be located within the theater to which it pertains and, in certain cases, it can even be incorporated into an EMS 22.

[51] The formalization of an event hierarchy that can subsume both application and device events and that can be extended to the digital cinema platform as a whole is desirable. The extension of the concept to agents that can proxy TMS and SMS units preferably can enable virtual digital cinema platform configurations on top of any TMS and SMS implementation, respectively. The added value, in this case, is in the overall unification of the fairly large Exhibition Management Systems and the very small Screen Management System, independent of the deployment environment.

"Fractal-Enabled" Common API.

[52] An API is a set of definitions of the ways in which one piece of computer software communicates with another. It is a method of achieving abstraction, usually (but not necessarily) between lower-level and higher-level software. Generally, the main purpose of an API is to spare the programmer the need to write software from scratch. An API in the present context preferably states in a formal way what behavior is required by the CMS unit in order to fulfill requirements, e.g., the minimum requirements of groups such as NATO, DCI and SMPTE. If, for example the TMS programs to the SMS API, it does not need to know anything of the SMS. If the SMS supports the SMS API, it would not need to adapt to any one TMS manufacturer/implementation.

[53] The API implemented in the present invention preferably is technologically agnostic, e.g., meaning that it does not matter whether the TMS is a Java Application running on Linux or whether the SMS is written in C++ running on Windows. The API is valuable without stating a technological implementation. Today, Web Services Description Language (WSDL), which is expressed in extensible markup language (XML), commonly is used to describe services. WSDL describes, in a formal, technologically neutral way, the "what, where and how" of accessing services. WSDL allows for different bindings, i.e. different technological implementations. Simple Object Access Protocol (SOAP), which also uses XML, is a technologically agnostic message protocol. HTTP is a widely available wire protocol. A good SOA architecture will support different bindings, but such message and wire protocols generally are outside the realm of what an API according to the present invention is trying to express.

[54] In the preferred implementations of the present architecture, the API also is "common" at each level of the hierarchy and is "fractal-enabled". The "common" API defines abstractions of the minimal functionality required of a CMS unit to participate in the platform and to establish service-level agreements between CMS units in parent-child relationships in order to mediate the parent-child protocols and vendor-specific child protocols, allowing the child CMS unit to communicate in its protocol with any parent CMS unit programmed to the common API. A common event hierarchy preferably is part of the common API abstraction that translates vendor- specific events to DCP events. The common API preferably publishes the functionality of a given CMS unit to external non- agent clients. A "fractal-enabled" API, as the expression is used herein, recursively replicates up the hierarchy. For example, the SMS API is replicated into the TMS API, the TMS and SMS APIs are replicated into the EMS API, and so forth, e.g., as described in greater detail below. Such defined minimum functionality and recursiveness of the common API are highly desirable elements in providing the interoperability and scalability of the platform.

S O A/Agent/ Asynchronous Messaging.

[55] The three inter-process communication strategies that support system development in the preferred distributed, heterogeneous environment include: agents, service oriented architecture (SOA) and asynchronous messaging (infrastructure & agent). The agents used herein preferably function in a closed world, meaning that they have their own wire and message protocols, agent registration, discovery mechanism, etc. More preferably, such agents can interoperate, provided that they adhere to standards governed by the IEEE Foundation for Intelligent Physical Agents (FIPA). In this world, the agents can have state, and use their own communication channels, in addition to public event channels, to maintain consistent state for the system as a whole.

[56] Figure 2 is a block diagram illustrating certain inter-process communications employed in a representative embodiment of the present invention. Included in Figure 2 is a plurality of agents 40. It is noted that within this communication context there is no hierarchical distinction between the different agents 40; for example, any one of the agents 40 could be a SMS agent 10, TMS agent 15 or EMS agent 20. [57] A service-oriented architecture preferably is the standard vehicle by which services are published to external service consumers. A service-oriented architecture used in the present invention preferably accommodates a variety of transport communication protocols 45 for communications between the agents 40 and various external applications 46. Very seldom are services state-based. Associated with the present service-oriented architecture are infrastructure services, such as service registration (lookup) 47 and notification 48. These two services have industry standards and are considered as part of the enterprise service bus offering. Asynchronous messaging is part of the transport layer. It facilitates both process and data flow.

[58] In Figure 2, service choreography and orchestration is not displayed, but it preferably involves an additional infrastructure service that is attached to an enterprise service bus product. The services of 41 implemented by the agents 40 preferably are published to external non-agents (applications) 46 through the SOA platform 42 via a transport mechanism (wire and message protocols, asynchronous message queues etc) 45. For ease of illustration, the SOA platform 42 and underlying services 41 are only depicted on a single agent 40, but preferably are provided for each agent 40.

[59] The agents 40 of the present invention preferably are distributed concrete computing units that provide services. One of the purposes of each of the present agents preferably is to be able to act in an autonomous or semi-autonomous manner based on shared knowledge through agent communications 44. There are both open standards and open-source solutions available for agent-based platforms. As noted above, the present agent platform 43 preferably is based on the FIPA architecture, using the same underlying agent platform architecture, especially with respect to agent registration and communication. This approach allows any agent programmed to FIPA standards to register itself in the digital cinema platform of the preferred embodiments.

[60] The agent architecture of the present invention preferably is designed to act as a central nervous system for the digital cinema platform. In preferred embodiments, this entails the hierarchical clustering of agents 40 working in a coordinated fashion to fulfill all the steps required to manufacture, prepare, manage and/or distribute digital content from "scene-to-screen". This structure for the digital cinema platform is unique because it is capable of providing an intelligent, interoperable, federated environment for all players in the digital cinema industry. For example, with an agent-based digital cinema platform according to the preferred embodiments of the present invention, distributors would be able to know everything about their content, even where and when it is currently playing. Unlike Federal Express tracking, however, the present digital cinema platform preferably allows the distributor, e.g., to stop playing a particular movie at a particular screen at any point in time, provided it had the permission to do so.

[61] A service-oriented architecture (SOA) provides a public or external interface to the world outside the cloistered, i.e. inner circle, agent world. The SOA is a formalism or model for building services. While agents on the same agent platform can talk to each other in agent speak for data synchronization issues, for example, everybody else preferably deals with the agents via published service contracts. Such service contracts, therefore, preferably are implemented by the agents. This relationship between general agents and services is well-known. One of the more interesting facets of agents is that in a large distributed service infrastructure, the agents typically help implement SOA governance policies. These issues pertain to autonomic computing: self-healing, self- configuration, self-protection, etc.

[62] Asynchronous messaging has been described in other documents with emphasis on an event-driven architecture. However, the main purpose behind the use of message-oriented middleware (MOM) in the present digital cinema platform is integration, particularly with respect to work and data flows. In the Web Services community, this is invariably referred to as service choreography and orchestration. Asynchronous messaging provides important abstractions which are then implemented by solution providers. Such abstractions include publish-subscribe methods, persistence of messages, transactional properties, etc.

Semi- Autonomous Hierarchically Clustered Agents.

[63] Each agent 40, as used herein, preferably is a piece of code that interfaces with an element (hardware or software) and communicates 44 asynchronously in an agent language with agents associated with other elements to report on state. Another view is that the agent 40 is a robot that contributes to the automation of the system. The agents 40 used in the present invention do not need to be on the same box/machine where functionality is executed, provided they can reach the box (i.e., are somehow attached to the box) in order to execute the functionality. The agent 40 preferably communicates through the attached device's API or through the universal API provided by the present system. The agent 40 can then communicate 44 with the agents on (or for) other devices which are tied into those devices through their own or the universal API (thus, the recursiveness mentioned above). [64] Preferably, agents 40 implement the underlying management system hierarchy by cooperating through the agent platform 43. As noted above, the present agents preferably conform to standards (more preferably, FIPA) so agents written by different entities can interoperate using "agent speak". Without the agent platform 43, the next level of communication ordinarily would be through services. However, services almost always are stateless and do not have the same level of sophistication as agents (the sophistication being, e.g., in terms of self-healing, self-optimization, exhibiting autonomous behavior, etc.).

[65] The present agents 40 preferably are capable of autonomous computing and are self-healing, self-protecting, self-configuring and self-optimizing. For example, an agent 40 that is specific for a particular digital cinema player preferably is written. The agent 40 would include adaptation code specifically for that player to implement SMS API behavior. Similarly, an agent 40 preferably would be written for every physical device that is intended to work within the overall DCP system.

[66] Each of the present agents 40 preferably is capable of semi-autonomous behavior, meaning that the agents 40 can act in both an independent and a co-dependent fashion. This relationship preferably is how, for example, the TMS and the SMS interact, as well as how the EMS and TMS interact. Central control may also be provided, meaning that agents 40 work in co-dependent fashion, managed centrally. The management of the agents 40 from a remote, central location can be performed by a finite-state machine. At a particular point in time, a scheduled job executes, and the execution mechanism preferably is a finite-state machine.

[67] Figure 3 is a block diagram illustrating a hierarchical arrangement of clustered, semi-autonomous agents 40 (with individual ones of the agents 40 labeled with different reference numbers for ease of discussion). Such a hierarchical arrangement of agents 40 preferably is used to create a system of both isolated and inter-connected functionality. The agents 40 of the present invention preferably work with knowledge that is represented by an ontology, a formal representation of knowledge based on a model of the digital cinema platform. Each agent 40 or cluster of agents 40 preferably is "tied" to a "management system", e.g., an enterprise, a theater or a screen in that underlying hierarchy.

[68] However, SMS Agent 50, for example, as a computing entity, can be located anywhere; it does not necessarily have to reside on the device that is actually performing digital playout. In the preferred embodiments, each agent 40 adapts itself (or is adapted when it is written) to the constraints of the device and its environment. TMS agent 60 and SMS agent 50 are configured to be in a parent-child relationship. As a result, when SMS Agent 50 starts, for example, it will look to connect or register with its parent, the TMS agent 60. The connection 51 between TMS agent 60 and SMS agent 50 can use any wire protocol, but the messages between TMS agent 60 and SMS agent 50 preferably are comprised of agent-based protocols and a language that expresses the digital cinema domain. This connection 51 preferably represents a shared knowledge that is not publicly accessible.

[69] An agent platform 43 preferably is used to cluster the agents 40 that collaborate closely to fulfill an overriding purpose. Thus, for example, theater agent platform 65 provides management, registration and discovery policies for agents 40 in the corresponding theater complex.

[70] Clients outside the agent environment preferably access services through a published service contract or interface, e.g. through an input content playout invocation 67. The preferred embodiments provide a number of service interfaces that formalize behavior and that are made publicly available. For external clients, a local service registration and discovery service preferably is used. Thus, for example, the TMS agent 70 or any non-agent TMS software can invoke services for the SMS 5 (shown in Figure 1) to which SMS agent 88 is attached through the public API 72.

[71] Each TMS agent (e.g., 60 or 70) preferably also provides publicly accessible services through a TMS API (e.g., corresponding API 61 or 71). In addition, the Theater Agent Platform (e.g., platform 65 or 75) preferably allows for aggregation of behavior, specifically the aggregation of SMS functionality across all SMS units within the theater complex into the TMS. For example, as shown in Figure 4A this type of aggregated behavior would allow an external client to invoke a play movie command 102, as if it were dealing directly with the corresponding SMS unit 5 itself. However, in this case, access to the SMS unit 5 preferably is managed by the TMS agent 60 through the TMS API 61.

[72] An Exhibitor Management System (EMS) 22 (shown in Figure 1) controls and manages all theaters in a circuit. As shown in Figure 3, the agent 20 for the EMS 22 interacts with TMS Agents 60 and 70 (each an example of a TMS agent 15), and through message forwarding via such TMS Agents 60 and 70, to SMS Agents 50, 55, 58, 80, 85 and 88 (each an example of SMS agent 10). In addition, e.g., through an SMS API provided by the EMS agent 20 (discussed in more detail below), the EMS 22 preferably can communicate directly with an individual SMS 5. The EMS Agent 20 preferably does not exist in isolation, but rather is part of an agent cluster within the exhibition management system agent platform 95. Just as the TMS Agents 60 and 70 seek to form parent-child relationships with the EMS agent 20, agent platforms preferably merge registries with the parent platforms. In this way, every agent becomes visible and accessible with each cluster aggregation. This approach facilitates a central control of the system.

[73] External clients preferably can access the EMS 22 functionality through published services. In the preferred embodiments, the EMS 22 provides an aggregation of TMS 17 behavior across many Theater Management System 17 implementations, with each such TMS 17 aggregating SMS 5 behavior across many different SMS 5 implementations. As shown in Figure 4B, such hierarchically organized behavior preferably allows an external client of the Exhibitor management system 22 to invoke playout 74 for any screen in the entire circuit (i.e., enterprise). The ability to access the target SMS unit 5 preferably proceeds through the agent protocol, because SMS unit 5 interfaces preferably are not be globally published. The TMS units 17 preferably is able to invoke the playout operation 74 by the service oriented architecture supported within the complex.

[74] As shown in Figure 5, the physical structure of agents 40 does not necessarily have to match the physical structure of the hardware topology. In the specific example shown in Figure 5, the EMS agent 20, as well as the TMS agent 60 for one of the TMS 125 is provided within the EMS 22, while the TMS agent 70 for the other TMS 130 is provided within the TMS 130 itself, together with SMS agents 80 and 85 for corresponding SMS units 140 and 145, respectively (TMS units 125 and 130 being examples of a TMS 17, and SMS units 140 and 145 being examples of a SMS 5).

[75] In other words, the agent configurations preferably allow the agents 40 to be placed locally on the same agent platform or remotely on different platforms. Agent functionality typically does not change based on different placements, only the communication modus operandi. In the preferred embodiments of the invention, the agents 40 implement adaptation code to integrate third-party products, and the hierarchical nature of the overall digital cinema platform is realized by the hierarchical arrangement of the agents 40. Recursive Parent-Child Relationship of CMS APIs.

[76] As noted above, the parent-child relationships within the cinema management system preferably allow roll-up and drill-down behavior, such that EMS clients would be able to have as much remote control over the individual projector, for example, as the applicable SMS clients would have locally. The ability to represent that SMS unit, for example, at the high-end exhibitor management system 22 as if one were at the low-end auditorium, gives rise to the "fractal" nature of the system, according to the preferred embodiments. The parent-child relationships preferably replicate the minimum functionality of the child CMS unit to the parent so that the overall architecture is "fractal" in nature.

[77] This "fractal" nature of the system can be expressed thusly. The irreducible element, or the stopping point of the recursion, preferably is the SMS 5. According to the Digital Cinema Initiative (DCI) specs, the show "must always go on". This statement means that the SMS 5 must be completely functional with or without the TMS 17. It requires the SMS 5 to ingest and manage content, to ingest and manage Key Delivery Messages (KDM), to be able to construct show playlists and show schedules, and to validate digital cinema packages, composition playlists, Key Delivery Messages, Show Playlists, Show Schedules, etc. When a TMS 17 is functional and connected to SMS units 5, the TMS 17 preferably will do, or enable its clients to do, all these same things, so that each SMS 5 can be centrally managed. The TMS 17 preferably will do for all SMS units 5 what an individual SMS unit 5 will do for itself. The SMS 5 preferably operates both in an independent and co-dependent fashion. In order for the TMS 17 to be able to fully represent the SMS 5 so that it can be remotely managed, the TMS preferably knows the state ofthe SMS 5.

[78] The relationship between the circuit or Exhibitor Management System (EMS) 22 and the TMS 17 is exactly the same as that between the TMS 17 and the SMS 5. The TMS 17 preferably functions in both an independent and co-dependent relationship with the EMS 22. This means that the ability to turn the projector on and off can happen at the SMS 5, at the TMS 17, or even at the EMS 22 level (secured operations being assumed). In the present embodiments, the API to do this programmatically is the IScreenProjectionService. The ability to find this service and to invoke this operation is managed by the digital cinema platform agents 40, which, as discussed above, preferably in are deployed in hierarchical clusters. [79] This arrangement is depicted as graphically in Figure 6. As shown, the EMS unit 22 incorporates and has access to EMS API 91, TMS API 71 and SMS API 80, i.e., the APIs for EMS unit 22, TMS unit 130 and SMS unit 140, respectively. The TMS unit 130 incorporates and has access to its own TMS API 71, as well as SMS API 80, and the SMS unit 190 incorporates and has access to only its own SMS API 80.

[80] As noted above, e.g., in connection with the discussion of Figure 5, agents do not have to sit on the host/machine in order to fulfill their obligations. The software architecture allows for relocation of components, message forwarding, proxies, etc. What is more, the hierarchy need not be limited to three levels (EMS <-> TMS <-> SMS), but can incorporate many more levels if required. For example, it might be the case that the EMS 22 deals with a regional or country office, which manages the theaters. In addition, or instead, there might be a Network Operations Center (NOC) which maintains SMS units 5 directly. In any event, the rollup of functionality preferably exists for any additional levels of the hierarchy.

[81] The interfaces implemented within the Theater Agent Platform 65 or 75 preferably fulfill industry requirements. As mentioned above, these requirements can originate from distributors (e.g., DCI) and from exhibitors (e.g., NATO). In the preferred embodiments, whenever possible, the SMS API 52 or 72 tries to work with data structures or data types that are SMPTE-defmed. The functional areas covered by these interfaces preferably deal with:

• content management and transfer;

• Key Delivery Messages management and transfer;

• show playlists and show schedules management and transfer;

• screen projection;

• screen operations and software; and

• screen logs

[82] These services preferably can be invoked from different contexts. Service discovery and registration preferably are managed by the agents 40. Service implementations/proxies preferably depend on self-configuring agents 40.

[83] In the present digital cinema model, the parent preferably acquires certain functions/responsibilities of the child. For example, the TMS 17 preferably has the ability to manage content, keys, playlists, show schedules and log files as if it were the SMS 5, but it has the ability to do so for all SMS units 5 in the theater. At the same time, these preferably are not the only functions of the TMS unit 17. For example, the TMS unit 17 preferably also addresses the issue of Point-of-Sale (POS) integration. POS is another unit that preferably has the ability to do playout scheduling.

[84] Similarly, the EMS 22 preferably aggregates the TMSs 17. In the preferred embodiments, the EMS 22 not only acquires SMS rights-protected control through the TMS 17, but it also is responsible for interfacing to distributors, ad aggregators, KDM brokers, etc. The EMS 22 preferably aggregates box office receipts, concession sales, etc.

[85] The rollup of functions and responsibilities starting from the SMS 5, through the TMS 17, up to the EMS 22 and potentially beyond is an important design element. Such a design allows for both scaling up and scaling down. Consider the case when an owner has only a single theater. EMS functionality would still be useful. The fractal insight of the present invention would suggest that the TMS 17 not be built as both TMS and EMS, but that an EMS 22 communicating with a single TMS 17 would be the right design and implementation decision. The degenerative case works efficiently and elegantly because the agent configuration recurses and the APIs remain the same. The same is true for the degenerative TMS case, when there is a single auditorium in the theater. Generally speaking, the "fractal" relationship is based on data flows that become more complex as the data flows from child to parent.

DCP Event Hierarchy.

[86] The CMS units can be comprised of different application software, built on different hosts/machines. Such applications and hardware emit their own events, resulting in a "Tower of Babel" of events. The preferred embodiments of the present invention rationalize this "Tower of Babel" into a unified event hierarchy that is intended to span the functional spectrum of the digital cinema platform. This event hierarchy posits a taxonomy that is considered illustrative of the real world digital cinema platform domain. Preferably, vendor-specific hardware and software events are translated into unified DCP events in the hierarchy for communication among the agents to maintain synchronization of the CMS units and to share and build information for higher-level functionality.

[87] The preferred approach is to extend the Simple Network Management Protocol (SNMP) architecture. First, an event hierarchy, similar to a management information base (MIB), preferably is used for the digital cinema platform as a whole. Second, the messages preferably are both lightweight and application-rich. For this purpose, IBM's Common Base Event architecture, which facilitates both light and heavy- weight events, preferably is adapted for the present use. Third, Web Service Distributed Management (WSDM) technologies preferably are used in order to Web (XML)-enable the data. In other words, the preferred approach is to generalize access to SNMP-based and application data through a high-level event hierarchy available using standard WS- Notification protocols. The preferred structure uses severities and situations in order to minimize the number of event topics.

[88] As used herein, a hierarchical event is an event that is categorized by increasing specialization with respect to the topic or concern of the event. Each event preferably is assigned a mnemonic name (label) using "dot notation". The more parts there are to the name, dot separated, the more specific is the event, given the topic of concern of the preceding parts. Event handlers then are defined for one or more specific events and/or for one or more families of events. A family of events can be expressed as all child events for a parent. This relationship recurses. For example, it would be possible to write an event for a "Key Window Error", e.g., dcp.domain.security.kdm. window, or respond to this event with a generic handler for Key Delivery Message events, i.e., keeping with the present example, dcp.domain.security.kdm. In short, the hierarchy for hierarchical events refers to a taxonomy or classification schema for events. The preferred context is the digital cinema platform as a whole, not just the TMS or SMS units.

[89] As noted above, events preferably are classified in a hierarchical fashion. A portion of such a hierarchical event classification is illustrated in Figure 7. The taxonomic root 220 in the present embodiment is "dcp", which stands for "digital cinema platform". The two first-level branches are "infrastructure" 222 and "domain" 223. The "infrastructure" branch 222 refers to the group of events that can emanate from the dcp- unaware technological components that make up the digital cinema platform. Accordingly, the infrastructure branch 222 typically consists of events generated by generic hardware, software, storage and networking elements. The "domain" branch 223 pertains to dcp-aware components that know of their participation in a digital cinema platform solution. This difference can be illustrated by an example.

[90] Normally, digital players are built on top of commodity boxes, like Dell, Acer, HP, Toshiba, etc. These boxes are configured as general-purpose computing devices, not digital players, and can be used to perform other tasks in other environments. The original equipment manufacturer (OEM) typically installs a Simple Network Management Protocol (SNMP) device (either software or hardware) called a SNMP agent. Using TCP/IP, this agent can emit events or be queried with respect to machine characteristics, e.g. available memory, central processing unit (CPU) usage, CPU temperature, etc. SNMP is an Internet Engineering Task Force (IETF) standard, and it provides a set of protocols, including the structured management of information, for network managed systems.

[91] When a Dell-based player emits a memory error event, it typically will use an event ID/name that is different than that from any other player. It often will do so even if there is a standard ID/name for that event. Every computing device seems to create and adhere to its own "name space" or management information base (MIB). When a digital cinema player wants to emit a digital cinema package retrieval error, it would have to use its own MIB because the underlying computing device's MIB has no notion of what applications are running on the machine. The computing device's MIB generally would not be capable of expressing a digital cinema retrieval error.

[92] The "infrastructure" branch 222 preferably is used to normalize/standardize different MIBs from different computing devices for the digital cinema platform. Hence, adaptation code preferably is provided to translate the Dell event for memory error to the correct dcp infrastructure event. By providing appropriate adaptation code for all different computing devices, the digital cinema platform need only understand dcp. infrastructure. software.os.mem to detect memory faults on any machine in the system, whatever the original manufacturer.

[93] The "domain" branch 223 is a way to classify all digital cinema platform events. These events are emitted by components specifically built to solve the digital cinema platform problem. Whereas "infrastructure" events typically contain sparse, extremely simple information, "domain" events are likely to contain more elaborate information, best expressed in XML. Whereas "infrastructure" events stem from low- level machine elements, "domain" events typically derive from rich contextual environments. The contribution of the event hierarchy primarily is twofold. First, it creates a unified event hierarchy for infrastructure events. Infrastructure events conventionally are emitted by different OEMs using different MIBs - a "Tower of Babel" in a distributed, heterogeneous environment. Second, it brings under one umbrella both infrastructure and domain events. The IETF rejects changing the current SNMP standard to accommodate application events and XML format.

[94] The "infrastructure" branch 222 preferably uses SMPTE terms when creating event branches for hardware elements, e.g., mediaBlock, projector, soundSystem. The "domain" branch preferably subdivides into areas consistent with the SMS API 52 or 72. For example, events embraced by dcp.domain.playout are related to the IScreenProjectionService. As more and more services come on stream, the digital cinema platform event hierarchy can grow correspondingly.

[95] A MIB module is rigorously defined by the SNMP standard. SNMP itself does not define which information (which variables) a managed system should offer. Rather, SNMP uses an extensible design, where the available information is defined by management information bases (MIBs). MIBs describe the structure of the management data of a device subsystem; they use a hierarchical namespace containing object identifiers (OIDs). Roughly speaking, each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by ASN.1 (Abstract Syntax Notation One). The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. The top-level MIB OIDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations. This model permits management across all layers of the OSI reference model, extending into applications such as databases, email, and the Java EE reference model, as MIBs can be defined for all such area- specific information and operations.

[96] The preferred event hierarchy is based on behavioral aspects or operations of the system as a whole. It does not follow the organizational elements of the components. The event preferably states what happened and where. Accordingly, if an error occurs on playout, the event preferably will say playout error, on SMS unit 12, reported by theater ABC. Events preferably are not classified as sms .playout. error, tms .playout. error, ems.playout.error.

[97] There are five major event classes to consider:

• Content (including content transfer)

• Security (including KDMs)

• Scheduling (including show playlists)

• Playout (including automation)

• Operations

[98] The preferred design is based on the IBM Common Business Event model, which facilitates both light and heavy-weight events. The structure preferably uses severities and situations in order to minimize the number of event topics.

[99] The severities preferably include:

• O: Unknown • 10: Information - MUST be used for cases when the event contains only general information and is not reporting an error.

• 20: Harmless - MUST be used for cases in which the error event has no effect on the normal operation of the resource.

• 30: Warning - MUST be used when it is appropriate to let the user decide if an action is needed in response to the event.

• 40: Minor - MUST be used to indicate that action is needed but the situation is not serious at this time.

• 50: Critical - MUST be used to indicate that an immediate action is needed and the scope is broad (perhaps an imminent outage to a critical resource will result).

• 60: Fatal - MUST be used to indicate that an error occurred, but it is too late to take remedial action.

[100] The situations preferably involve: SITUATION TYPE START SITUATION TYPE STOP SITUATION TYPE CONNECT SITUATION TYPE REQUEST SITUATION TYPE CONFIGURE SITUATION TYPE AVAILABLE SITUATION TYPE REPORT SITUATION TYPE CREATE SITUATION TYPE DESTROY SITUATION TYPE FEATURE SITUATION TYPE DEPENDENCY and SITUATION TYPE OTHER

[101] Figure 8 illustrates two different devices 260 and 270 functioning as SMS units 5. The base computing device, and hence the SNMP agent 261, for device 260 has been provided by a manufacturer A, while the base computing device, and hence the SNMP agent 271, for device 270 has been provided by a manufacturer B. SNMP agent 261 emits events 262 using its own MIB, while SNMP agent 271 emits events 272 using a different MIB. Both kinds of events 262 and 272 preferably are translated into the common hierarchy described above by a translation component 280 of the applicable agent (e.g., the attached SMS agent 10 or the upstream TMS agent 15).

[102] Similarly, the application 264 that configures device 260 to function as a SMS unit 5 has been provided by a manufacturer M, while the application 274 that configures device 270 to function as a SMS unit 5 has been provided by a manufacturer N. Application 264 emits events 266 in its own format, while application 274 emits events 276 in its own format. Both kinds of events 266 and 276 preferably are translated into the common hierarchy described above by the translation component 280 of the applicable agent (e.g., the attached SMS agent 10 or the upstream TMS agent 15).

Finite State Machines for Local and Central Control of Agents.

[103] Figure 9 illustrates implementations for and interactions between two agents 300 and 310 (either one of which being, e.g., a SMS agent 10, a TMS agent 15 or an EMS agent 20), according to a representative embodiment of the present invention. Agent 310 is considered semi-autonomous. It can initiate and control independent action by virtue of its own finite-state machine 312, and/or based on local knowledge (e.g., knowledge obtained from the CSM to which it is attached and/or knowledge obtained from another agent, such as agent 300). It can also, however, respond to execution requests from a remote finite-state machine. Agent 300 is an example of a logistics agent that schedules jobs. These jobs (e.g., job 301) have embedded state-based machines (e.g., finite-state machine 302) that function as workflow processors, directing slave agents to perform one or more tasks as part of a multi-step process (e.g., through invoker module 315).

[104] The finite-state machines (FSMs) preferably "listen" for DCP events. If an event occurs that changes the state of the FSM, the corresponding agent preferably "acts" by issuing a DCP event (or other agent communication). When agent(s) are being directed from a central location, the FSMs and event messaging preferably maintains them, or more appropriately the CSM unit(s) attached to the agent(s), in the same state. When one agent/CSM unit acts locally, the DCP event preferably is propagated to synchronize the other CMS units during or immediately following the local action.

Representative System Architectures for TMS and SMS Integration.

[105] Figure 10 illustrates an example of a software architecture based on services, software agents and messaging for the TMS-SMS platform. These three elements of distributed computing have existing implementations upon which to draw. The purpose of this section is to discuss how these implementations can be used to best effect in order to solve the TMS-SMS integration problem. In the present example, the TMS agent 15 (implementing functionality such as content management, content movement, playlist composition, scheduling, key management, logging, monitoring of network and equipment, problem escalation, reporting, maintenance of site information, user management and security) is hosted on the theater management system 17, and the SMS agent 10 (implementing functionality such as screen content service, screen management service, screen validation service, screen projection service, screen schedule service, screen operation service and screen log service) is hosted on the screen management system 5.

[106] One design element for addressing the TMS and SMS integration problem is the software agent. A software agent is nothing more than a background process running on a host. In the present case, each agent preferably implements platform-specific implementations of behaviors that are to be fulfilled in order for the SMSs and TMS to function in a theater complex. These behaviors preferably are defined by a contract, i.e., a set of service interfaces and events that are secure and readily accessible through different technologies.

Service Invocation

[107] It is possible for the TMS 17 to access SMS 5 services in any number of different ways, three of which being illustrated in Figure 10. The availability of choice abets various integration issues, but might also lead to confusion.

[108] The agent platform 43 preferably is based on the Foundation of Intelligent Physical Agents (FIPA) standard. It provides a messaging protocol whereby message payloads can be included in the body of a message as Multipurpose Internet Mail Extensions (MIME) attachments, thereby providing the ability for direct agent-to-agent collaboration messages 340. A TMS 17 without a FIPA-compliant agent platform 43, however, typically will find this message protocol cumbersome to use. There is a provision in the FIPA standard that allows direct agent-to-agent communications to negotiate and use alternative wire and message protocols. The FIPA implementation according to be preferred embodiment of the present invention allows for this.

[109] MOM communications 350 preferably are used for event notifications from the MOM client 352 of the SMS agent 10 to the MOM server 354 (maintaining a plurality of message 380 queues 355), which then communicates such messages to the TMS agent 15. Although MOM communications 350 can be used for request-response message exchanges, to do so would not be an effective use of this technology. MOM is intended for asynchronous communication.

[110] It seems likely that most TMS implementations will want to interact with a SMS using simple, direct wire and message protocols. Today, this is plain old XML (POX) over HTTP, where the XML is defined by published XML Schema. While easy to use, this type of communication lacks formalism. The lack of semantics is quite manageable in relatively simple environments. However, for complex environments, where security, transactions, sessions, reliable messaging, quality of service are issues, a machine understandable expression of semantics is required.

[Ill] A service-oriented architecture 42 is designed for interoperability; it decouples the service implementation from service invocation, allows the service invocation mechanism to support multiple bindings and enables service consumers and producers to interact on agreed-upon protocols and quality of service attributes at runtime. A service-oriented architecture 42 accommodates formalism as complexity increases. When HTTP/POX is not sufficient and a formal expression of semantics is required, the SOA approach enables both the TMS 17 and the SMS 5 to include support 42 for HTTP/SOAP and the Web Services stack.

Service Location

[112] The Web Services stack is a set of technology-agnostic protocols. A service-oriented architecture instructs as to the proper application of the protocols. One of the issues addressed by a SOA is the registration and discovery of services. How is the TMS 17 supposed to find SMS 5 service end points and how will the TMS 17 know what communication protocols to use? A service-oriented architecture mandates service registration and discovery using lookup or registration services at previously defined locations. However, service registration and discovery might not be the best approach in the current implementation. Consider a theater complex with twenty auditoriums. Each SMS 5 would register an identical interface with the TMS 17. In order for the TMS 17 to know which SMS 5 to use, it would need unique identifying information, like screen name. When a SMS unit 5 is not available, the TMS 17 cannot replace needed functionality from one SMS 5 with a similar invocation on another SMS unit 5. [113] The TMS 17 and SMS 5 connection preferably is a whole-part relationship. More preferably, it is a "fractal" of the digital cinema platform. This means at certain points in the architecture hierarchically organized units contribute in unison to fulfilling a required functionality. Within a fractal, service registration and discovery can and should occur by other means. In the present agent-based implementation, the agents 40 register with a parent agent 40 and an agent platform is used to resolve the path for agent-to-agent communication.

[114] Because there generally is no way to guarantee that a TMS 17 will implement an agent platform, the simplest solution would be to have the TMS 17 configured with the IP addresses of all SMS agents 10 in the theater complex. An alternative would be to require that TMS 17 and SMS 5 implementations register and discover one another using multicast protocols on the network. The SMS agent 10 on the digital cinema player 360 is configured to implement this form of service publishing in certain embodiments of the invention.

Service Usage

[115] By whatever means used by the TMS 17 to discover the SMS agent 10, there still remains the question of what communication protocols to use. Normally, this information can be found at some well-known location on the host that is supporting the SMS agent 10. It is widely accepted practice to use Web Services Description Language (WSDL) and WS-Policy to formally describe services and their capabilities. Because some TMS implementations might not be able to support W3C protocols, convention typically requires that all SMS implementations minimally support HTTP/POX access using a common message format. This would allow less sophisticated TMS implementations 17 to start accessing the SMS 5 as soon as the IP address and port are known. The ability to support both simple and more elaborate protocols not only enhances interoperability but provides for differentiating "quality of service" implementations.

SNMP Support

[116] In the preferred embodiments, one functional requirement of the TMS 17 is to monitor network and equipment health. The Simple Network Management Protocol (SNMP), defined by an Internet Engineering Task Force (IETF), is the standard way to get such information. A great deal of device information can be obtained by the TMS through SNMP without requiring SMS implementations to intervene. [117] SNMP information shares the same underlying structure but has meaning defined by management information base (MIB) modules. This information is organized by a global system of object identifiers, allowing for both public and private namespaces. Unfortunately, more often than not, device manufacturers choose to define events as private when it might have been more beneficial to map them to public identifiers. This places the burden on the event consumer, e.g., the TMS 17 or an agent 40 (such as the SMS agent 10 or the TMS agent 15) to reconcile common but privately identified events, e.g., by translating into a common event hierarchy, as discussed above.

[118] In the illustrated embodiment, such SNMP events 370 are issued by the digital cinema player's SNMP agent 372 to the SNMP manager 375 for the TMS agent 15, or the SNMP manager 375 for the TMS agent 15 retrieves SNMP information 370 from logs generated by SNMP agent 372, depending upon the functionality provided in SNMP agent 372. In either case, the TMS agent 15 preferably translates such SNMP information 370 into the common event hierarchy discussed above.

Event Notification

[119] One issue is the approach to be used for sending SMS application events to the TMS 17. SNMP was not intended to address this issue. The current messaging structure of SNMP is not sufficient to handle error information normally associated with complex applications (e.g., trace stacks). An IETF proposal to move from the current messaging format to XML is unlikely to proceed due to resistance from device manufacturers.

[120] The simplest way for events to get to the TMS 17 from the SMS 5 is for the TMS 17 (or an agent 40) to call a SMS service periodically. However, if the TMS 17 is required to get relatively real-time input on what is happening on the SMS 5, the TMS 17 would have to poll frequently. Unfortunately, intensive polling by a TMS 17 in a theater complex with many SMS units 5 is not an efficient solution. A better approach is to have the TMS 17 listening for events emitted by the SMS 5. Here is one example of where the SMS agent 10 can provide upward adaptability. A SMS agent 10 can take digital cinema player events and forward these events to the TMS 17 (e.g., by way of the TMS agent 15); this preferably works exactly like, or very similar to, SNMP.

[121] One way to hide the many possible ways to notify various TMS implementations is through a notification service abstraction. Such an abstraction, WS- Notification, is provided by the Web Services Distributed Management (WSDM) technical committee. WS-Notification is a technology-agnostic description of essential message- oriented middleware functionality. As such, it provides clear semantics for both event producers and consumers. Unfortunately, WS -Notification is of sufficient complexity that an implementation presupposes message-oriented middleware support.

Common Event Format

[122] Just like the SNMP situation where different device manufacturers ignore public object identifiers in favor of privately defined events, SMS implementations can emit application events in any message format it wants, thereby putting the burden of adaptation on TMS implementations. This problem could be greatly alleviated if a common event hierarchy and message format could be agreed upon, similar to SNMP. It preferably then would be the responsibility of the SMS device agent 10 to map internal SMS implementation events to a public common protocol.

[123] The Web Services Distributed Management committee is proposing an event format (WEF) that is based on IBM's Common Base Event model for consistent notification messages. This model can facilitate both lightweight event notification and the aggregation of events by event manager or problem escalation subsystems. These subsystems, which use rule or learning technologies to filter and interpret a stream of events, are needed to reduce the volume of events which flood both network and human bandwidth.

Content Movement

[124] One additional point of interoperability concerns the delivery of content. This facet of operation preferably is governed by the Message Dispatch Protocol (MDP) defined by SMPTE. Although still a candidate proposal, it is a clever and useful protocol right out of the box.

[125] An external request to move content to a SMS unit 5 preferably would not be directly sent to the device agent 10 representing the SMS 5, but would be directed to the system's Logistics Agent. The Logistics Agent preferably is the central dispatch unit that schedules and monitors the transfer of digital content to all screens, optimizing scarce network resources and ensuring guaranteed delivery prior to the first date in the performance schedule. The Logistics Agent is an example of an "unattached" agent that uses shared knowledge to provide higher-level functionality. The Logistics Agent would then forward the request to the Theater Agent 15, rather than the Device Agent 10. The theater topology preferably is known to the Logistics Agent. The content transfer request to the Theater Agent 15 preferably contains an optimized set of content locations for files to be transferred. The Logistics Agent stacks the request to the Theater Agent 15 if a content transfer is currently in progress for the theater site. This is important for reducing contention at gated access points connecting external and internal networks. The Theater Agent 15 then checks to see if the content is locally present and available (e.g., from a previous download request). If not, the Theater Agent 15 forwards the request to the Content Agent (another unattached agent) sitting on the platform in the theater local network. The Content Agent pulls down the content, using SMPTE 's Dispatch Media Protocol. Once complete, the Content Agent notifies the Theater Agent 15, which then instructs the Device Agent 10 to get the content 378 from the Theater's local content server 380. When the Device Agent 10 has finished fetching the content, it notifies the Theater Agent 15, which then notifies the Logistic Agent.

[126] Each transfer request preferably is managed as a scheduled job. This approach allows requests to be suspended with a scheduled time for resumption. Such suspension is desirable when attempting to prioritize requests with limited resources. More importantly, since transfer requests for extremely large files can take many hours, if not days, the transfer request job can be rescheduled for purposes of monitoring the download process, in the face of missing events or information. The management of the download process is implemented by a Finite State Machine. Such automatons are preprogrammed to react to input events associated with content transfers and other multi-step tasks.

TMS Partitioning

[127] One proposed design variation posits that a TMS 17 should be partitioned into services and application areas. The application area is termed a Theater Business Management System (TBMS). It has been suggested that the TBMS, which would be on a completely different subnet, have its own database. This implies two things. First, there is the hint that core TMS functionality can be refined. Second, TMS partitioning is yet another argument for an architecture based on services, agents and messages.

[128] Another design variation more in keeping with E-Cinema than D-Cinema proposes a network of SMS units 5 without a TMS 17 at the theater site. The SMS units 5 in such a case would be managed by an exhibition management system (EMS) 22 at a central location. This possibility is yet another argument for a highly interoperable distributed computing software architecture.

Additional Agent Functionality.

[129] As described in detail throughout this disclosure, the architecture of the present invention preferably involves attachment of agents 40 to various CMSs within a Digital Cinema platform. In the preferred embodiments, the agents 40 are arranged hierarchically, mirroring the hierarchical arrangement of the CMS units themselves.

[130] The actual manner of attachment can be performed in any of a variety of different ways, so that the agents 40 are able to access information from (or listen to events occurring within) the CMSs to which they are attached. At the same time, the agents 40 preferably are listening for events issued by other agents 40 within the system. In the various embodiments of the invention, the agents 40 can be provided in any of a variety of different locations, in some cases merging two or more agents 40 into a single processing module and/or merging one or more agents 40 into an application.

[131] Using this agent structure, a system according to the present invention is able to manage and propagate information more efficiently throughout the various CMS components. The resulting platform allows designers and/or users to customize the system in order to best manage data and workflows throughout a theater, and enterprise or beyond. For instance, such designers and/or users can have the ability to manage what information (including state information) is to be made available (i.e., required to be communicated) and when.

[132] In addition, the agents 40 can be configured so as to appropriately react to different network conditions. Examples include filtering messages that are no longer relevant by the time they are capable of being delivered (earlier delivery having been precluded due to network or device problems, or due to network congestion); and self- healing, which can include routing messages intelligently, a TMS agent 15 (or other higher-level agent) taking actions to fix problems that have been communicated from an SMS agent 10 (or other lower-level agent) without the necessity of escalating the problem when it is possible to do correct the problem locally. More specific examples include: determining that it is not necessary to download content when a copy of the required content is located on another device within the theater, or alerting local personnel to attempt to resolve a problem before escalating it. The individual agents 40 preferably are user-configurable for the purposes of directing and prioritizing information flows and responding to identified problems.

Interfaces.

[133] The present section formally describes a representative set of behaviors for the screen management system. A programming contract is comprised of interfaces, events and exceptions. It is not only about information exchange, but also about correct behavior taking place when part of the contract is invoked. To simplify matters, define an application programming interface (API) to be equivalent to a programming contract and permit either term to be used in a technology-agnostic manner. From this point forward, little or no reference will be made to implementation concerns and particular technologies.

[134] It is possible to describe a programming contract in many ways. Below, Java is used as a succinct representation. Normally, public interfaces would be published using WSDL. It is assumed that an equivalence mapping can be found between different representations.

[135] A programming contract should first and foremost provide clear and concise meaning. The clearer the intent of the interfaces, the less room there is for ambiguity and error. Good interfaces are sufficiently detailed to be emblematic of the problem domain, but not so detailed to be easily susceptible to change. In addition, a good interface will exhibit a high degree of cohesion, meaning that interface operations and data are strongly associated. This usually happens when an interface focuses on a clear, singular concept or purpose in the problem domain.

[136] One part of an interface contract is the ability of the implementation to convey to the client whether it was able to execute the terms of the contract. This is usually done through a return code or an exception. This part of the interface definitions is deferred until agreement can be found on the larger abstractions.

[137] Since the TMS and SMS share quite a bit of overlapping functionality, some interfaces are likely to be implemented by both the TMS 17 and SMS 5. However, it is not the present focus to describe an API that purposefully spans both TMS 17 and SMS 5. The interfaces described below generally can be implemented by either or both of TMS 17 and SMS 5. IContentTransferService

[138] This interface defines a pull model for movement of content files from a source (content server, such as content server 380) to the SMS unit 5. It can also support content movement from external content servers to the central server at the theater.

[139] The contract design is biased towards the Message Dispatch Protocol defined by SMPTE, and the pull model in particular. The prepareToDownload method corresponds to the initiation and negotiation protocol of the standard. The download process is required to emit progress and failure events which will eventually be transmitted to the initiator of the download and whoever else might be interested. The getDownloadStatus is used as a way to get the current state of the download at any time. When told to either pause or stop a download process, the SMS is required to provide a summary of its progress. This is represented by a TransferManifest.

public interface IContentTransferService { public TransferCapabilities getTransferCapabilities(); public int prepareToTransfer(TransferManifest manifest); public int startTransfer(TransferManifest manifest); public TransferManifest getTransferStatus(); public TransferManifest pauseTransfer(); public int resumeTransfer(); public TransferManifest stopTransfer();

}

[140] The interface definition above, utilizing the TransferCapabilities document, should be able to subsume both content ingest and streaming. The TransferManifest will describe what to download, how and from where.

IContentManagementService

[141] The purpose of this service contract is to support the management of content and its attendant metadata. It is assumed that all content will be packaged and described according to SMPTE standards. These standards provide considerable flexibility with respect to packaging. However, complexity is the handmaiden of flexibility. This poses some challenges for content management. [142] The composition playlist (CPL) is the means by which content is played; the digital cinema package is the means by which content is transported. The former is primarily a user artifact, the latter a machine artifact. The content management service preferably supports these two fundamental and inextricably linked perspectives on media content.

[143] In the preferred embodiments, the service provides at the very least methods to be able query the SMS for content. Normally, content deletion is considered the responsibility of the SMS 5. This process coincides with the expiry of KDM keys. Because the KDM is always assigned to a CPL, this implies that deletion takes place along a CPL axis, not a DCP axis. This process of deletion is non-trivial. "A DCP may or may not contain all the content (essence or metadata) necessary to play back a particular movie or trailer", implying that a composition playlist can refer to media essences that span more than one DCP. It can also be the case that one media essence can be referenced by many composition playlists. A basic algorithm for content deletion would require that content deletion only occur when a media asset no longer is being referenced. The deletion of content as a result of KDM expiration is a form of garbage collection, i.e., expired content cannot be played, making all existing references to content invalid.

[144] It can sometimes be the case, due to ambiguous or unintended situations, that content needs to be deleted prior to the expiration of the KDM keys for a CPL. Although one could possibly manipulate KDM keys in order to affect a garbage collection cleanup, this approach would not be advisable. Consequently, it is desirable to have two operations to help with manage content. The first allows content to be deleted along the CPL axis. Here, the service implementation should decide what is to be done once the client has specified what CPLs to delete. The second operation, purge, is similar to the invocation of a garbage collection. The service implementation is told to remove all non- referenced content.

public interface IContentManagementService { public boolean hasContent(UUID cplld); public void deleteContent(List<UUID> cpllds); public CompositionPlaylist getCompositionPlaylist(UUID cplld); public CompositionPlayList[] getCompositionPlayLists(UUID pklld); public UUID [] getAUPackingLists() public void purgeQ; }

IKeyTransferService

[145] KDM keys are the security counterparts to playable content. Because security artifacts are managed differently than secured artifacts, security and content are treated as separate concerns. Like content management, the issues surrounding the transfer or movement of KDM keys are quite orthogonal to the management of keys, once transfer has taken place. By keeping these two aspects separate, it is possible to create simpler and more generic service interfaces.

[146] The formalization of a KDM transfer is a current SMPTE topic, investigating various use case scenarios defining numerous pull, push and pull/push models. The actors involved, depending on the use case, can include:

• KDM Provider

• KDM Broker

• NOC

• Exhibitor Central Office

• Theater Complex

• Screen Media Block

[147] At a minimum, a key transfer service interface preferably supports a push model. All SMPTE use cases require that a signed receipt be sent back to the issuer of the KDM. In general, this message could be called synchronously. However, asynchronous messaging could also take place should KDM forwarding be required. This would depend on the use case and its realization.

public interface IKeyTransferService { public KDMReceipt load(KDM kdm);

}

[148] It is noted that there is a late proposal to transfer a bundle of keys in order to enable efficiencies. However, this proposal does not define how signed key receipt for a bundle should be managed.

IKeyManagementService

[149] It appears that each of the actors involved in the flow of KDM keys have a management responsibility of some sort. A large part of this responsibility can be encapsulated by a simple key management service interface. This interface could have many implementations or a single implementation that can be relocated to the various actor locations.

[150] A KDM has two associations: composition playlist and recipient. The composition playlist association allows the client to query for all KDM keys for a CPL. A list rather than a single KDM is returned since it is possible for a CPL to have KDM keys which span time over intervals. Likewise, the recipient association enables the client to find all KDMs for a particular recipient. If the implementer of this service is a SMS unit, the result preferably will always be an empty list if the recipient argument is not the SMS itself. Given the possible filters that could be applied to KDM selection, the service contract provides a generic find method based on a query. The KDMQuery object consists of "and" constraints, referencing start and end dates of the KDM, recipient and composition playlist identifier.

[151] When a KDM expires, the service is expected to generate an event. Some implementations might be clever enough to generate events some time interval before the actual expiry date. All the same, the getExpiringKDMs method preferably will return all expired and will have expired KDMs within an interval bounded by inclusive dates.

public interface IKeyManagementService { public KDM getKDM(UUID kdmld); public KDMQueryResult fϊndKDMs(KDMQuery query); public void removeKDM(UUID kdmld); public UUID[] getAUKDMs(); public UUID[] getExpiringKDMs(Date startDate, Date endDate); public KDM [] getKDMsByRecipient(KDMRecipient recipient);

}

[152] Services involved with KDM keys should be secure. Hence, the invocation of each operation preferably authenticates the caller and ensures that the caller is authorized for the operation.

IScreen ValidationService

[153] This service requires that the SMS unit be able to validate the whole and the parts of correct digital playout. The primary reason for this service is that, although content ingest is normally accompanied with validation, full validation cannot take place until all parts are in place. For example, it would not be possible to test the playability of content if the KDM keys are not accessible. It would not be possible to test the playability of the schedule without the show playlist, and so on. Hence, at some point in time, there preferably is a way to invoke full validation. Another problem that this service is designed to alleviate is KDM expiration and renewal. KDM expiration represents a SMS state change which can prohibit content from playing.

[154] The validation service contract focuses on validation dependencies. The validateCompositionPlaylist method, for example, is responsible for not only validating the CPL syntax, structure and presence of playable assets, but also the existence of KDM keys which enable asset decryption. The validateShowPlaylist performs a set of validations on each composition playlist referenced. The validateSchedule will do recursive validation on the show playlist, but will validate the KDM expiry date against the schedule dates. With these operations, parts of the playout content and instructions can replaced and playout capabilities incrementally validated.

[155] When content and commensurate metadata has been placed on the SMS, normal procedure is to physically check the playout of a movie by human observation. A testPlayBack function is not meant to replace this procedure, at least not for now. The testPlayBack function provides a state check for content that might be played some interval before a projection, where alternative content or replacement hardware can be installed just in time for public exhibition. Because the testPlayBack operation is likely to take some time, this operation preferably emits progress events.

public interface IScreenValidationService() { public void testPlayBack(UUID splld); public ValidationManifest validateShowPlaylist(UUID splld); public ValidationManifest validateCompositionPlaylist(UUID cplld); public ValidationManifest validateKDM(UUID kdmld); public ValidationManifest validateSchedule(UUID scheduleld);

} The ValidationManifest provides a report on the validation procedure invoked. IScreenProjectionService

[156] The screen projection service contract pertains to playout control. It provides the client with the ability to start, pause, resume, and stop the exhibition of content.

[157] The "prepare" operation signals the SMS unit 5 that this show playlist should be played next. If the argument is null, then the SMS 5 should prepare the next scheduled playlist. The purpose of this operation is to ensure that the SMS player is in a proper state for playback.

[158] Sometimes, it might be necessary to delay the time of play due to weather conditions. If this is necessary, the TMS system 17 preferably submits a revised schedule to the SMS unit 5. The schedule will be able to signal delay on either a single performance or on all remaining performances for the day.

[159] The SMS 5 is responsible for emitting playback events. However, the interface also provides the possibility to obtain a playout manifest. This will indicate what is playing, what has played, i.e. the timeline of an executing show playlist.

[160] For the case of recovery from a catastrophic failure (e.g. power outage), the SMS 5 preferably also provides a capability for the resumption of play at the point of failure.

public interface IScreenProjectionService { public int prepare(UUID playlistld); public int play(UUID playlistID); public int pause(); public int resume(); public int restartAtPointOfFailure(); public int stop(); public PlayoutManifest getPlayoutStatus(); }

IScreenScheduleService

[161] This service is responsible for the management of SMPTE-compliant show playlists and schedules. Given the nature of the contract and its types, this service can be implemented by units other than the screen management system. The show playlist always refers to what is to be played, independent of location and time. The show schedule preferably will specify the full "what, where and when" relationships. Hence, whereas a TMS implementation will be able to accept schedules for screens within the theater complex, a SMS implementation of the service will be able to restrict the loading of a schedule specific to itself.

[162] The screen schedule service provides one method for querying for show playlists, and another for querying schedules. The SPLQuery facilitates queries based on content alone. The SSCHQuery is more expressive, given the "what, where and when" relationships.

[163] Last but not least, this service contract provides external clients with the ability to load, modify and delete show playlists and schedules. Show playlists and schedules preferably can be manipulated by various systems in and out of the theater complex.

public interface IScreenScheduleService() { public SPLQueryResult fmdShowPlaylists(SPLQuery query); public ShowPlaylist getPlayList(UUID playlistld); public void removePlaylist(UUID playlistld); public void loadPlaylist(ShowPlaylist playlist); public void loadSchedule(ShowSchedule schedule); public void load(ShowPlaylist playlist, ShowSchedule schedule); public SSCHQueryResult fϊndShowSchedules(SSCHQuery query); public ShowSchedule getShowSchedule(UUID scheduleld); public void removeShowSchedule(UUID scheduleld);

}

The SMS 5 preferably is responsible for generating an event when a new playlist or schedule has been introduced into the system.

IScreenOperationService

[164] This interface concerns operational and maintenance issues that relate to SMS equipment. One of the operations is the request for a SMPTE-compliant device description. The device description is useful for helping the system to achieve self- managing properties. Another property of a SMS unit 5 is its certificate chain. The certificate chain plays a key role in the construction of a Facility List Message (FLM). Facility List Messages are used for the allocation and assignment of KDMs for digital playout.

[165] The getOperationalStatus method will provide an operations manifest. It will detail the current mode of the device, unexpected state changes affecting operation, the current software version, etc. The doSelfCheck method causes the equipment to run through a series of tests and possibly do some repair. Equipment checks will vary from one digital cinema player to another.

[166] One operational feature preferably is the ability to do software upgrades remotely, and if a software upgrade is found faulty, to revert to the previous version. This facility is particularly valuable within an environment where the deployment of digital players can be in the thousands.

[167] The setProperties method provides a rudimentary way to configure the device remotely. A more elaborate configuration scheme could require the introduction of an IScreenConfigurationService interface.

public interface IScreenOperationService { public void reboot(); public OperationTest doSelfCheck(); public OperationsManifest getOperationalStatus(); public DeviceDescription getDeviceDesciption(); public CertificateChain getCertificateChain(); public void updateSoftware(URL url); public void revertSoftwareUpgrade(); public void setProperties(DeviceProperties properties); }

IScreenLogService

[168] This service interface allows access to SMS log records. Indeed, the API is sufficiently generic that it could apply to other subsystems in the theater complex as well. Given the potential volume of log records, and the necessity to collect only what is needed, the interface defines a batch- like protocol to obtaining chunks of pre-selected, pre- filtered log records. [169] In order to obtain a batch of log records in manageable portions, the getLogBatch operation preferably is first invoked. The LogBatchQuery argument allows the client to describe a batch of records according to event class/type, start date, end date, regular expressions, etc. The result, which is a LogBatch object, can then be used to fetch prepared records in bundles via the getLogRecords method. The LogBatchResult will not only contain SMPTE-compliant log records but an updated LogBatch object as well. The use of an updated LogBatch alleviates the need to keep state in the service implementation. The client repeatedly calls getLogRecords with the updated LogBatch argument until all records in the batch have been read.

[170] The purpose of the getLoggingStatus operation is to ensure that logging is functioning correctly. Such information in the LogManifest could also help maintenance efforts, since a malfunctioning digital player might generate millions of log records, causing resource problems. The SMS 5 preferably is responsible for managing its log files. Its management policy, however, could be configured through the setProperties method in the IScreenOperationService interface.

public interface IScreenLogService { public LogBatch getLogBatch(LogBatchQuery query); public LogBatchResult getLogRecords(LogBatch logBatch); public LogManifest getLoggingStatus();

}

Events.

[171] Part of an API or programming contract can be expressed by events. The discussion on interfaces above often alluded to application events being emitted by the SMS 5. A small number of SMPTE specifications make reference to event classes and subtypes. The SMPTE specification for secure logging in particular is helpful, but only to a limited extent. Logging does not fulfill the requirements of an event-driven system. Logging is used for recording and auditing what happened; events cause things to happen.

[172] In the preferred embodiments, the relationship between the TMS 17 and the SMS 5 is based on both co-dependence and independence. In order to adhere to the DCI dictum that "the show must always go on", the SMS 5 is empowered to do things that might normally be assigned to a TMS 17. Whether the network is up or down, content and keys preferably can be loaded onto the SMS 5 via hardware ports, without TMS 17 supervision. Playlists and schedules preferably can be constructed on the SMS 5, again without TMS 17 involvement. This is a difficult relationship. Without events, it will be hard for any TMS 17 to know what is really taking place on the SMS 5. Without this knowledge, the TMS 17 cannot fulfill basic SMS 5 integration functionality. In short, events are important to how the TMS 17 and the SMS 5 cooperate.

[173] For management purposes, events are classified into classes or categories. There are five major event classes to consider:

• Content (including content transfer)

• Security (including KDMs)

• Scheduling (including show playlists)

• Playout (including automation)

• Operations

[174] The design of an event-based system has to take into account many factors. Lightweight events are important for process signaling. However, many event-driven systems are bound by high-latency networks. In such an environment, few events with high information payloads generally are better than many events with low information payloads. Hence, an event-based architecture preferably has both the ability to enable high-performance event processing and add appropriate, incremental context information for event aggregation and propagation.

[175] The Common Base Event model from IBM is one event format that facilitates both lightweight and heavyweight events. Events can be:

• described with metadata

• complemented with context data

• elaborated with extended data

• aggregated by association engines

• connected to source components

• processed by reporting components

• categorized by situations

[176] The common base event model, such as that from IBM, is important because it represents a formulation that can be used to define an event-based architecture. A definition of clear semantics in an increasingly formal and consistent way is a prerequisite for event programming. This is evident, for example, in the classification of situation types. [177] Event classification, like other expressions of metadata, normally would not be present inside the event. Late-binding preferably is used to keep the event payload as lightweight and as a flexible as possible. To facilitate late binding, every message preferably has a message identifier that will connect the message to its metadata.

[178] In the various embodiments of the present invention, the following events can be generated by any of these CMS units, typically through their respective agents 40, and transmitted to one or more other CMS units, again typically through their respective agents 40. Such events can be generated, e.g., by monitoring logs created by the CMS unit. In addition, where the underlying CMS unit generates an event, an agent according to the present invention typically will be used to translate the event into the common event hierarchy discussed above.

Content Events

[179] This event class of events pertains to content movement and management. With respect to content movement, there are three different ways in which content can be placed on a machine:

• Content ingest: transfer through direct physical connection to the device

• Content transfer: remote transfer of content from a secure content server

• Content upload: remote upload of content by an external client

[180] The DCP Received event describes how the DCP was received. This information allows the system to take whatever steps are necessary to maintain consistent state.

• DCP Retrieval Starting - retrieval process started

• DCP Retrieval Progress - retrieval in progress

• DCP Retrieval Suspended - retrieval suspended

• DCP Retrieval Resumed - retrieval resumed

• DCP Retrieval Stopped - retrieval stopped

• DCP Retrieval Finished - retrieval successfully finished

• DCP Received - package received and validated

• DCP Deleted - package deleted

• DCP Format Error - packaging does not mean normative requirements

• Asset Missing Error - asset referenced in a CPL was not found

• Content Format Error - content not playable on device • Composition Playlist Missing - composition playlist not found

• Composition Playlist Check - composition playlist validates

• Composition Playlist Format Error - normative language requirements not met

Security Events

[181] This event class deals with security notifications, including KDM distribution and management. The KDM Received event preferably describes how the KDM was obtained, in order to allow subsystems the opportunity to perform synchronization tasks. Similarly, the KDM Deleted event preferably identifies the source of deletion. Security events dealing with encryption/decryption based on KDM keys are also incorporated.

• KDM Received - KDM received and validated

• KDM Expired - KDM has expired

• KDM Deleted - KDM removed prior to expiry

• KDM Format Error - normative language requirements not met

• KDM Missing Error - CPL/KDM pair missing

• KDM Check - CPL/KDM pair confirmed

• Key Type Error - a KDM supplied a key of the wrong Key Type for a track file

• KDM Window Error - decryption failed due to an attempt to use a KDM outside of its validity window.

• TDL Error - at least one downstream device from a media block did not appear on the TDL of the KDM that was used to decrypt content.

• Content Authenticator Error - Signer of a CPL does not match the Content Authenticator of a KDM that enables that CPL.

• Certificate Format Error - the Signer Certificate of the referenced object did not meet the normative language of SMPTE 430-2

• Signature Error - the digital signature of the referenced object did not validate.

• Asset Hash Error - computed hash of one of the assets referenced by the CPL did not match the value recorded in the optional Hash element of the Asset element of the CPL.

• Check Value Error - at least one Check Value within a range of frames processed did not match the Check Value specified in [TFE] Table 11.

• Frame Integrity Error - MIC check failed on one or more frames of a track file Scheduling Events

[182] This event class describes notifications associated with show playlists and schedules. These events must include the source of the action, since this will allow the TMS to act appropriately when playlists and schedules are changed by the SMS or any other subsystem in the theater complex.

• Show Playlist Received - received and validated

• Show Playlist Deleted - playlist deleted

• Show Playlist Format Error - normative language requirements not met

• Show Playlist Missing - show playlist not found

• Show Playlist Check - show playlist is valid

• Show Schedule Received - received and validated

• Show Schedule Deleted - show schedule deleted

• Show Schedule Format Error - normative language requirements not met

• Show Schedule Missing - schedule missing

• Show Schedule Check - show schedule is valid

Playout Events

[183] This event class pertains to the playout of a composition playlist. The CPL represents a unified body of exhibition content, such as a feature film or trailer. Ordinarily, when content has been received by the SMS, standard procedure required that the content be audited by human observation. Given the ease with which content, keys, playlists and schedules can be moved and changed, human verification instead of automated testing of playable content becomes increasingly cumbersome. Test playout events bracket the SMS-specific process that ensures correct content playability.

• CPL Start - the first edit unit of the Main Picture asset of the first reel of a target CPL has been played by a device

• CPL End - the last edit unit of the Main Picture asset of the last Reel of a target CPL has been played by a device

• CPL Pause - the edit unit of the Reel where pause was invoked

• CPL Resumed - the edit unit of the Reel where resume was invoked

• CPL Stopped - the edit unit of the Reel where stopped was invoked

• CPL Restarted At Point of Failure - the edit unit of the Reel where restart was invoked • CPL Playout Complete - the target CPL has been played without interruption of exception by a device

• Frame Sequence Played - a specified sequence of frames from a track file has been played

• Test Playout Started - start test of next scheduled CPL playout

• Test Playout Stopped - stop playout test

• Test Playout Finished - test playout finished

Operational Events

[184] This category of events describes notifications related to operation and maintenance issues. In general, these events should indicate the event source. The SMS Startup event should include whether the system was shutdown normally or was the result of a catastrophic error.

• SMS Shutdown - SMS Unit is shutting down

• SMS Startup - SMS Unit is starting up

• SMS Clock Adjust - the time of a secure clock within an SPB was adjusted.

• Unexpected State Change - ability to tell if the device changed state at an unexpected time

• Log Transfer - a device has transferred a log record or records to another device

• Log Overflow - logging service in danger of losing events

• Low Disk Space - some SMS operations might not complete

• Device Not Found - indicates that a device was unable to locate another device.

• Link Opened - an ASM link has been opened between two devices

• Link Closed - an ASM link between two devices has been closed

• Link Exception - an exception occurred on an open ASM link

• Software Upgrade - SMS software upgrade

• Software Failure - replacement of software failed

• Software Regress - revert to previous software version

• Equipment Check Invoked - self test method started

• Equipment Check Failed - self test method failed

• Equipment Check Passed - self test method passed

• Unknown Error - unspecified error occurred If automation events are required, they could be categorized either as operational or playout.

System Environment.

[185] Generally speaking, except where clearly indicated otherwise, all of the systems, methods and techniques described herein can be practiced with the use of one or more programmable general-purpose computing devices. Such devices typically will include, for example, at least some of the following components interconnected with each other, e.g., via a common bus: one or more central processing units (CPUs); read-only memory (ROM); random access memory (RAM); input/output software and circuitry for interfacing with other devices (e.g., using a hardwired connection, such as a serial port, a parallel port, a USB connection or a firewire connection, or using a wireless protocol, such as Bluetooth or a 802.11 protocol); software and circuitry for connecting to one or more networks, e.g., using a hardwired connection such as an Ethernet card or a wireless protocol, such as code division multiple access (CDMA), global system for mobile communications (GSM), Bluetooth, a 802.11 protocol, or any other cellular-based or non- cellular-based system, which networks, in turn, in many embodiments of the invention, connect to the Internet or to any other networks; a display (such as a cathode ray tube display, a liquid crystal display, an organic light-emitting display, a polymeric light- emitting display or any other thin-film display); other output devices (such as one or more speakers, a headphone set and a printer); one or more input devices (such as a mouse, touchpad, tablet, touch-sensitive display or other pointing device, a keyboard, a keypad, a microphone and a scanner); a mass storage unit (such as a hard disk drive); a real-time clock; a removable storage read/write device (such as for reading from and writing to RAM, a magnetic disk, a magnetic tape, an opto-magnetic disk, an optical disk, or the like); and a modem (e.g., for sending faxes or for connecting to the Internet or to any other computer network via a dial-up connection). In operation, the process steps to implement the above methods and functionality, to the extent performed by such a general-purpose computer, typically initially are stored in mass storage (e.g., the hard disk), are downloaded into RAM and then are executed by the CPU out of RAM. However, in some cases the process steps initially are stored in RAM or ROM.

[186] Suitable general-purpose programmable devices for use in implementing the present invention may be obtained from various vendors. In the various embodiments, different types of devices are used depending upon the size and complexity of the tasks. Such devices can include, e.g., mainframe computers, multiprocessor computers, workstations, personal computers and/or even smaller computers, such as PDAs, wireless telephones or any other programmable appliance or device, whether stand-alone, hardwired into a network or wirelessly connected to a network.

[187] In addition, although general-purpose programmable devices have been described above, in alternate embodiments one or more special-purpose processors or computers instead (or in addition) are used. In general, it should be noted that, except as expressly noted otherwise, any of the functionality described above can be implemented by a general-purpose processor executing software and/or firmware, by dedicated (e.g., logic-based) hardware, or any combination of these, with the particular implementation being selected based on known engineering tradeoffs. More specifically, where any process and/or functionality described above is implemented in a fixed, predetermined and/or logical manner, it can be accomplished by a general-purpose processor executing programming (e.g., software or firmware), an appropriate arrangement of logic components (hardware), or any combination of the two, as will be readily appreciated by those skilled in the art. In other words, it is well-understood how to convert logical and/or arithmetic operations into instructions for performing such operations within a processor and/or into logic gate configurations for performing such operations; in fact, compilers typically are available for both kinds of conversions.

[188] It should be understood that the present invention also relates to machine- readable tangible media on which are stored software or firmware program instructions (i.e., computer-executable process instructions) for performing the methods and functionality of this invention. Such media include, by way of example, magnetic disks, magnetic tape, optically readable media such as CD ROMs and DVD ROMs, or semiconductor memory such as PCMCIA cards, various types of memory cards, USB memory devices, etc. In each case, the medium may take the form of a portable item such as a miniature disk drive or a small disk, diskette, cassette, cartridge, card, stick etc., or it may take the form of a relatively larger or immobile item such as a hard disk drive, ROM or RAM provided in a computer or other device. As used herein, unless clearly noted otherwise, references to computer-executable process steps stored on a computer-readable or machine-readable medium are intended to encompass situations in which such process steps are stored on a single medium, as well as situations in which such process steps are stored across multiple media. [189] The foregoing description primarily emphasizes electronic computers and devices. However, it should be understood that any other computing or other type of device instead may be used, such as a device utilizing any combination of electronic, optical, biological and chemical processing that is capable of performing basic logical and/or arithmetic operations.

Additional Considerations.

[190] Several different embodiments of the present invention are described above, with each such embodiment described as including certain features. However, it is intended that the features described in connection with the discussion of any single embodiment are not limited to that embodiment but may be included and/or arranged in various combinations in any of the other embodiments as well, as will be understood by those skilled in the art.

[191] Similarly, in the discussion above, functionality sometimes is ascribed to a particular module or component. However, functionality generally may be redistributed as desired among any different modules or components, in some cases completely obviating the need for a particular component or module and/or requiring the addition of new components or modules. The precise distribution of functionality preferably is made according to known engineering tradeoffs, with reference to the specific embodiment of the invention, as will be understood by those skilled in the art.

[192] Thus, although the present invention has been described in detail with regard to the exemplary embodiments thereof and accompanying drawings, it should be apparent to those skilled in the art that various adaptations and modifications of the present invention may be accomplished without departing from the spirit and the scope of the invention. Accordingly, the invention is not limited to the precise embodiments shown in the drawings and described above. Rather, it is intended that all such variations not departing from the spirit of the invention be considered as within the scope thereof as limited solely by the claims appended hereto.

Claims

CLAIMSWhat is claimed is:

1. A digital cinema management system, comprising: a plurality of separate screen management systems, each said screen management system managing content played on a digital cinema projector; a SMS agent attached to each said screen management system; a theater management system, separate from the screen management systems, monitoring and controlling operations for a theater that includes the screen management systems; and a TMS agent attached to the theater management system, wherein the TMS agent is configured to communicate with each said SMS agent, and each said SMS agent is configured to communicate with the TMS agent, and wherein each said SMS agent comprises a finite state machine listening for an occurrence of a predefined digital cinema platform event on the attached screen management system that changes a state of the finite state machine and, upon said occurrence, issues an asynchronous SMS event communication to the TMS agent.

2. A digital cinema management system according to claim 1, wherein the SMS agent attached to at least one of the screen management systems communicates with the TMS agent using message oriented middleware.

3. A digital cinema management system according to claim 1, wherein the SMS agent attached to at least one of the screen management systems communicates with the TMS agent using a service-oriented architecture.

4. A digital cinema management system according to claim 1, wherein the SMS agent attached to at least one of the screen management systems communicates with the TMS agent using an agent language that is based on a standard agent platform architecture.

5. A digital cinema management system according to claim 1, wherein the SMS agent attached to at least one of the screen management systems coordinates with the TMS agent so as to maintain a consistent internal state of behavior and data between said screen management system and the theater management system.

6. A digital cinema management system according to claim 1, wherein at least one of the SMS agents and the TMS agent translates digital cinema platform events occurring within the screen management systems from a vendor-specific code into a predefined common event hierarchy.

7. A digital cinema management system according to claim 1, wherein at least one of the SMS agents and the TMS agent translates machine characteristic information within the screen management systems from vendor-specific Simple Network Management Protocol (SNMP) protocols into a predefined common event hierarchy.

8. A digital cinema management system according to claim 7, wherein the predefined common event hierarchy includes both said machine characteristic information and events that are specific to a digital cinema platform.

9. A digital cinema management system according to claim 1, wherein each of the SMS agents is a background process running on a host machine.

10. A digital cinema management system according to claim 1, wherein at least one of the SMS agents and the TMS agent coordinate with each other so as to replicate an application programming interface of the screen management system to which said at least one SMS agent is attached within the theater management system.

11. A digital cinema management system according to claim 1 , wherein at least one of the SMS agents merges a registry with the TMS agent.

12. A digital cinema management system according to claim 1, further comprising: a second theater management system monitoring and controlling operations for a second theater; a second TMS agent attached to the second theater management system; an enterprise management system, separate from the screen management systems and the first and second theater management systems, monitoring and controlling operations for an enterprise that includes the theater and the second theater; and an EMS agent attached to the enterprise management system, wherein the EMS agent is configured to communicate with each of the first and second theater management systems, and each of the first and second theater management systems is configured to communicate with the EMS agent.

13. A digital cinema management system according to claim 12, wherein each of the first and second theater management systems comprises a finite state machine that listens for an occurrence of a predefined digital cinema platform event on the attached theater management system that changes a state of the finite state machine within said theater management system and, upon said occurrence, issues an asynchronous TMS event communication to the EMS agent.

14. A digital cinema management system according to claim 1, wherein predefined digital cinema platform event on the attached screen management system is identified by monitoring a log generated by the screen management system.