MXPA05013130A - Interoperable systems and methods for peer-to-peer service orchestration - Google Patents

Abstract

Systems and methods are described for performing policy-managed, peer-to-peer service orchestration in a manner that supports the formation of self-organizing service networks that enable rich media experiences. In one embodiment, services are distributed across peer-to-peer communicating nodes, and each node provides message routing and orchestration using a message pump and workflow collator. Distributed policy management of service interfaces helps to provide trust and security, supporting commercial exchange of value. Peer-to-peer messaging and workflow collation allow services to be dynamically created from a heterogeneous set of primitive services. The shared resources are services of many different types, using different service interface bindings beyond those typically supported in a web service deployments built on UDDI, SOAP, and WSDL. In a preferred embodiment, a media services framework is provided that enables nodes to find one another, interact, exchange value, and cooperate across tiers of networks from WANs to PANs.

Description

SYSTEMS AND METHODS.IN EROP-ERABLES FOR-ORCHESTATION "SERVICE EQUAL TO EQUAL Related Requests This application claims the priority of the Request for Provisional Patent of E.U. commonly ceded NOS. 60 / 476,357, entitled "Systems and Methods for Equal to Equal Services Orchestration", by William Bradley and David Maher, filed on June 5, 2003, and 60 / 504,524, entitled "Systems and Methods of Digital Rights Management ", by Gilíes Bocón-Gibod, presented on September 15, 2003, both of which are incorporated herein by reference in their entirety; these requests are also appended to this as 83 pages of material included in this specification.

Authorization of Copyright A portion of the exposition of this patent document contains material that is subject to copyright protection. The owner of the copyright has no objection to the reproduction of any of the patent documents or patent exposition, as it appears in the archives or records of the Patent and Trademark Office, but otherwise reserves all rights From author.

ANTE-CÉDENTS- Networks such as the Internet have become the predominant medium for the supply of digital content and media-related services. The emergence of standard network service protocols promises to accelerate this trend, allowing companies to provide services that can interoperate across multiple software platforms and support cooperation between business services and consumers through standardized mechanisms. There are still significant barriers to the purpose of an interoperable and secure world of media-related services. For example, multiple fact overlays and formal standards can actually inhibit direct interoperability by forcing different implementations to select between marginally standard, but otherwise incompatible, alternative technical approaches to address the same problems of basic interoperability or interconnection. . In some cases, these incompatibilities are due to problems that arise from trying to integrate different generations of technologies, although in other cases the problems are due to market options prepared by different parties that operate at the same time but in different locations and with different requirements. In this way, despite standardization, it is often difficult to locate, connect to, and interact with devices that provide necessary services. And there are often points of incompatibility between - - Although emerging network service standards, such as WSDL (Network Description Service Language) begin to address some of these issues for systems facing the Internet, such approaches are incomplete. . They fail to address these issues through multiple levels of network that encompass work networks of personal and local area; access roads to home, company and department; and wide networks of work by area. They also do not adequately address the need for interoperability based on dynamic orchestration of both simple and complex services using a variety of service interface links (eg, CORBA, WS-I, Java RMI, DCOM, invocation of C functions). , .Net, etc.), thus limiting the ability to integrate many policy applications. The arrival of peer-to-peer and networked applications (P2P) and networks further complicates the obstacles in the creation of interoperable services related to media, due in part to the fact that there is no unified notion of how to represent and reinforce usage rights over digital content.

BRIEF DESCRIPTION The embodiments of the systems and methods described herein can be used to address some or all of the above problems. In a modality, a service structure is provided that allows multiple types of companies - - - international - in the medium space of the consumer (the example, consumers, content providers, device manufacturers, service providers) that meet each other, establish a relationship of trust, and exchange of values in 5 rich and dynamic ways through exposed service interfaces. The modalities of this structure - which will generally be referred to as the Network Environment for Media Orchestration (NEMO) - can provide a platform to allow electronic commerce related to media, secure, interoperable, in a world of heterogeneous consumer devices, media formats, communication protocols and security mechanisms. The distributed policy management of the service interfaces can be used to provide confidence and security, thus facilitating the commercial exchange of values. Although the emerging network service standards begin to address interoperability issues for services that face the Internet, NEMO modalities can be used to direct interoperability across multiple network levels that encompass personal and local area networks; access roads to the home, company and department; and wide area networks. For example, NEMO can provide interoperability in an interconnected system that uses cell phones, gaming platforms, PDAs, PCs, network-based content services, discovery services, notification services, and update services. The modalities-of-WE O-pv © deft ~ ^ -at11í pata ~ pr6p6r6cionar the peer-to-peer, dynamic orchestration of both simple and complex services by using a variety of local and remote interface links (eg WS-I [1], Java RMI, DCOM, C,. Net, etc.), thus allowing the integration of legacy applications. In the media world, the systems and interfaces required or favored by the major sets of participating international institutions (for example, content publishers, distributors, retail services, consumer device providers, and consumers) often differ widely. In this way, it is desirable to unify the capabilities provided by these entities in integrated services that can rapidly develop optimal configurations that meet the needs of the participating entities. For example, protocols and discovery records of various services, such as Bluetooth, UPnP, Rendezvous, Jll, UDDI, and LDAP (among others) can coexist within the same service, allowing each node to use the service (s). ) of discovery more suitable for the device that hosts that node. Another service could support IP-based notification, as well as wireless SMS or various media formats (MP4, WMF, etc.). The NEMO modalities satisfy these purposes through the use of peer-to-peer services orchestration (P2P). -. observed for things such as music and video distribution, P2P technology can be used much more extensively. Most activity in network services has focused on machine-to-machine interaction with relatively static network configuration and customer service interactions. NEMO is able to handle situations in which a person contains parts of their personal area network (PAN), moves in the vicinity of a LAN or another PAN, and want to reconfigure access to the service immediately, as well as connect to many additional services on an equal basis. There are also opportunities in the media and other diverse business services and especially in interactions between two or more companies. Although companies are often more hierarchically organized and their information systems often reflect that organization, people from different companies will often interact more effectively through equality interfaces. For example, a person / service recipient in company A can solve problems or obtain useful information more directly when talking with the traffic person in company B. Neglected or unnecessarily interfering hierarchies are generally not useful. Transportation companies (such as FEDEC and UPS) realize This allows direct visibility into their processes, allowing companies and municipalities to organize their services through corporate portals., allowing simple forms of self-service. 5 However, the existing peer-to-peer work structures do not allow a company to expose its various service interfaces to its clients and suppliers, in such a way that those entities are allowed to interact at natural equality levels, allowing those entities orchestrate services business as best suits them. This would include, for example, some forms of trust management of those equality interfaces. The preferred embodiments of the present invention can be used not only to allow but to facilitate this P2P exposure of service interfaces. 15 In the context of particular applications such as DRM (Copyright Management), the NEMO modalities can be used to provide a service-oriented architecture, designed to address the shortcomings and limitations of closed, homogeneous DRM systems. The preferred modalities can be used to provide interoperable, secure, media-related trading, operations for fired consumer devices, media formats, and security mechanisms. In contrast to many DRM systems Conventional technologies, which require client-side engines -ready, vague, and "handle" protected content, the preferred embodiments of the present invention allow DRM engines on the client side to be relatively simple, reinforcing the policies of management established by richer policy management systems that operate at the service level. Preferred embodiments of the present invention can also provide increased flexibility in the selection of cryptographic media formats and protocols, and can facilitate interoperability between DRM systems. A simple, open and flexible client side DRM engine can be used to build powerful applications enabled by DRM. In one mode, the DRM engine is designed to be easily integrated into a networked services environment and into virtually any host software environment or architecture. The orchestration of services is used to overcome interoperability barriers. For example, when there is a content query, the various services (for example, discovery, search, match, update, exchange of rights and notification) can be coordinated in order to satisfy the request. Preferred modes of orchestration capability allow a user to observe all associated memories of home and Internet-based content of any device at any point in a dynamic multi-tiered network. This capacity can be extended to promote the sharing of streams and performance lists, the elaboration of ^-^ - "" of ^ -t-ran-sTn-tetóñés ^ - 'a-mplias and narrow impro isá ^ "s ^ ^ rres: *? e = discover and connect, using many different devices, while ensuring rights are respected NEMO's preferred modalities provide an interoperable end-to-end 5-way distribution system that does not depend on just one set of standards for media format, rights management and compliance protocols.In the value chain that includes content originators, distributors, retailers, suppliers of service, device manufacturers and consumers, there are often some localized needs in each segment. This is especially true in the case of rights management, where content originators may express usage rights that apply differently in different contexts for different rights. value chain elements downstream. A consumer access path typically has a much narrower set of priorities and an end-user device can have an even simpler set of priorities, ie, running only the content. With a sufficiently automated system of services In order to distribute dynamic self-configuration, content originators can produce and package content, express rights and rely on confidential values of other service providers to quickly provide content to interested consumers, regardless of where are found or the kind of device they use. -. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - innovate and introduce new services that benefit both consumers and service providers without having to wait or rely on a monolithic set of end-to-end standards.Policy management can limit the degree to which pirates can maneuver Those legitimate services, NEMO allows the effect of networking to promote the evolution of a very rich set of legitimate services 10 that provide better values than those that pirates can provide.Some "best practice" techniques common to many of the The modalities discussed below include the following: • Separation of complex policies oriented to the device and oriented to the service • Composition of sophisticated services based on more simplified services • Dynamic configuration and service announcement. • Dynamic discovery and invocation of various services in a heterogeneous environment. • Use of access path services from simple devices. There is also a novel DRM engine and architecture that can be used with the NEMO work structure.

This DRM system can be used to achieve some or all of the following: pro-tes it: - == 3 ^ = ^ = _ ^^^ - ==== - - = - ^ = ^ ^ .. Simplicity. In one embodiment, an engine is provided DRM that uses a Virtual Machine based on minimalist batteries (VM) to execute control programs (for example, programs that reinforce government policies). For example, the VM could only consist of a few pages of codes. Modulation capacity. In one mode, the DRM engine is designed to function as a single module integrated into a larger DRM-enabled application. Many of the functions that were carried out once by monolithic DRM cores (such as cryptography services) can be requested from the host environment, which can provide these services to other code modules. This allows designers to incorporate standard or proprietary technologies with relative ease. Flexibility. Due to its modular design, the preferred DRM engine modalities can be used in a wide variety of software environments, from embedded devices to general purpose PCs. Opening. The modalities of the DRM engine are suitable for use as reference software, so that the code modules and APIs can be implemented by users in virtually any programming language and in systems that they can control completely. In one embodiment, the system does not force users to adopt particular content formats or limit the content encoding.

- - = - -Semically agnostic. In a module? "The DRM module is based on a model based on simple graphics that makes authorization requests in queries about the structure of the graph.The vertices in the graph represent entities in the system and the directed edges represent relationships between these entities. , the DRM engine does not need to be aware of which of these vertices and edges represent any particular application Seamless Integration with Network Services The DRM client engine can use network services in several ways, for example, the vertices and edges in The graph can be discovered dynamically through services Content and content licenses can also be discovered and delivered to the DRM engine through sophisticated network services, although one mode of the DRM engine can be configured to manipulate network services in many places, its architecture is independent of network services and can be used as a DRM kernel on the client side, independent. Simplified Management of Keys. In one embodiment, the graphics topology can be re-used to simplify the derivation of content protection keys without requiring cryptographic redirection. The key derivation method is an optional but powerful feature of the DRM engine - the system also, or alternatively, may be able to integrate with other key management systems.

- - = • - • '- Separation of Tsb? Érrio, E? Cnpción and Content? ^? fr QfxB- modality, the controls that govern the content are logically distinct from the cryptographic information used to strengthen the capacity of government. Similarly, the controls and cryptographic information are logically distinct from content and content formats. Each of these elements can be supplied separately or in a unified package, thus allowing a high degree of flexibility in the design of a content delivery system. 10 The modalities of the NEMO work network, its applications and its component parts are described here. It should be understood that the work structure itself is novel, as are many of its components and applications. It should also be appreciated that the present invention can be implemented from numerous ways, including processes, devices, systems, devices, methods, computer-readable media or a combination thereof. These and other features and advantages will be presented in greater detail in the following detailed description and the accompanying drawings that illustrate, by way of example, the principles of the inventive body of work.

BRIEF DESCRIPTION OF THE DRAWINGS The modalities of the inventive working body will be easily understood by reference to the following Detailed description in conjunction with the accompanying drawings, in which - "similar numerical references" designate similar structural elements, and in which: Fig. 1 illustrates a sample embodiment of the structure of the system. Fig. 2a illustrates a conceptual network of system nodes. Fig. 2b illustrates system nodes in a P2P network. Fig. 2c illustrates system nodes operating through the Internet. Fig. 2d illustrates a system access node. Fig. 2e illustrates a node in proximity to the system. Fig. 2f illustrates an adapter node to the system device. Fig. 3 illustrates a conceptual network of DRM devices. Fig. 4 illustrates a conceptual DRM node authorization chart. Fig. 5a illustrates a conceptual view of the architecture of a system node. Fig. 5b illustrates interface links of multiple services supported by the service adaptation layer of a system node. Fig. 6a illustrates the basic interaction between a system node providing services and a system node consuming services. Fig. 6b is another example of an interaction between a - node - system: for services and a system of systems. The "consumes services." Fig. 7a illustrates a service access point involved in a client-side WSDL interaction, Fig. 7b illustrates a service access point involved in a native client-side interaction. 7c illustrates a service access point in a service-to-interaction point-of-service pattern, Fig. 7d illustrates a service access point in a service point-to-multipoint point pattern. of Interaction Fig. 7e illustrates a service access point involved in a side-by-side pattern of the intermediate service-to-interaction.Figure 8 illustrates one modality of the architecture of the service adaptation stratum. 9a illustrates an interaction pattern of a workflow classifier that depends on external service providers Fig. 9b illustrates an interaction pattern of a workflow classifier involved in communication multi-phase lines with a client node. Fig. 9c illustrates a basic pattern of intra-node interaction of a workflow classifier. Fig. 9d illustrates a relatively-complex interaction pattern of a "work flow" classifier. - * - - = ^ ----- - - = * == »« ¥ = 5 ^ - The. Fig. 10 illustrates the system integration of a DRM engine. Fig. 1 1 illustrates a modality of the architecture of a 5 DRM engine. Fig. 12a illustrates a DRM engine and related elements within a service side system node. Fig. 12b illustrates a DRM engine and related elements within a service side system node. 10 Fig. 13 illustrates a protection mode of authority DRM objects and content. Fig. 14 illustrates a node mode and link DRM objects. Fig. 15 illustrates a DRM cryptographic key element mode. Fig. 16 illustrates a basic interaction pattern between the client and the system nodes that provide service. Fig. 17a illustrates a set of notification processing nodes that discover a node that supports a notification handler service. Fig. 17b illustrates the process of delivering notifications. Fig. 18a illustrates a scenario of discovery of services operated by the client, in which a requesting node performs a service discovery request to a target service-provider node Y - - ^ - - - - - - "Fig. 18b illustrates an equality registration services discovery scenario, in which a requesting node seeks to register its description with a service provider node Fig. 18c illustrates an event-based service discovery scenario in which an interested node receives notification of a change in service availability (eg example, the existence of a service within a service provider node.) Fig. 19a illustrates the process of establishing trust through the use of a service link with an implicitly trusted channel, Fig. 19b illustrates the process of establishing trust based on a request / response model Fig. 19c illustrates the process of establishing trust based on an explicit exchange of security credentials Fig. 10 illustrates access managed by politics a to a service Fig. 21 illustrates a DRM node graph displayed with membership links and key access. Fig. 22 illustrates a format mode of a VM DRM code module. Fig. 23 illustrates a profile hierarchy of system functions. Fig. 24 illustrates application scenarios of music reptoduction DRMk - = _.- ~ _ ^^ --- _- ^. ^ --_ --- .- DETAILED DESCRIPTION A detailed description of the inventive operating body is given below. Although this description is provided in conjunction with various modalities, it should be understood that the inventive operating body is not limited to any modality, but rather encompasses numerous alternatives, modifications and equivalences. For example, although some modalities are described in the context of consumer-oriented content and applications, those skilled in the art will recognize the systems and methods set forth are readily adaptable for a broader application. For example, without limitation, these modalities could easily be adapted and applied to the context of business content and applications. Furthermore, although numerous specific details are set forth in the following description in order to provide a thorough understanding of the inventive working body, some modalities may be practiced without some or all of these details. In addition, for purposes of clarity, certain technical material known in the art has not been described in detail in order to avoid unnecessarily obscuring the inventive operating body. 1. CONCEPTS 1.1 Services in Rec ~ ~ - - • = - - - - * The Network Services Architecture (WSA) is a specific instance of a Service Oriented Architecture (SOA).

An SOA is itself a type of distributed system consisting of cooperative software agents, loosely coupled. Agents in an SOA can provide a service, request (consumption) of a service or perform both. A service can be seen as a self-contained, well-defined set of operations handled by an agent acting in a service provider role. The operations are invoked over the network at a certain network-steered location, called an endpoint, that uses standard data protocols and formats. By self-content, it is understood that the service does not directly depend on the state or context of another service or application that covers it. Examples of established technologies that support the concepts of an SOA include CORBA, DCOM, and J2EE. The WSA is attractive because it is not linked to a specific platform, programming language, application protocol stack, or data format convention. The WSA uses standard formats based on XML to describe services and exchange messages that promote loose coupling and interoperability between providers and consumers, and supports multiple standard Internet protocols (notably HTTP), which facilitates the deployment and participation in a system potentially distributed globally.

- '"-" "" "An emerging Te ^ encr" is observing an SOA in the context of a "connect and run" service bus. The service bus approach provides the orchestration of services by leveling description, messaging and transport standards. The infrastructure can also incorporate standards of discovery, transformation, security, and perhaps also others. Through the intrinsic qualities of the traditional standards incorporated in the WSA, it is flexible, expandable and scalable and, therefore, provides the appropriate foundation for the construction of a bus model of orchestrated services. In this model, the fundamental unit of work (the service) is called a network service. There is a large number of definitions for a network service. The following definition comes from the Network Services Architecture work project of the World Wide Network Consortium (W3C) (August 8, 2003 - see www.w3.org/TR/ws-arch): A network service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine processable format (specifically WSDL). Other systems interact with the network service in a manner prescribed by its description by using SOAP messages, typically transported by using HTTP with an XML serial order in conjunction with other standards related to the network. Although the W3C definition provides a useful starting point ^ must understand what the term, "network services" "is used in the present in a broader sense, without limitation, for example, for the use of specific standards, formats and protocols (eg , WSDL, SOAP, XML, HTTP, etc.). A particular network service can be described as an abstract interface for a logically coherent set of operations that provides a basis for a (possibly transitory) relationship between a service provider and a service provider. service requester Of course, real network services have concrete implementations.The concrete implementation of the provider is sometimes referred to as l service (as distinguished from the network service). The software that actually implements the functionality for the service provider is the supplying agent and for the service requester, the requesting agent. The person or organization that owns the agent is referred to as the supplying entity or applicant entity, as appropriate. When used alone, the applicant or provider may refer to any respective entity or agent, depending on the context. A network service exists to satisfy a purpose, and the way it is achieved is specified by the mechanics and semantics of the exchange of service messages in a particular network. The mechanics refers to the technical specifications, processable by machine, precise, that allow the exchange of messages on a network to occur. Although the mechanics are defined precisely, the semantics could be different. ~ The semantics "ref to af" contract "explicit or implicit in any form that exists, governing the understanding and expectations in general between the requesting and the provider entities for the network service." Network services are often modeled in terms of Interactions of three functions: (i) Service Provider, (ii) Service Applicant, and (iii) Service Registration In this model, a service provider "publishes" the information describing its network service for a registry of services. A service requester "finds" this information through some discovery mechanism and then uses this information to "connect" to the service provider in order to use the service Connecting simply means that the requester will make the operations available available by the provider through the use of message format, graphical representation of data, and transportation protocol conventions. specified by the provider in the published service description. The XML-based language used to describe this information is called the Network Services Description Language (WSDL). A service provider offers access to a certain set of operations for a particular purpose described by a description of WSDL services; This service description is published in a registry by any number of means so that the service can be discovered. A record can be public or private within a specific domain. _. A "registry k3e ~ servicios és" software- that Tends to requests for service search when returning a previously published description of services. A service requester is software that invokes various operations offered by a provider in accordance with the connection information specified in the WSDL obtained from a registry. The service record can exist only in a conceptual way or it can exist, in fact, as real software that provides a database of descriptions of services used to consult, locate and connect to a particular service. But if an applicant actually conducts an active search for a service or if a service description is provided in a static or dynamic manner, the registration is a logically distinct aspect of the networked services model. It is interesting to note that in a real-world implementation, a service registry can be a part of the service requester's platform, the service provider's platform, or it can reside elsewhere entirely identified by some well-known address or a provided address by some other means. The WSDL services description supports loose coupling, often a central theme behind an SOA. Although finally a service requester will understand the semantics of the service interface consumed with the purpose of achieving a desired result, the service description isolates the service interface from the service connection specific information and supports a service model in highly dynamic network. A service-oriented architecture can be built on top of many possible technology strata. As practiced today, network services typically incorporate or involve aspects of the following technologies: HTTP - a standard application protocol for most network service communications. Although network services can be depleted over various networking protocols (for example, SMTP, FTP, etc.), HTTP is the most ubiquitous transport, compatible with the wall of fire in use. For certain applications, especially within an intranet, other networking protocols may make sense, depending on the requirements; however, HTTP is a part of almost any network service platform built today. XML - a standard for formatting and accessing content (and information about content) of structured information. XML is a text-based standard for communicating information between network service agents. Note that the use of XML does not mean that message payloads for network services may not contain any binary data; but it means that this data will be formatted in accordance with XML conventions. Most network service architectures do not necessarily dictate these messages and the data is serially ordered for a character stream - they can only be ordered in series for a binary stream where it makes sense - but if XML is being used - - ^ , these streams will represent documents-XlvlL. ^ E 'is to say over the level of the transport mechanism, the sending of network service messages will often be conducted through the use of XML documents. 5 Two XML subset technology that are particularly important for many network services are XML Name Spaces and XML Schemas. XML Name Spaces are used to resolve mention conflicts and determine specific meanings for elements contained with XML documents. XML Schemas are used to define and limit certain information topics contained within an XML document. Although it is possible (and optional) to carry out these objectives by other means, the use of XML is probably the most common technique used today. The format descriptions XML document 5 for network service documents are defined by using XML Schema and most real-world network services operations and the messages themselves will be further defined by incorporating the XML Schema. SOAP - an XML-based standard for 0 encapsulation instructions and information in a special format package for transmission and handling by other receivers. SOAP (Simple Object Access Protocol) is a standard mechanism for packaging messages from network services for transmission between agents. In a way, an erroneous term, its legacy is like a means to invoke distributed objects and in that aspect it is therefore "simpler" - qe - ^ o? fás ^^^ ^ pr ~~ Tá ^ "ten e cTa" "recent is to consider SOAP As an XML-based connection protocol for purposes that have transcended the original meaning of the acronym, SOAP defines a relatively lightweight convention for structuring messages and the proportion of information about the content.Each SOAP document contains a wrapper that is it divides into a header and a body, although structurally similar, the header is usually used for meta-information or instructions for receivers related to the handling of content within the body, SOAP also specifies a means to identify characteristics and the necessary processing to meet the obligations of the characteristics A Message Exchange Pattern (MEP) is a characteristic that defines a pattern in the manner of exchange messages between nodes. A common MEP is request-response, which establishes a single complete message transaction between an applicant and a responding node (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624#soapsupmep .). WSDL - an XML-based standard to describe how a network service is used. From a WSDL perspective, a service is related to a set of messages exchanged between applicants and service providers. The messages are described in an abstract way that can be represented graphically in specific protocols. The ^ kn-tersambio ^ e ^ mens-ijes ^ that invokes certain functionality is "called an operation." A specific set of operations defines an interface.An interface is related to a particular message format and protocol over a named connection. (the graphical representation of an interface for a specific protocol) is associated with an appropriate URI for the protocol, resulting in an endpoint.A collection of one or more related endpoints (graphic representation of an interface for specific protocols to URIs specific) includes a service, these definitions represent specific elements WSDL: Container element types for type definitions Message an abstract definition of the data type sent Operation an abstract description of an action based on a combination of input, output and failure messages. tipoPuerto an abstract set of operations - an interface Connection specification of a specific protocol and data format for an interface (port type) Port the combination of a connection and a real network work address - an endpoint --__.- _ - _ Service a port collection ^^ - rélacrsna iO? ^ '* "' (Endpoints) WSDL defines a common connection mechanism and then defines specific connection extensions for SOAP, HTTP GET / POST and MIME. In this way, the connection does not necessarily mean connecting to a transport protocol directly, but to a specific cable format. The most common connection for network services is SOAP, although actual exchanges of SOAP messages generally occur over HTTP on port 80 (through an http: // URI). However, an interface can connect directly to http; alternatively, for example, a connection to SOAP can use SMTP (through an email to: // URI). An implementation can even define its own cable format and use a custom connection extension. 15 WSDL boosts maintenance and reuse capability by supporting ratio to an element of < Import > . By using the import, a WSDL document can be divided into separate pieces so that an organization is given meaning. For a cohesive network services environment that wants a certain degree of separation between an interface definition and an implementation definition, the following separation in three documents is reasonable: A schema document (.xsd) - the root node is < scheme > and the namespace is 25 http://www.w3.org/2001/XMLSchema "~ A service worm that contains what is considered the reusable portion <message> <porttype> <connection> A definition of service implementation that contains the service-specific endpoint <service> WSDL interfaces are not exactly like Java interfaces (or IDL, or some other programming language.) For example, a specific Java interface declaration a set of methods that must agree with at least a subset of the methods of a class that requires the implementation of that interface.More than one class can implement an interface and each implementation can be different, but method identifications (name of the method and any type of input and output) should generally be identical, this is indicated by the language and is reinforced at compile time, execution time or both. It is different and more like a real abstract class that by itself is not completely useful. Various WSDL interfaces, or Port Types, of a single network service are logically related in the sense that the set of operation names must be identical - as if the Port type implemented, in fact, a specific contract in some other logar - but none of such elements really exists and there is no mechanism to reinforce the "kde" - typePuerto symmetry. Each typePuerto ~ is mentioned "generally to identify the type of connection it supports -even though aPort type only does not create a connection.Port operations for relatedPort types are mentioned equally, but the input, output, and failure messages (if presented) ) are graphically represented in specific messages containing mentioned parts also necessary for the support of a specific connection, which highlights the point that the messages themselves are not completely abstract.A service can and often needs to define similar but different messages For the various connections required, as will be illustrated below, when leveling the emerging network service and related standards, a system architecture can be developed that facilitates the creation of services related to interoperable media for networking, using a variety of protocols and different interfaces through u n wide range of hardware and software platforms and operating environments. 1. 2 Functions Preferred embodiments of the present invention seek to actively enable, promote and / or support a peer-to-peer environment in which parities can spontaneously offer a variety of functionality by exposing services. A modality of the work structure decreases the observation of parities that have u? set fij? ^ e ^ capacTdade's; and instead promotes a model where parity at any point in time is a participant in one or more functions. A function can be defined by a set of services that a given parity exposes in combination with a specific behavior pattern. At any given moment, a node enabled by NEMO can act in multiple functions based on a variety of factors: its actual implementation trail that provides the functionality to support a given set of services, administrative configuration, information that declares the (s) service (s) that parity is able to expose and load policy and routine in service interfaces. An explicit set of functions could be defined based on different types of services. Over time, as common participation patterns are determined and new services introduced, a more formal categorization of functions could be defined. A preliminary set of functions that can be formalized over time could include the following: Client - a relatively simple function in which no service is exposed and parity simply uses services from other parities. Authorizer - this function denotes a parity that acts as a Policy Decision Point (PDP) that determines whether a requesting authority has access to a specific resource with a given set of pre-conditions and post-conditions.

Path of Access - in certain situ- ations, a parity may not be able to discover or interact directly with other service providers, for reasons that include: incompatibility of the transport protocol, inability to negotiate a reliable context, or lack of processing capacity to create and process the necessary messages associated with a given service. An access path is a parity that acts as a bridge to another parity in order to allow parity to interact with a service provider. From an identity perspective and the establishment of an authoritative and trustworthy context for operation, the requesting parity can actually delegate its identity identity parity and allow parity to negotiate and make decisions on its behalf. Alternatively, the access parity can act as a simple relay point, advancing or directing demands and responses. Orchestrator - in situations where interaction with a set of service providers involves the non-trivial coordination of services (including possibly transactions, distributed state management, etc.), a capacity for parity to participate can be found separately. An orchestrator is a specialization of the access function. A parity can ask an orchestrator to act in his name, intervening to provide one or more services. The orchestration parity may use certain additional NEMO components, such as a Workflow Flow Classifier, which is configured to meet orchestration requirements, given the purpose of "providing instant gratification to meet a demand for Any medium, in any format, from any source, anywhere, at any time, on any device that complies with any reasonable set of rules of use, "the following informal model illustrates how this purpose can be achieved through use of modalities of the NEMO work structure.

It will become apparent from the highest level of the model (without listing each aspect of how NEMO allows lower level services of different levels in the model to be assembled into richer end-to-end media services. of this model, there are four levels of service components: 1) Content Authorization, Assembly, and Packing services, 2) Content Addition and Distribution Services based on Network, 3) Domestic Access Route services and 4) Consumer Electronic devices. Each of these four levels typically has 0 different security requirements, rights management, service discovery, service orchestration, user interface complexity, and other system attributes. The first two levels fit almost exactly in the models we observe as "traditional" network services, while the last two levels fit more into what we might call a model of personal logical network work, with certain the ~ domestic access road in the links between the two types of models. However, services for CE devices could occasionally appear at any of the levels. A dilemma lies in the desire to specialize parts of the work structure for implementation efficiency, although it would generally be sufficient to encompass an end-to-end solution. For example, a UDDI and discovery directory approach may work well for relatively static and centralized network services, but for a more dynamic transient personnel emergence, discovery models such as those found in UPnP and Rendezvous may be more appropriate. Thus, in some modalities, multiple discovery standards are accommodated within the work structure. Similarly, when rights management is applied to distribution of media through sub-levels of wholesale distribution, addition and often, there may be different types of complex rights and obligations that need to be expressed and tracked, suggesting the need for a highly expressive and complex language of rights, content authority and sophisticated cleaning services and a model of global trust. However, the rights and content management authority for the domestic gateway and CE device levels may encompass a different trust model that emphasizes broadly-used rights that are relatively straightforward from the "T_ -Tsta" point ofTT. consumer. Parity devices in a personal logical network may wish to interact through the use of the relatively simple trust model of that network, and with the ability to interact with parities through a wide-area network through the use of a model. of global trust, perhaps through the use of nearby access services. At the consumer end, complexity arises from the automated management of content availability through the device, some of which are mobile and intermittently intercept multiple networks. In this way, an effective approach to rights management, which at the same time allows end-to-end distribution, could also be heterogeneous, supporting a variety of rights management services, including services that interpret expressions of distribution rights and translate, in context, into individual consumer use rights in a transaction that is orchestrated with a sales transaction, or perhaps another event where a subscription right is exercised. 1. 3 Logical Model In a modality, the structure of the system consists of a logically connected set of nodes that interact in a peer-to-peer manner (P2P). The peer-to-peer calculation is often defined as the sharing of resources (such as hard drives and processing cycles) between 'computers ^ - and- - smart devices. See http://www.intel.com/cure/peer.htm. Here, P2P can be observed as a communication model that allows network working nodes to be consumed symmetrically and provide services of all kinds. The sending of P2P messages and the classification of the workflow allow rich services to be created dynamically from a heterogeneous set of more primitive services. This allows the examination of the P2P computation possibilities when the shared resources are services of many different types, even through the use of different service connections. Different modalities can provide a structure of media services that allow the participants in the operation (for example, consumers, content providers, device manufacturers and service providers to meet each other, interact, exchange values and cooperate in rich and dynamic ways. These different types of services vary from the most basic level (discovery, notification, search and file sharing) to more complex higher level services (such as files, licensing, coupling, authorization, payment transactions and updating) and combinations of any or all of these.Services can be distributed through peer-to-peer communication nodes, each providing direction and orchestration of messages through the use of a message-stream and classifier of t rab flow to] ck ( d written in more detail below), designed for this working structure. The nodes interact when preparing service invocation requests and receive responses. The format and payload of demand and response messages are preferably defined in a network service description language based on standard XML schema (for example, WSDL) that incorporates an expandable set of data types that allow the description and composition of services and their associated interface connections. Many of the target types in WSDL are polymorphic and can be extended to support new functionality. The structure of the system supports the construction of different communication patterns, varying from direct interaction with a single service provider to a complex addition of a choreographic set of services from multiple service providers. In one modality, the work structure supports the basic mechanisms for the use of existing service choreography standards (WSCL, BPEL, etc.) and also allows service providers to use their own conventions. The message syntax associated with the invocation of services is preferably described in a relatively flexible and portable manner, as do the core data types used within the working structure of the system. In one embodiment, this is accomplished by using WSDL to provide relatively simple ways to refer to semantic descriptions associated with described services. A service interface can have one or more service connections. In such mode, a node can invoke the interface of another node as long as the connection of that node's interface can be expressed in, for example, WSDL, and as long as the requesting node can support the conventions and protocols associated with the connection . For example, if a node supports a network service interface, a requesting node may be required to support SOAP, HTTP, Security-WS, etc. Any service interface can be controlled (for example, rights management) in a standardized manner, directly providing aspects of rights management. Interactions between nodes can be observed as indicated operations. Virtually any type of device (physical or virtual) can be observed as potentially enabled by NEMO and allows to implement key aspects of the NEMO structure. Device types include, for example, consumer electronic equipment, networking services, and software clients. In a preferred embodiment, a device enabled by NEMO (node) typically includes some or all of the following logical modules (discussed in more detail below): Native API Services - the set of one or more services that the device implements. There is no requirement that a NEMO node expose any service directly or indirectly in the NEMO work structure. Native Service Implementation - the corresponding set of implementations for native API services. Service Adaptation Stratum - the logical stratum through which an exposed subset of an entity's native services has access through the use of one or more discoverable connections described in, for example, WSDL. Work Structure Support Library - components that provide support functionality for operation with the NEMO structure that includes support for invoking service interfaces, message processing, service orchestration, etc. 1. 4. Terminology In a modality, a basic WSDL profile defines a set of minimum "core" data types and messages to support interaction patterns and infrastructure functionality !. Users can either directly, in an appropriate manner, or through some form of standardization processes. Define other profiles built on top of this core, adding new data and types of service and what exists in expansion. In a modality, this core profile includes definitions for some or all of the following main types of basic data: Node - a representation of a participant in the ~ "structure" of the system's work. "A node can functions that include a service consumer and / or a service provider." The nodes can be implemented in a variety of ways, including consumer electronic devices, software agents such as media players or virtual service providers. , such as content search engines, DRM license providers or content blockers Device - encapsulates the representation of a virtual or physical device User - encapsulates the representation of a client user Request - encapsulates a service request for a set of target nodes 5 Application entry - encapsulates the entry of a Request. Answer - encapsulate a Response associated with a Request. Result of the Request - encapsulates Results 0 within a Response associated with any Request. Service - encapsulates the representation of a set of well-defined functionalities, exposed or offered by a provider node. This could be, for example, a low-level functionality offered within a device such as a cellular telephone 5 (eg, a voice recognition service), or a multi-faceted functionality offered "eh Ta network at the world level (for example). example, a shopping service.) Services could cover a wide variety of applications, including DRM-related services, such as customer personalization and license acquisition Service Provider - an entity (eg, a Node or Device) that exposes a certain set of Services. Potential Service Providers include consumer electronic devices, such as cell phones, PDAs, portable media players and home access routes, as well as network operators (such as cable tops), network providers cellular, network-based retailers and content license providers. Inferíase of Service - a well-defined way of interacting with one or more Services. Service Connection - encapsulates a specific way to communicate with a Service, including the conventions and protocols used to invoke a Service Interface. This can be represented in a variety of well-defined ways, such as the WS-I standard XML protocol, RPC based on the WSDL definition, or a function invocation from a DLL. Service Access Point (SAP) - encapsulates the necessary functionality to allow a Node to perform a Service Invocation Request towards an objective set of Service Provider Nodes and receive a set of Responses. Workflow Classifier (WFC) - an Orchestration Mechanism -of Seqicios -qua -provides ut? A "" ínfe "rfáf * e -cOfnún that allows a Node to handle and process collections of Requests and Answers in relation to invocations of Service This interface provides the basic building blocks for orchestrating Services through the handling of Messages associated with the Services In the context of a particular application, such as digital rights management (DRM), a typical profile could include various DRM-related services (described below) for the following set of authority objects and content protection, which represents entities in the system, protects the content, associates use rules with the content and determines whether access can be granted when requested: Content Reference - encapsulates the representation of a reference or signal of a content topic. Such a reference typically levels out other standardized ways of describing form, location of content, etc. DRM Reference - encapsulates the representation of a reference or signal from a description of a digital rights management format. Link - links between entities (for example, Nodes). Content - represents media or other content. Content Key - represents encryption keys used to decrypt the Content. Control - represents rules of use or others that govern * ~ ^ í "inter action with the Content:" ", - ^ _- ---- ___ = _ ,., -, ==, - - = - Controller - represents Associations between Control and Content Objects Projector Key - represents associations between Content and 5 ContentClass objects In a modality, a core profile includes definitions for some or all of the following Basic Services: Authorization - a request or response to authorize a certain participant to have access to a Service 10 Authority - The process of exercising authoritative or dominant influence over a certain topic (for example, a music file, a document, or a Service operation), such as the ability to download and install a software update The Authority typically interacts with Services that provide functionality, 15 such as trust handling, policy management, and content protection. Message Routing - a Request or Response to provide message routing functionality, including the ability to make the Service Provider Node 20 forward the message or collect and assemble messages. Node Registration - a Request or Response to carry out registration operations for a Node, thus allowing the Node to be discovered through an Intermediate Node. Node Discovery (Query) - a Request or 25 Response related to the discovery of Nodes.

^ "" Notification - A "So? Icft? ^ D Or" Réspuei a "to send or supply objective messages of Notification to a given set of Nodes.Exchange of Security Credentials - a Request or Response related to allowing the Nodes exchange information related to security, such as key pairs, certificates or the like Service Discovery (Query) - a Request or Response related to the discovery of Services provided by a certain set of one or more Nodes Service Orchestration - The assembly and Coordination of services in manageable services, coarser grain, reusable components or complete applications that adhere to rules specified by a service provider Examples include rules based on the identity of the provider, type of service, method by which has access to the Services, order in which the Services are composed, etc. Confidence Management - provides a joint common use of conventions and protocols to create authoritative and reliable contexts for interactions between nodes. In some modalities, NEMO's Confidence Management can level and / or expand existing security specifications and mechanisms, including Security-WS and Policy-WS in the network services domain. Update - represents a Request or Response related to receiving a functionality update. In a purely abstract modajidadisas.te s rvici.os.ies, providing with other profiles concrete representations. 1. 5. Illustrative Interaction Between Nodes As will be discussed in more detail below, the basic logical interaction between two system nodes, a service requester and a service provider, typically includes the following sequence of events. From the perspective of the service requesting node: The service requesting node makes a service discovery request to locate any NEMO-enabled node that can provide the necessary service through the use of specified service connections. A node can choose to hide information about discovered services. The interface / mechanism for the discovery of services between nodes can be just another service that a NEMO node chooses to implement. Once the candidate service providing nodes is found, the requesting node may choose to dispatch a request to one or more of the nodes that provide services based on a specific service connection. In one modality, two nodes that wish to communicate securely with each other will establish a trust relationship for the purpose of exchanging WSDL messages. For example, they can negotiate a set of trusted, trusted credentials (for example, X.500 certificates, device keys, etc.) that can * ~ "" "" T ¡T "en en en en en en en en en en en" "" "" "" of authorization, establishment of a secure channel, etc. In some cases, the negotiation of these credentials can be an implicit property of the service interface connection (for example, WS- 5 Security if WS-I-XML Protocol is used, or an SSL request between two well-known nodes.) In other cases, the negotiation of trusted credentials can be an explicitly separate stage In one modality, it depends on a given node to determine which credentials are sufficient to interact with another node, and to make the decision that a given node can be trusted. The requesting node creates the appropriate WSDL request message (s) corresponding to the requested service. Once the messages are created, they are dispatched to the target service provider (s) node (s). The style of The communication of the request can be, for example, synchronous or asynchronous RPC style, or message oriented on the basis of the service connection. The dispatch of service requests and the receipt of responses can be made directly by the device or through the NEMO Service Representative. The service representative (described below) provides an abstraction and interface for sending messages to other participants and can hide certain service connection topics, such as supported message formats, transport mechanisms, message routing topics, etc. After dispatching an application, the requesting node will typically receive one or more answers. Depending on the specifics of the connection-da-int-erfaße-of the service-the preferences of the requesting node, the response (s) can be returned in a variety of ways including, for example, an RPC style response or a notification message. The response, en route to the target node (s), can pass through other intermediate nodes that can provide a number of relevant services, including, for example, routing functions, trust negotiation, classification and correlation, etc. The requesting node validates the response (s) to ensure that it adheres to the trust semantics negotiated between it and the service provider node. The appropriate processing is then applied based on the type of payload and content of the message. From the perspective of the service provider node, the sequence of events would typically include the following: Determines whether the requested service is supported. In one embodiment, the NEMO work structure does not dictate the style or granulation capacity of the way a service interface represents an entry point to a service. In the simplest case, a service interface can ambiguously represent a given service and the act of connecting and invoking it can constitute service support. However, in some modalities a single service interface can handle multiple types of requests; and a given type of service may contain additional attributes that need to be examined before a determination can be made that the TTdf_b sopoHek'a ^ specifically desired functionality. In some cases, it may be necessary for the service provider to determine whether to trust the requesting node and negotiate a set of trusted trust credentials. In a modality, regardless of whether the service provider determines trust, any policy associated with the service interface will still apply. The service provider determines and dispatches authorization request (s) to that node (s) responsible for authorizing access to the interface in order to determine whether the requesting node has access. In many situations, the authorizing node and the node providing the service will be the same entity, and the dispatch and processing of the authorization request will be local operations invoked through a lightweight service interface connection, such as a point Function entry C. After receiving the authorization response, if the requesting node is authorized, the service provider will make the request satisfied. If not, an appropriate response message could be generated. The response message is returned based on the service interface connection and the preferences of the requesting node. En route to the requesting node, the message may pass through other intermediate nodes that can provide necessary or "value-added" services. For example, an intermediate node could "provide routing, trust negotiation, or provision to a notification processor node that it can deliver the message in an acceptable manner to the requesting node." An example of a "value-added" service is a service of coupon that attaches coupons to the message if you know about the interests of the requesting node. 2. SYSTEM ARCHITECTURE Consider a sample mode of the structure of the NEMO system, as illustrated in FIG. 1, which implements a DRM application. As noted above, the NEMO nodes can interact when processing service invocation requests and receiving responses. The NEMO work structure supports the construction of diverse and rich communication patterns that vary from a simple point-to-point interaction with a single service provider to a complex addition of a choreographic set of services from multiple service providers. In the context of FIG. 1, the NEMO nodes interact with each other to provide a variety of services that, in the aggregate, implement a music licensing system. The music stored in the Consumer Music Archive 1 10 can be extracted by the Network Music Retailer 120 and provided to end users in their homes through its 130 Domestic Access Access Way. Music from the Music Archive of the Consumer and IO may include rules that dictate the conditions under which such music may be provided to the Network Music Retailer 120 and subsequently to others for additional use and distribution. The Domestic Access Access Way 130 is the vehicle by which such music (as well as video and other content) can be played, for example, on the home PC of! user (e.g., through the Software Video Player of the PC 140) or on a user's portable playback device (e.g., Portable Music Player 1 50). A user could travel, for example, with the Portable Music Player 150 and obtain, through a wireless Internet connection (for example, Digital Rights License Service 160), a license to acquire additional songs or replay songs exist for additional times or even add new features to the Portable Music Player 150 through the Software Update Service 170. The NEMO nodes can interact with each other and with other devices, in a variety of different ways. A NEMO host, as illustrated in FIG. 2a, it is a certain type of machine or device that hosts at least one NEMO node. A guest may reside within a personal area network 210 or at a remote location 220 accessible through the Internet. A guest could, for example, be a 230 server, a 240 desktop PC, a 250 laptop, or a 260 personal digital assistant.

- - A node - NEMO - is a software agent that can provide services to other nodes (such as a guest 235 that provides a network service to third parties) as well as invoke other node services within the structure managed by NEMO . Some nodes 270 are tied to another guest through a dedicated communication channel, such as Bluetooth. These guests 240 and 250 are equipped with network connectivity and sufficient processing power to present a virtual node to other participating NEMO nodes. As illustrated in FIG. 2b, a NEMO node can be a complete parity within the local or personal area work network 210. The nodes share the symmetric ability to expose and invoke services; however, each node generally does not offer identical sets of services. The nodes can announce and / or consult in a specific way about the services they carry out. If an Internet connection is presented, as shown in FIG. 2c, then the local NEMO nodes (for example, within the personal area work network 210) can also access the remote node 220 services. Depending on the configuration and policies of the local network, it is also possible that nodes local and remote (for example, capable NEMO guests on the Internet 280) interoperate as NEMO parities. As illustrated in FIG. 2d, not all NEMO nodes can be found in hosts capable of communicating with other hosts, "whether they are" local "or remote, a NEMO guest 280 can provide an access service through which a node can invoke the services of another, such as the interleaved node 285 or nodes in the personal area work network 21 0. As illustrated in FIG.2e, a node 295 in an interlaced device can access the services of other nodes through of a path, as discussed above, can also be accessed by other nodes through a representative service on another host 290. The representative service creates a virtual node that runs on the NEMO guest. be complete NEMO parities As illustrated in FIG 2f, a NEMO host can provide dedicated support for interleaved devices through NEMO node adapters A private communication channel 296 is used between the NEMO device adapter / host 297 and the interleaved node 298 by the use of any suitable protocol. The interleaved node 298 does not see, nor is it visible to, other NEMO parity nodes. We next consider the exemplary digital rights management (DRM) functionality that can be provided by devices enabled by NEMO in certain modalities, or that can be used outside the NEMO context. As previously described, one of the primary purposes of a preferred embodiment of the NEMO system structure is to support the development of interoperable, secure interconnections between related services "means encompassing * levels of faith" (T oriented). In addition to the connectivity of the service, interoperability between media-related services will often require coordinated use rights management, as applied to the content available through those services. Exemplary DRM machine described herein may be used in combination to achieve interoperability which allows devices based on the NEMO structure to provide consumers with the perception of an experience of use and which becomes seamless, even on the surface of a media format infrastructure and heterogeneous DRM In the context of a DRM application, such as it is illustrated in FIG. 3, a network of DRM devices enabled by NEMO may include content provider / server 310, which packages the content for other DRM devices, as well as consumer PC player 330 and consumer PC packager / player 320, which can not only play protected content but can also package content for delivery to a portable device 340. Within each DRM device, the DRM machine carries out specific DRM functions (e.g., reinforces license terms, supplies keys for host application, etc.), and it depends on the guest's application for those services that can be provided more efficiently by the host, such as encipption, file management. As will be discussed in more detail below, in one embodiment the DRM machine includes a virtual machine (VM) designed to determine whether certain actions on protected content are permissible. This Control VM can be implemented as a simple stack-based machine with a minimum set of instructions. In one mode, it is able to carry out logical and arithmetic calculations, as well as query status information from the host environment to verify parameters such as system time, meter status and so on. In one modality, the DRM uses an algorithm based on graphs to verify the relationships between entities in a DRM value chain. FIG. 4 illustrates a conceptual modality of such a graph. The graph includes a collection of nodes or vertices, connected by links. Each entity in the system can be represented by a vertex object. Only entities that need a reference by link objects. or being the recipient of cryptographically objective information, they need to have corresponding vertex objects. In one embodiment, a vertex typically represents a user, a device or a group. The vertex objects also have associated attributes that represent certain properties of the entity associated with the vertex. For example, FIG. 4 shows two users (Xan and Knox), two devices (the Mac and a portable device) and several groups representing entities (members of the Carey family, members of the public library, subscribers to a particular music service, approved devices by RIAA and devices manufactured by a specific company). Each of these has a vertex object associated with it. The semantics of the links may vary in a specific way to the application. For example, the led edge of the Mac vertex to the Knox vertex may mean that the Knox owns the Mac. The Knox edge to the Public Library may indicate that Knox is a member of the Public Library. In one modality, the DRM machine does not impose or interpret this semantics - it simply determines the existence or non-existence of trajectories within the graph. This graph of vertices can be considered an "authorization" graph since the existence of a trajectory or relationship (direct or indirect) between two vertices can be interpreted as an authorization for a vertex to access another vertex. For example, because Knox is linked to the Carey family and the Carey family is linked to the Music Service, there is a path between Knox and the Music Service. The vertex of the Music service is considered reachable from another vertex when there is a path from that vertex to the Music Service. This allows a control that allows access to protected content to be written based on the condition that the Music Service may be reachable from the portable device on which the application requesting access is running (for example, a guest application). DRM client).

For example, a content-owner can create "a control program to be interpreted by the Control VM that allows a particular piece of music to be reproduced if the consumer device is owned by a member of the Public Library. and is approved by RIAA When the Control VM running on the device evaluates this control program, the DRM determines if there are links between the Portable Device and the Public Library, and between the Handheld Device and the RIAA Approved. and vertices of the graph can be static and conform devices or they can be dynamic and discovered through services that communicate with the host application.Without imposing semantics on vertices and links, the DRM machine can allow great flexibility. to many models of use, from policy systems based on traditional delegation to authorized domains and personal area networks. In one mode, the DRM client can also reuse the authorization graphic for content protection key derivation. System designers can choose to allow the existence of a link to also indicate the sharing of certain cryptographic information. In such cases, the authorization chart can be used to derive content keys without explicit cryptographic redirection to consumer devices. - 3. - ARQUITECTURTTDl? - ^ isC O 3.1. Overview Any type of device (physical or virtual), including consumer electronic equipment, networking services, or 5 software clients, can potentially be enabled by NEMO, which means that the functionality of the device can be extended in such a way that allow participation in the NEMO system. In one embodiment, a device enabled by NEMO (node) is conceptually comprised of certain standard modules, such as 0 is illustrated in Fig. 5a. The API 510 Native Services represent the logical set of one or more services that the device implements. There is no requirement that the NEMO node exposes any service directly or indirectly. The Implementation of Native Services 5 520 represents the set of corresponding implementations for the native API services. The Service Access Point 530 provides support for invoking exposed service interfaces. It encapsulates the functionality needed to allow a NEMO node to perform a 0 service invocation request to an objective set of NEMO service provider nodes and to receive a set of responses. The nodes enabled by NEMO can use various discovery, name resolution and transport protocols, which require the creation of a flexible and expandable communication API. The Service Access Point can be realized in a variety of ways directed to an environment of "executing and executing" a particular application structure A common generic model for its interface will be an interface capable of receiving messages XML in some form and return XML messages Other models with 5 more native interfaces can also be supported The NEMO 540 Service Adaptation Stratum represents an optional stratum through which there is access to an exposed subset of native entity services by using one or more connections that can be discovered. a level of abstraction over API of native services, allowing a service provider to more easily support multiple types of service interface connections. In situations where a service adaptation stratum is not presented, it may still be possible to interact with the service directly through the Point Service Access 530 if it supports the necessary communication protocols. The Service Adaptation Stratum 540 provides a common way for service providers to expose services, process requests and responses, and orchestrate services in the NEMO structure. This is the logical point at which services are published and provides a foundation on which to implement other specific service interface connections. In addition to providing a common way to expose native services from the service provider to other enabled nodes by NEMO, the Service Adaptation Stratum 540 also provides a "parent" place in it, which can be used to support additional service interface connections 560, as illustrated in FIG 5b. By supporting additional service interface connections, a service provider increases the likelihood that a compatible connection will be capable of being negotiated and used either by a Service Access Point or through some other native API. Referring again to FIG. 5a, the Workflow Classifier 550 provides service message support and service orchestration support management, providing a common interface that allows a node to handle and process collections of request and response messages, this interface, in turn, provides the basic building blocks to orchestrate services through the handling of messages associated with those services. ementa by a node that supports message routing functionality as well as the middle row and message classification. In some modalities, the NEMO structure includes a collection of optional support services that facilitate an important participation in the work network. Such services can be classified according to various types of functionality, as well as the types of entities that require such services (for example, services that support client applications, as opposed to those needed by service providers). Typical support services include the following: ~ RutTnas ^ ~ "~ of ^ ~~" * Forming and WSDL Manipulation '-provide functionality for the creation and manipulation of service messages based on WSDL. Service Hiding - provides a common interface that allows a node to manage a collection of maps between discovered nodes and the services they support. Notification Processor Interface - provides a common service provider interface to extend a NEMO node that supports notification processing for some well-defined notification processing machines. Accessory Support Functionality - which includes routines to generate message IDs, time stamps, etc. 3. 2. Basic Node Interaction Before examining the individual architectural elements of NEMO nodes in more detail, it is useful to understand the way in which such nodes interact and communicate with each other. The various communication styles are supported, ranging from synchronous and asynchronous RPC style communication, to one-way interface invocations and client calls. Supply Style RPC Asynchronous - this model is particularly suitable if there is an expectation that meeting the demand will take a long period of time and the client does not want to wait. The client submits a request in the hope that it will be processed in an asynchronous manner by any service provider node. In this case, the endpoint provider of "service may respond by indicating that it does not support this model or, if the service provider node supports this model, it shall return a response from which it shall transport a ticket that may be submitted to the node providing service given in requests In order to determine if it has a response to the client's request, in a modality, any endpoint service provider that supports this model is forced to hide answers to pending client requests based on an internal policy. recover a ticket associated with such request and there is no response available, or the response has been discarded by the service provider node, then an appropriate error response is returned. In this modality, it is up to the client to determine when he will make such follow-up requests in an attempt to recover the ticket for the answers. Supply Style Synchronous RPC - the client submits a request and then waits for one or more responses to be returned. An endpoint enabled by NEMO that provides service can respond, indicated that it does not support this model. Efe Style Message-Based Supply - the customer submits a request indicating that he or she wishes to receive any response through a message notification associated with one or more notification management service interfaces. An endpoint enabled by NEMO that provides service may respond indicating that it does not support this model.

From the application perspective give? Anyway, none of the above interaction patterns need an architecture that must block and wait for answers, or must vote explicitly. It is possible to use interweaving or other platform-specific mechanism to model semantics of both blocking and non-blocking with the previous delivery style mechanism. Also, none of the above styles intends to directly address the issues associated with the latency of a given communications channel - only the potential latency associated with the actual satisfaction of a request. The mechanisms to deal with the issues associated with the latency of the communications channel should be addressed in the specific implementation of a component such as the Service Access Point or within the client's implementation directly. 3. 3. Service Access Point As noted above, a Service Access Point (SAP) can be used as a reusable, common API for service invocation. You can encapsulate the negotiation and use of a transport channel. For example, some transport channels may require SSL session establishment on RCP / IP, while some channels may support only non-UDP / IP dependent communication, and still others may not be entirely IP-based. An SAP can encapsulate the discovery of an initial set of NEMO nodes for message routing. For example, a box of higher cable parameters can have a dedicated connection to the network and have all messages flow through a specific route and intermediary. A portable media player in a home network can use a UPnP discovery to find multiple nodes that are directly accessible. Clients may not be able or may not choose to converse directly with other NEMO nodes when exchanging XML messages. In this case, a version of the SAP can be used that exposes and uses any native interface that is supported. In a preferred embodiment, the SAP pattern supports the following two common communication models (although the combinations of the two, as well as others, can be supported): (i) Based on Message (as discussed above) - where the SAP forms XML request messages and directly exchanges NEMO messages with the service provider through some interface connection; or (ii) Native - where SAP can interact with the service provider through some native communication protocol. The SAP can be internally translated into / from XML messages defined anywhere within the structure. A sample interaction between two parity nodes NEMO is illustrated in FIG. 6a. The client node 610 interacts with the service provider node 660 through the use of the NEMO service access point (SAP) 620. In this example, the network and standard service protocols are both used to expose services and for transport. The service provider node 660 uses its 670 network services "stratum" (using, for example, "messages" based on SOAP and WSDL) to expose its services to such clients. as the node 610. The network services layer 630 of the client node 610 creates and interprets SOAP messages, with the help of the graphical representation layer 640 (which represents SOAP messages to and from the SAP 620 interface) and the processing stratum of the client. trust management 650 (which could, for example, level WS security through the use of credentials carried within SOAP headers). Another exemplary interaction between NEMO nodes is illustrated in FIG. 6b. The service provider node 682 interacts with the client node 684 through the use of SAP 686. In this example, the service provider node 682 includes a different but interoperable trust management stratum 684. In particular, the service provider node 682 it includes both a trusted machine 688 and an authorization machine 690. In this example, the trusted machine 688 could be generally responsible for carrying out the encryption and description of SOAP messages, for verifying digital certificates and for carrying out other basic cryptographic operations, while the 690 authorization machine could be responsible for making decisions of higher level policy. In the example shown in FIG. 6b, the client node 684 includes a trusted machine 692, but not an authorization machine. Thus, in this example, the client node 684 could be able to carry out basic cryptographic operations and reinforce relatively simple policies (for example, policies related to the level of message authenticity, confidentiality or the like), but they could depend on the service provider node 682 to evaluate and enforce higher order policies dictating the client's use of and interaction with the services and / or content provided by the service provider node 682. It should be appreciated that FIG. 6b is provided for purposes of illustration and not limitation and that in other modalities the client node 684 could also include an authorization machine, as would be the case if the client needed to adhere to a set of obligations related to a specific policy. In this way, it can be seen that the different NEMO parities may contain different parts of the trust management structure, depending on their requirements. FIG. 6b also illustrates that the communication link between nodes can be transport agnostic. Even in the context of a SOAP processing model, any suitable coding of data and / or processing rules can be used. For example, the XML security model could be replaced with another security model that supports a different encoding scheme. A Service Access Point can be implemented in a variety of ways, such as within the limits of a client (in the form of a shared library) or outside the limits of the client (in the form of an agent running on a different process). The exact form of the implementation of the Service Access Point can be adapted to the needs of a type of platform "ma-o" clientep e ~ s ~ p "e" cíftcsr 'From the perspective of "a client, ~ the use of the Service Access Point may be optional, although in general it provides an important utility, as illustrated below: The Service Access Point can be implemented as a static component that supports only a fixed set of service protocol connections, or can be able to support new connections dynamically Interactions involving the Service Access Point can be characterized from at least two perspectives - one side of the client that the requesting participant uses and one service side that interacts with other endpoints enabled by NEMO (nodes) In a client-side mode, illustrated in FIG 7a, the Service Access Point 710 directly exchanges XML messages with the 720 client. The client 720 forms 740 request messages directly and submits them to the 71 0 Service Access Point, which generates and sends one or more response messages 750 to the 720 client, where they are collected, analyzed and processed. The client 720 may also submit (when making requests) the explicit set (s) of connections to service 730 to use the addressing of the supply of the request. These service connections may have been obtained in a variety of ways. For example, the client 720 may perform service discovery operations and then select which service connections are applicable-or may use the information obtained from previous responses. In another embodiment of the client side, illustrated in FIG. 7b, the 760 Service Access Point directly supports a native 770 protocol of the 780 client. The 760 Service Access Point will translate the messages internally between XML and that native 770 protocol, thus allowing the 780 customer to participate within the NEMO system. To perform such support, the native 770 protocol (or a combination of native 770 protocol and the execution environment) must provide any necessary information in any way to the 760 Service Access Point, which generates an appropriate request and, if necessary , determines a connection to the appropriate objective service. On the service side, multiple interaction patterns can be supported between a Customer Service Access Point and endpoints enabled by NEMO that provide service. As with the client side, the interaction patterns may be adapted and may vary based on a variety of criteria, including the nature of the request, the underlying communication network and the nature of the application and / or transport protocols associated with it. any objective service connection. In FIG. 7c a relatively simple type of service-side interaction pattern is illustrated in which the Service Access Point 71 1 communicates directly with the serving provider node 7 t ti a way of point ^ irCrntoY Returning to FIG. 7d, the Service Access Point 721 can directly initiate communication with (and can receive responses directly from) multiple potential service providers 725. This type of interaction pattern can be implemented by transmitting multiple client service connections to be used by the client. Service Access Point 721; or a broadcast or multiple transmission network could be used by the Service Access Point 721 to transmit messages. Based on the preferences specified in the request, the 721 Service Access Point may choose to collect and classify responses or simply return the first acceptable response. In FIG. 7e, the 731 Service Access Point does not communicate directly with any endpoint, service provider, target, 735. Instead, requests are routed through an intermediate node 733 that transmits the request, receives any response, and transmits again to the 731 Service Access Point. Such an interaction pattern may be desirable if the Service Access Point 731 is unable or does not wish to directly support any of the service connections associated with the endpoints providing service 735, but may establish a relationship with the intermediate node 733, the which is able to act as a gateway. Alternatively, the client may not be able to discover or otherwise determine the service connections for any suitable service "provider" node, but may be able to allow the intermediate node 733 to discover any provider of services. adequate service. Finally, the 731 Service Access Point may wish to take advantage of the intermediate node 733 because it supports stronger collection and classification functionality, which in turn allows for more flexible communication patterns between the 731 Service Access Point and the service providers such as endpoint nodes 735. In addition to the previous, basic service-side interaction patterns, combinations of such patterns or new patterns may be implemented within the Service Access Point. Although the Service Access Point attempts to provide a common interface, its implementation typically relates to the characteristics of the communication models and the associated protocols, used by the endpoints enabled by NEMO, given. In practice, the Service Access Point can be used to encapsulate the logic for handling ordering and de-ordering of data related to I / O, such as serial ordering objects for suitable representations, such as an XML representation (with a format expressed in WSDL), or one that wraps objects encoded by XML in the appropriate format. In a preferred embodiment, the SAP also encapsulates logic for communication through one or more supported application, session and / or transport protocols, such as invocation - "service over HTTP using SOAP wrap." - - - - - - Finally , in some modalities, the SAP can encapsulate logic for the message integrity and confidentiality ratio, such as support for the establishment of SSL / TLS sessions and / or signature / verification of data through standards such as Signature-XML and Encryption -XML When the specific address of a service interface is unknown or not specified (for example, when a service is invoked through multiple nodes based on some search criteria), the SAP can encapsulate the logic to establish a Initial connection to an initial / default set of NEMO nodes where services can be discovered or resolved The following is an exemplary, non-limiting mode of API mapping of high level exported by an SAP modality: ServiceAccessPoint :: Create (EnvironmentO)? ServicePointService - this is an individual interface that returns an initialized instance of an SAP. The SAP can be initialized based on an optional set of environmental parameters.

ServicePointService :: IvokeService (MessageRequest Service, Boolean)? ServiceResponse Message - a synchronous service invocation API is supported where the client (using WSDL) forms an XML service request message, and receives an XML message in response. The API also accepts a Boolean identifier that "" indicates whether or not the client should e-request a response. Normally, the identifier will be true, except in the case of messages without associated response or messages to which the response will be returned asynchronously through another channel (such as through 5 notification). The resulting message can also carry some resulting error condition. ServiceAccess Point:: Apply IntegrityProtection (Boolean, DescO)? Boolean - This API allows the caller to specify whether integrity protection should be applied and to which 0 elements a message should be applied. ServiceAccess Point:: SetCallsCall (SignCallCall) CallCall VerificationSignature, 5CallCall, CallKeyDescription) - »Boolean As indicated in the previous APIs, when a message is sent or received, it may contain objects that require integrity or confidentiality protection. This API allows the client to establish certain necessary hooks between themselves and the SAP to allow the SAP to obtain keys associated with a particular type of trust management operation. In one modality, the interface is based on calls that support integrity protection through digital signature and verification, and confidentiality through encryption - and description. In a modality, "" cacTa "" one "of the" calls is in the form of: CallCall (DescClave)? Key where DescIce is an optional object that describes the required key (s) and returns a list of appropriate keys. Signatures are validated as part of receiving response service messages when using the ServiceInvoke API (...). If a message element fails verification, an XML message can be returned from lnvocarServicio (...) indicating this status and the elements that failed the verification. 3. 4. Service Adaptation Stratum As noted above, the Service Adaptation Stratum provides a common way for service providers to expose their services, process requests and generate responses to services, and orchestra services in the NEMO structure. It also provides a foundation upon which other connections to a specific service interface can be implemented. In one mode, WSDL is used to describe a service interface within the system. Such a service description could, in addition to defining the way to connect to a service in a particular interface, also include a list of one or more authorization service providers that will be responsible for authorizing access to the service, a flag for a semantic description of the purpose and use of the service, "yun abetes cñptíorf" of the "orqué = staci" órT ~ nec "e ~ áa ¡a ~ for" compound services resulting from the choreographic execution of one more different services. In addition to serving as the logical point at which services are exposed, the Service Adaptation Stratum also preferentially encapsulates the specific representations of the NEMO data types and objects specified in the NEMO service profiles for platforms that are supported by a participant. dice. It also contains a mechanism to graphically represent messages related to services for the implementation of appropriate native services. In one modality, the NEMO structure does not dictate the way in which the Service Adaptation Stratum is performed for a given platform or participant. In situations where a service provider node does not require translation of its native service protocols - that is, exposure of its services only to client nodes that can communicate through the native protocol - then that service provider node does not need to contain a stratum of Adaptation of Service. Else, its Service Adaptation Stratum will typically contain the following elements, as illustrated in FIG. 8: Input Points - a layer that encapsulates the entry points to the service interface 810 and associated WSDL connections. Through these access points, other nodes invoke "services, pass data", "parameters" and "collect results." Message Processing Logic - a layer 820 that corresponds to the logic for message processing, which typically contains a 825 message pump that directs message processing, a certain type of XML 826 data connection support, and low-level XML analyzer and 827 data representation support. Native Services - a stratum that represents the available native services (about which the corresponding service messages are represented), including a native services API 830 and corresponding implementation 840. 3. 5. Workflow Classifier In a preferred mode, a Workflow Classifier (WFC) helps satisfy most non-trivial NEMO service requests by coordinating the flow of events of a request, handling any associated data that includes transient and intermediate results, and reinforcing the rules associated with compliance. Examples of this type of functionality can be seen in the form of transaction coordinators ranging from simple transaction monitors in relational databases to more generalized monitors, as seen in Microsoft MTS / COM +. In one modality, the Workflow Classifier is a programmable mechanism through which the NEMO -orqa nodes are the processing and fulfillment of invocations Y_e service. The WFC can adapt to specific NEMO node characteristics and requirements and can be designed to support a variety of functionality ranging from traditional message rows to more sophisticated distributed transaction coordinators. A relatively simple WFC could provide an interface to store and retrieve messages related to arbitrary services. By building this, it is possible to support a wide variety of functionality, including (i) collection of service requests for more efficient processing; (ii) simple addition of service responses in a composite response; (iii) manual orchestration of multiple service requests and service responses in order to. create a composite service; and (iv) automated orchestration of multiple service demands and service responses in order to create a composite service. A basic service interaction pattern begins with a service request that arrives at some NEMO node through the Service Adaptation Stratum of the node. The message is derived from the WSDL Message Bomb that will initially direct and in turn be directed by WFC to satisfy the request and return a response. In even more complex scenarios, satisfying a service request may require multiple messages and responses and the participation of multiple nodes in a coordinated manner. The rules for processing requests can be expressed in the system's service description language or by using ^ -other service-descriptive standards-such as BPEL. When a message is given to WFC, the WFC determines the correct rules to process this request. Depending on the WFC implementation, the service description logic can be represented in the form of a fixed-state machine for a set of services that the node exposes or can be represented in ways that support the processing of an expression in a freer manner. the logic of service processing. In a preferred embodiment, the WFC architecture is modular and expandable, supporting connections. In addition to interpreting service composition and processing rules, the WFC may need to determine whether or not NEMO messages are used in the context of initiating a service satisfaction processing lifecycle, or as input into the chain of a transaction. in progress. In one modality, NEMO messages include IDs and metadata that are used to make these types of determinations. NEMO messages can also be extended to include additional information that can serve a specific transaction, facilitating the processing of messages. As discussed in more detail below, notification services are directly supported by various modalities of the NEMO system. A notification represents a message addressed to interested nodes enabled by NEMO, received at a service interface designated for processing. The - - - - notifications - can transpose a diverse set of types "d" and "payload to carry information and the criteria used to determine if a node is interested in a notification are expandable., including criteria based on identity as well as 5 based on events. In one embodiment, illustrated in FIG. 9a, a node of NEMO service provider 910 provides a service that requires an orchestration process through its Workflow Sorter 914 (for example, the collection and processing of 10 results from two other service providers) to satisfy an application for that service coming from the client node 940. When the application enabled by NEMO 942 in the client node 940 initiates a request to invoke the service provided by the service provider 910, the Workflow Classifier 15 914 in turn generates messages for initiate their own requests (in the name of application 942), respectively, for Service Provider "Y" 922 on node 920 and Service Provider "Z" 932 on node 930. Workflow Classifier 914 collects and then processes the results of these other two nodes 20 service providers in order to satisfy the original request of the client node 940. Alternatively, A requested service may not require the services of multiple service provider nodes, but may instead require multiple rounds or phases of service.

The communication between the service provider node and the client node ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ the service provided by the service provider 910, the Workflow Classifier 914 is in turn engaged in multiple communication phases 950 with the client node 940 in order to satisfy the original request, for example, the Workflow Classifier 914 can generate and send messages to the client node 940 (through Access Point 944), receive and process the responses and then generate additional messages (and receive additional responses) during the subsequent communication phases, finally satisfying the node's original request client 940. In this scenario, Workflow Sorter 914 is used by the 910 service provider to maintain the trace (perhaps based on a session ID service-specific or transaction ID as part of the service request) whose phase of the operation is with the client for the correct processing. As noted above, a state machine or mechanism or similar technique could be employed to process these multiple communication phases 950. FIG. 9c illustrates a relatively basic interaction mode, within the service provider node 960, between the Workflow Classifier 914 and the Message Pump 965 (within the Service Adaptation Stratum of the node, not shown). As noted above, Workflow Classifier 914 processes Yma Y. ma ^ "'s'bTíc ilu is" o'e "" servicTcf ^ d. * "' And" "generates 964 responses, using a storage mechanism and 966 recovery to maintain the state of this orchestration process In this simple example, Workflow Classifier 914 is capable of processing multiple requests and service responses, which could be implemented with a fairly simple state machine. For more complex processing, FIG 9d illustrates a node architecture that can both direct and be directed to perform service orchestration, such functionality includes the collection of multiple service requests, the addition of responses in a response from composite, and the orchestration either manual or automated of multiple requests and service responses in order to create a composite service.A variety of scenarios can be supported by the archit The information surrounding the Workflow Classifier 914 in FIG. 9d. For example, by having a NEMO node that combines its functionality with that of an external 970 coordinator who understands the semantics of process orchestration (such as a Business Process Language machine directed by a high-level description of the processes of business associated with services) or semantics of resource use (such as the Resource Description Structure machine that can be addressed by the semantic meaning of resources in relation to each other), it is possible to create more powerful services above the most simple The External processors ^ Customary BPL972 and / or RDF973 can level the external message pump 975 to execute process descriptions through a 966 manual orchestration process, that is, one that involves human intervention. In addition to transmitting in a manually directed process that depends on an operation of the external coordinator in conjunction with a message pump of the NEMO node, it is also possible to create an architecture where the modules can be directly integrated with the Workflow Classifier 914 in order to support an automated 968 service coordination and orchestration form. For example, for regular types of service orchestration patterns, such as those represented in BPEL and EBXML and communicated in network service connections associated with a service interface, the Workflow Classifier 914 can be directly addressed by a description and collection of 967 request and response messages that arrive on time. In this scenario, a composite response message is pushed to the 965 Message Pump only when the state machine associated with the given orchestration processor plug (for example, BPEL 982 or EBXML 983) has determined that it is adequate. Below is a modality of a relatively high-level API description, exported by a NEMO Workflow Classifier modality: JobFlow Classifier :: Create (EnvironmentO)? ClassifierFlujsWork - this is an individual interface "that returns an initialized instance of a WFC.The WFC can be initialized based on an optional set of environmental parameters. ClassifierFlow Job :: Store (KeyD, Message XML) - > Boolean - this API allows the caller to store a service message within WFC through a specific set of keys. Classifier Workflow :: RetrieveCorve (KeyD, XML Message)? XMLO message - this API allows the caller to retrieve a set of messages through a set of specific keys. Returned messages are no longer contained within the WFC. Flow Sorter Job :: Parity by Key (Claven, XML Message)? XMLO message - this API allows the caller to retrieve a set of messages through a specific set of keys. The returned messages are still contained within the WFC. Flow Sorter Job :: Delete ()? Boolean - this API allows the caller to delete any message stored within the WFC. As an alternative to the relatively rigid BPEL orchestration standard, another modality could allow an orchestration description based on more consistent XML - for example, for a more dynamic application, such as distributed search. Consider the following description that could be "interpreted by" uin "? Ta" "s1fi?: Dbr from NEMO Workflow (and could possibly even replace an entire service given a sufficiently rich language): <WSDI> <Descriptor NEMO Orchestration < Flow Control > for example, RUN Service A; If Result = Yes then Service B; If Not Service C < State / Shared Context > eg, Device Status < Transactions > for example, State, Price Reduction, etc. < Trust / Authorization > Observe Trust not necessarily transitive 3. 6. Exemplary DRM Machine Architecture In the context of the various embodiments of the NEMO node architecture described above, FIG. 10 illustrates the integration of a modular mode of a DRM 1000 machine into a NEMO content consumption device, thus facilitating its integration into many different software environments and devices. The guest application 1002 typically receives a request to access a particular piece of content through its user interface 1004. The guest application 1002 then sends the request, along with the relevant DRM-machine objects - ( -preferably "opaque" to "the application" of the "guest", to the DRM 1000 machine. The DRM 1000 machine can make requests for additional information and cryptographic services to host the service module 1008 through good interfaces. defined. For example, the DRM 1000 machine can ask guest services 1008 if a particular link is trusted, or it can request that certain objects be decrypted. Some of the information requested may be remote, in which case the guest services 1008 may request the information of network services through a service access point 1014. Once the DRM 1000 machine has determined that an operation is allowed in particular, this indicates and returns any cryptographic key required to host .services 1008 which, under the direction of the guest application 1002, depends on the content services 1016 to obtain the desired content and manage its use. Guest services. 1008 could then initiate the media conversion process 1010 (for example, by reproducing the content through speakers, displaying the content, on a screen, etc.), coordinated with cryptographic services 1012 as necessary. The system architecture illustrated in FIG. 10 is a relatively simple example of how the DRM machine can be used in applications, but it is only one of many possibilities. For example, in other modalities, the DRM machine can be integrated into packaging applications under the dictation - ---- of ^ sfernas "of handling policies relativárhenté" s frsTicáa'bsY Both client applications (content consumption) and server ( content packaging) of the DRM machine, including descriptions of the different types of objects related to 5 DRMs transmitted by such applications, will be discussed below, after a description of an embodiment of the internal architecture of the DRM machine itself. The DRM 1 100 machine, illustrated in FIG. 1 1, lies in a virtual machine, control VM 1 1 10, for DRM processing internal (for example, execution of control programs that dictate access to content) within a wide range of guest platforms, using guest environment 1 120 (described above, and in more detail below) in order to interact with the host application node 1 130 and, finally, other nodes within, for example, the NEMO or another system. In one embodiment, the control VM 1 1 10 is a virtual machine used by a mode of the DRM 1 100 Machine to execute control programs that indicate access to the content. A description of the integration of the control VM 1 1 10 in the architecture of the DRM 1 100 machine, as well as some of the basic elements of the control VM, including details about its instruction set, memory model, code modules and interaction with the guest environment 1 120 through of system calls 1 106. 25 In one mode, the control VM 1 1 10 is a relatively small trace virtual machine - which is designed = -p «ra - to be easy to implement by using various programming languages . It is based on a set of instructions oriented by stack that is designed to be of a minimalist nature, without much concern about speed of execution or code density. However, it will be appreciated that if execution speed and / or code density were subjects in a given application, conventional techniques (e.g., data compression) could be used to improve performance. The control VM 1 100 is suitable as a target for high or high level programming languages and supports languages such as assembler, C and FORTH. Compilers of other languages, such as Java or customary languages, could also be implemented with relative ease. The control VM 1 10 is designed to be housed within the DRM 1 100 machine, including the host environment 1 120, as opposed to running directly on a processor or silicon. The control VM 1 1 10 executes programs by executing instructions stored in Code Modules 1 102. Some of these instructions can make calls to functions implemented outside the program itself by processing one or more System Calls 1 106, which either they are implemented by the Control VM 1 1 10 itself or are delegated to the Guest Environment 1 120. Execution Model The control VM 1 1 10 executes stored instructions - "" ^ uly-oy-oílT ^^ "Bifésr loaded in the memory 1 104. The control VM 1 1 10 keeps a virtual recorder called the program counter (PC) that increases as the instructions are executed. The VM executes 5 each instruction, in sequence, until the OP_DETENER instruction is found, an OP_RET instruction with an empty call stack is encountered or an exception occurs. Jumps are specified either as a relative jump (specified as a displacement of b) iterate from the current value of the PC) or as an absolute address. 10 Memory Model In one embodiment, the control VM 1 1 10 has a relatively simple memory model. The memory VM 1 1 04 is separated into a data segment (DS) and a code segment (CS). The data segment is a single contiguous memory space, flat, which starts at address 0. The data segment is typically an installation of allocated bits within the cumulative memory of host application 1 130 or host environment 1 120. For a given VM implementation, the size of the memory space it is preferably set at a maximum; and the attempts to have access to memory outside that space will cause faults and end program execution. The data segment is potentially shared among several code modules 1 102 loaded concurrently by the VM. Access to the memory in the data segment can be accessed through access instructions to ia memory, which can be either 32-bit or 8-bit access.

Lo-s aceeso-s- ^ amnemoria -of 32 -bits are brought to cabotunadornte ^ the use * of the order of big-sian bites. No assumptions are made regarding the alignment between the memory visible by the VM and the memory handled by the guest (virtual guest CPU or physical memory). In one embodiment, the code segment is a contiguous, flat memory space that starts at address 0. The code segment is typically an installation of assigned bits within the cumulative memory of the guest application 1 130 or environment guest 1 120. The control VM 1 1 10 can load several code modules and all the code modules can share the same data segment (each module data is preferably loaded in a different address), but each has its own code segment (for example, it is preferably not possible for a jump instruction from a code module 1 102 to cause a jump directly to the code in another code module 1 1 02). Data Stack In a preferred embodiment, the VM has a notion of a data stack, which represents 32-bit data cells in the data segment. The VM maintains a virtual registrar called the stack pointer (SP). After the restart, the SP points to the end of the data segment and the stack grows down (when the data is pushed onto the data stack, the SP registers are decreased). The 32-bit values in the stack are interpreted either = - - as integers -da- d re ^ «ion ^ a ^ 3-2 ---- bits o- identifieadas ^ nrr = ^ 2- b? Ts depending of the instruction in relation to the stack data. P / 7a efe Calls In one mode, the control VM 1 1 10 handles a call stack 5 to make packaged sub routine calls. The values pushed to this stack can not be read or written directly by the memory access instructions, but are used indirectly by the VM when executing OP_JSR and OP_RET instructions. For a given VM profile, the size of this return address stack is preferably fixed at a maximum, which will allow a certain number of packet calls to be exceeded. Instruction Set In one mode, the control VM 1 1 10 uses a relatively simple instruction set. Even with a limited number of instructions; however, it is still possible to express simple programs. The set of instructions is based on a stack: except for the instruction of OP_EMPUJAR, none of the instructions have direct operands.

The operands are read from the data stack and the results are pushed on the data stack. The VM is a 32-bit VM: all instructions in this illustrative mode operate on 32-bit stack operands, which represent either memory addresses or integer identifiers. The identified integers are represented by using binary coding of 2s complement. '""' "" "fe ^ r? 'lí ó ü nW ^^ eñkír a mode is shown below: Module Format In one embodiment, code 1 modules 102 are stored in an atom-based format that is essentially equivalent to the atom structure used in the MPEG-4 file format. An atom consists of 32 bits, stored as 4 octets in order of large-sial bite, followed by a type of 4 octets (usually octets corresponding to ASCII values of letters of the alphabet), followed by the payload of the atom (octets of size 8). 3. 7. DRM Client-Server Architecture: Content Consumption and Packing As noted above, consumer applications on the DRM client side (eg, media players) consume DRM content (eg, run a song, show a movie) , etc.). The DRM service side packaging applications (typically resident on a server) package content (for example, associated with the relevant use of content and distribution rights, critical keys, etc.) directed to DRM clients. _. _ ^ "~ - .a -EIGT- - - = 2a - == i lustra- a modality of the main architectural elements of a DRM client. The guest application 1200 is interconnected with a user of the device (e.g., the owner of a music player) through the user interface 1210. The user could, for example, request access to protected content and receive metadata together with the content (for example, text that shows the name of the artist and the title of the song, along with the audio for the song itself). The guest application 1200, in addition to interacting with the user interface 1210, also performs various functions necessary to implement the user's request, which may include management interaction with the other DRM client modules to which it delegates. certain functionality. For example, host application 1200 can handle interaction with the file system to extract the requested content. Preferably, the host application also recognizes the format of the protected content object and issues a request to the DRM 1220 machine to evaluate the DRM objects that make up the license (for example, by executing the relevant control program) in order to determine whether permission to access the protected content must be granted. If permission is granted, the Guest Application 1200 may also need to verify the required signatures and delegate to 1230 encryption services any other general-purpose cryptographic function required by the DRM 1220 machine. The ^^ TDT ^ M'Y2-2f Machine is fé "sp .nsáblé" de'íávaluar loskbjétos) RM, coñfirrrrah3ó '* ~ o denying the permission and providing the keys to the guest application 1200 to decipher the content. The guest services 1240 provide the Machine 5 DRM 1220 with access to data handled by (as well as certain library functions implemented by) the guest application 1200. The guest application 1200 interacts with 1250 content services to access the content protected. Passing to the DRM 1220 machine only that portion of the content that requires 0 processing. The 1250 content services acquire content from external media servers and store and manage the content, depending on the persistent storage mechanisms of the client. Once the content is erased for access, the guest application 1200 interacts with the 1260 media conversion machine (e.g., by supply keys) to decrypt and convert the content through the client's AV output facilities. . Some of the information needed by the DRM 1220 Machine may be available in band with the 0 content and may be purchased and managed through 1250 content services, while other information may need to be obtained through DRM NEMO services or some other source. In a preferred embodiment, all cryptographic operations (encryption, signature verification, etc.) are handled by 5 encryption services 1230, which interact indirectly with the ^ máqum? "RBRM-122? Ia ifávés da ^ saTvrcl ^ "1240, which advance applications." Encryption services 1230 may also be used by 1260 media conversion machines to perform the content deciphering. "Returning to the service side, FIG. main architectural elements of a side packaging node of the exemplary DRM service The host application 1200 interfaces with a content packer (e.g., an owner or distributor of music content) through the user interface 1210. The packer could, for example, provide content and license information to the guest application 1200 so that the content can be protected (by example, encryption and association with limited access rights) and distributed to various intermediate and end-user content providers. The 1200 guest application, in addition to interacting with the user interface 1210, it can also perform various functions necessary to implement the packager request, including, for example, management interaction with the other DRM packaging modules to which it delegates certain functionality. For example, you can handle interaction with general 1235 encryption services to encrypt the content. You can also create a content object that contains or references content and contains or references a license (for example, after the DRM packaging machine "" "" "" H ^ 25 cr "kO ~ s" obj % to "s" "^ R ^ Metadata" can be associated with the license that explains what the license is about in a human readable manner (for example, to be observed by potential customer users) .5 As noted above, the guest application 1200 interacts with the user through the user interface 1210. It is responsible for obtaining information such as a content reference and the action (s) that the packer wishes to carry out (for example, with You can also display 0 information about the packaging process such as the text of the license issued and, if a failure occurs, the reason for this failure Some information needed by the guest 1200 application may require the use of being NEMO 1270 vices (for example, to level services such as authentication or authorization as well 5 as well as memberships). In one embodiment, host application 1200 delegates to media format services 1255 the responsibility of handling all media format operations, such as transcoding and packaging. The 1235 general encryption services are responsible for issuing and verifying signatures, as well as the encryption and decryption of certain data. The request for such operations could be issued externally or from the DRM 1225 packaging machine through guest services 1240. 5 In one mode, the encryption services of - ^ - = co tenid «-1237- they are logically separated from the general overhead mail services 1235 because they are not aware of the host application 1200. It is driven by the media format services 1255 at the time of content packaging with a set of 5 keys previously issued by the packaging machine DRM 1225 (all of which is coordinated by the guest application 1200). 3. 8. Protection of DRM Content and Authority Objects In an illustrative scenario, a content provider uses a guest application that depends on a DRM packaging machine to create a set of objects that protect the content and determine its use, including transport. of the information necessary to obtain the content encryption keys. The term, license, is used to encompass this set of objects. In a preferred embodiment, the content and its license are separated logically, but are joined together by references internal by using I Object Ds. The content and license are normally stored together, but could be stored separately if necessary or desirable. A license can apply to more than one content article, and more than one license can apply to any individual article of content. 25 FIG. 13 illustrates a modality of such a license, "including" "ás ^ p lacTapes ^ ab ^ discussed." Note that the control object 1320 and the controlling object 1330 are both objects identified in this mode, so that the DRM client machine can verify that the control information comes from a trusted source before being provided to the guest application with permission to access the protected content In this mode, all of these objects, with the exception of content object 1300, are created by the client machine DRM Content Object - Content object 1300 represents the encrypted content 1304 that uses a unique ID 1302 to facilitate the connection between the content and its associated key Content object 1300 is an "external" object. of the 1304 encrypted content (for example, MP4 mobile file, MP3 music track, etc.) is determined by the guest's application (or delegated to a service), based on partly to the type of content. The content format also provides support for associating the ID 1302 with the encrypted content 1304. The host application of the packet encrypts the content in a manner dependent on the format and handles the content object 1300 by the use of any available encryption system ( for example, by using a symmetric cipher, such as AES). ContentKey Object - the Key Content object 131 0 represents the encrypted key data 1314 (including a unique encryption key (s), optionally stored in the same way "" "of the object ^^ and ^ object) and ^ It also has a corresponding unique "-IT 1312. Preferably, these key data, if contained within the ContentClass 1310 object, are encrypted per se in order to be identified only by those authorized to decrypt the content. The ContentClass 1310 object also specifies which encryption system was used to encrypt this key data. This encryption system, a modality of which is discussed in more detail below, is referred to as the "key distribution system." 0 Control Object - Control object 1320 includes and protects the control program (e.g., control bite code 1324) which represents the rules that determine the use of the keys used to encrypt and decrypt the content. It also includes ID 1322 so you can join the corresponding ContentKey 5 object. As noted above, control object 1320 is signed so that the DRM client machine can verify the validity of the connection between Key Content 1310 and control 1320, as well as the connection between Key Content ID 1312 and data encrypted key 1314. The validity of the 0 control code 1324 may optionally be derived by secure verification of the mixture (eg, control mixture 1338, if available) contained in the controller object 1330. Object Controller - The controlling object 1330 represents the connection between the keys and the rules that determine their control, the use of IDs 1312 and 1322, respectively, to connect the CónfenTcToClave 1310 and the objects "uncontrolled" "1320." The object "controller 1330 dictates the use of protected content when controlling the application of the rules to that content - ie , by determining which control dictates the use of which KeyContent 1310 object. The controlling object 1330 also contains a mix value 1336 for each of the KeyContent 1310 objects to which it refers, in order to avoid hindrance to the connection between each KeyContent 1310 object and its corresponding encrypted key data 1314. As noted above, the controlling objects 1330 are preferably signed (for example, by an application of the packer having a certificate allowing it to sign the controller objects). , using public key or symmetric key signatures, as discussed below) in order to allow the veri the validity of the connection between the Key Content 1310 and the control objects 1320, as well as the connection between the Key Content ID 1312 and the encrypted key data 1314. As noted also above, the controlling object 1330 also optionally contains a control mixture 1338, which allows the validity of control object 1320 to be derived without having to separately verify its signature. Symmetric Key Signature - In a preferred embodiment, a symmetric key signature is the most common type of signature for 1330 controller objects. In one embodiment, this type of signature is implemented by calculation of a MAC (Message Authentication Code) of the 1330t driver card keyed in same key as the key represented by the KeyContent object 131 0. Public Key Signature - In a preferred embodiment, this type of signature is used when the signer identity of the controller object 1330 needs to be determined in a manner only. This type of signature is implemented with a public key signature algorithm, signing with the private key of the principal that determines the validity of this object. When this type of signature is used, the connection information to Key Content contained in the controller object 1330 preferably contains a mixture 1336 of the key contained in the ContentKey 1310 object, concatenated with a signature private signature (typically a mixture). of the private key). This connection ensures that the signer of the object has knowledge of the key used to protect the content. Protector Object - Protective object 1340 provides protected access to content by controlling the use of the keys used to encrypt and decrypt that content. The protective object 1340 connects the content object 1300 to the ContentKey 1310 object in order to associate the protected content with its corresponding key (s). To carry out this connection, it includes references 1342 and 1344, respectively, to the IDs 1302 and 1312 of the content 1300 and the Key Content 1310. In one embodiment, the protection object 1340 contains information not only for which the key was used to encrypt one or more content topics, but also with respect to the encryption algorithm that was used. In "-mo-Jairdad-sHa-content-referenced 1342 refers to more than one 1300-content object, the 1344 Content-Key reference can still reference only the Content-1310 object, indicating that all those content topics they were encrypted by using the same encryption algorithm and the same key. 3. 9. DRM Node and Link Objects Although FIG. 13 illustrates the protection objects and content authority created by DRM machines to control access to protected content, FIG. 14 illustrates the DRM objects that represent entities in the system (for example, users, devices or groups), as well as the relationships between those entities. Although FIG. 4, discussed above, illustrates a conceptual embodiment of an authorization node or graph that illustrates these entities and their relationships, FIG. 14 illustrates two types of objects that implement a modality of this conceptual graph: vertex objects (or "node") (1400a and 1400b), which represent entities and their attributes, and link objects (1420), which represent the relationships between node objects. In one modality, the DRM machine, when executing control programs, instigates one or more usage patterns to be involved. These objects - for example, the encryption of a song and its association with a license that limits its distribution to particular individuals. In addition, the DRM machine in this mode will not - - - espec-íffeat- implicitly or explicitly, l-a- will be added to these objects (for example, to whose individuals the song can be distributed). In one embodiment, this semantic context, referred to as a DRM profile, is defined within the attributes of the node objects themselves. A DRM profile can include descriptions of these entities and the various functions and identities they represent, typically expressed through the use of node attributes (1404a and 1401b). As discussed above, a 1420 link between two nodes 1400a and 1400b could represent different types of semantic relationships. For example, if one node were a "user" and the other a "device", then link 1420 could represent "property". If the other node were a "user group" instead of a "device", then the 1420 link could be unidirectional in one scenario and bidirectional in another (for example, representing two links between the same two nodes). Objects of nodes 1400a and 1400b also typically have asymmetric key-pairs of confidentiality protection (e.g., private key 1405a and public key 1406a of the node 1440a, and private key 1405b and public key 1406b of node 1406b) to limit confidential information to authorized portions of the node. The confidential information addressed to a node will be encrypted with the public key protecting the confidentiality of that node. Optionally, a pair of asymmetric key to protect the content (for example, private key 1403a and public key 1403b of node 1400a, and cla pftvadá I ^ OS ^ cla-public- ^ Cr? B ^ deF Odo- ^ OOb ") - may be used in conjunction with the objects of link when the system uses a Key Content derivation system for Key Content distribution, as discussed in more detail below.The content subjects themselves can be protected with symmetric content protection keys, such as the symmetric key 1402a of node 1400a and the key 1402b of the node 1400. As noted above, in one embodiment the link objects (e.g., link 1420) represent relationships between nodes.The semantics of these relationships can be stored in node attributes (e.g., node 1401 a). 1400a and 1401 b of node 1400b), referenced from inside the link objects (e.g., node reference 1422 for node 1400a and node reference 1424 for node 1400b). optionally providing cryptographic data (e.g., key derivation information 1426) that allows the link object to be used for KeyContents, as discussed below. In one embodiment, the link object itself is a signed object, represented by a directed edge on a graph, such as in FIG. 4 above. When there is such a directed edge of a node (for example, node X) towards another (for example, node Y), this "path" from node X to node Y indicates that node Y is "reachable" from node X. The existence of a path could be used by other objects DRM, for example, as a condition parakIevai ^ a 5 ^ a - Q "^^ A control object could verify in order to determine if a target node is reachable before it allows a certain action to be carried out in its associated content object, for example, if node D represents a device that wishes to perform the action of "executing" the action on a content object, a control indicating that this content object could be examined if a certain node U representing a certain user is reachable from node D (for example, if that user is the "owner" of that device) and only allows the "execute" action to be performed if that condition is satisfied. If the U node is reachable, the DRM machine can execute a pr control ogram to determine if there is a set of link objects that establish a path (for example, a direct or indirect relationship) between node D and node U. As noted above, in one mode, the DRM machine is incapable of the semantics of the relationship; it simply determines the existence of a path, allowing the guest application, for example, to interpret this path as a conditional authorization, allowing access to protected content. In one mode, the DRM machine verifies link objects before allowing them to be used to determine the existence of trajectories in the system node graph. The validity of a link object at any given time may depend on the particular characteristics of the certified system (discussed below) limited "life times" or be revoked or revalidated from time to time based on various conditions. Also, in one modality, the policies that dictate which entities can sign link objects, which link objects can be created, and the lifetime that the link objects are not handled directly by the DRM machine. Instead, they can level the node attribute information. To facilitate the work of reinforcing certain policies, the system can provide a way to extend standard certificate formats with additional constraint verification. These extensions make it possible to express validity constraints on certificates for keys that sign links, so that those constraints (for example, the type of nodes connected by the link, as well as other attributes), can be verified before they are considered. valid a link. Finally, in one embodiment, the link object may contain cryptographic data that provides the user with protection keys to the content of nodes for key distribution. The cryptographic data may contain, for example, in addition to metadata, the private and / or symmetric content protection keys of "from the" node, encrypted with the public key of content protection and / or the symmetric key of protection to the content. content of "towards" the node. For example, an entity that has been granted the ability to create link objects that link device nodes and user nodes under a certain policy can verify pata -as-eguratse ~ -de = cfear-solo ^ links in "ffé5"?: b7é is" from "node" "that have attributes that indicate that they nevertheless represent a device, and nodes that have attributes that indicate that they represent a user. 3. 10. DRM Cryptographic Keys An exemplary mode of a DRM key distribution system is illustrated in FIG. 15. The basic principle behind the key distribution system shown in FIG. 15 is the use of link objects to distribute keys in addition to their primary purpose of establishing relationships between node objects. As noted above, a control object may contain a control program that determines whether a requested operation should be allowed. That control program can verify in order to determine if a specific node is reachable through a collection of link objects. The key distribution system shown in FIG. 15 levels that search through a collection of link objects in order to facilitate the distribution of a key in such a way that it is available to the DRM machine that is executing the control program. In one embodiment, each node object that uses the key distribution system has one or more keys. These keys are used to encrypt content keys and other node key distribution keys. The link objects created for use in the same deployment contain some useful payload of cryptographic data - ^ e ^ parmilaTi ^ q? A- a 'key information will be demolished when links strings are processed by the DRM machine. With nodes and links transporting keys in this way, given a collection of links (for example, from node A to node 5 node B ... to node node Z), any entity that has access to node A private keys it also has access to the private keys of the node Z. Having access to the private keys of the node Z gives the entity access to any content key encrypted with those keys. 0 Node objects that participate in a key distribution system contain keys as part of their data. As illustrated in FIG. 15, in one mode each node (1500a, 1500b and 1500c) has three keys: Public Key KpubfNJ - this is the public part of a public / private key pair 5 for the public key encryption. In one embodiment, this key (1505a, 1505b and 1505c, respectively, at nodes 1500a, 1500b and 1500c) comes with a certificate (discussed below) so that your credentials can be verified by entities that wish to connect confidential information in a manner cryptographic Private Key KprivfNJ - This is the private part of the public / private key pair. The entity that manages the node is responsible for ensuring that this private key (keys 1515a, 1515b and 1 515c, respectively, at nodes 1 500a, 1500b and 1500c) 5 is kept secret. For that reason, in one modality, this key = ~ - "* r ~ ti eia '* f is stored and transported separately" ádTó, s ^ e? Ke ^ ó ~ ^ cfé ^ "? A = information of the Node Sim.Key KsfNJ - This key is used with a symmetric cipher (discussed below), because this private key (keys 1525a, 1525b and 1525c, respectively, at nodes 1500a, 1500b and 1500c) is confidential, the entity that manages the node is responsible for keeping it secret. The key distribution system illustrated in FIG. 15 can be implemented through the use of different cryptographic algorithms, although the participating entities will generally need to agree on a set of supported algorithms. In one embodiment, at least one public key cipher (such as RSA) and one symmetric key cipher (such as AES) are supported. The following annotation refers to cryptographic functions: Ep (Kpub [N], M) means "the message M cryptographed with the public key Kpub of the node N, using a public key cipher". Dp (Kpriv [N], M) means "the M message decrypted with the private Kpriv key of node N, using a public key cipher". Is (Ks [Nj, M) means "the message M encrypted with the symmetric key Ks of the node N, using a symmetric key cipher". 25 Ds (Ks [N], M) means "message M deciphered with the key" symmetric key symmetric. "The address of a" ContentKey "towards a node means making that key available to the entities that have access to the private keys of that node. , the connection is made by encrypting the key using one or both of the following methods: Public Connection: Create a ContentKey object that contains Ep (Kpub [N], CK) Symmetric Connection: Create a ContentKey object that contains (Ks [N], CK) In this mode, the symmetric connection is preferably used whenever possible, since it uses a less computationally intensive algorithm that is less burdensome in the receiving entity, however, the entity (for example , a content packer) that creates the ContentClave object may not always have access to Ks [N]. In that case, public connection may be used, since Kpub [N] must be available, since it is not in confidential training. Kpub [N] will normally be available to entities that need to direct Key Contents, accompanied by a certificate that can be inspected by the entity in order to decide whether Kpub [N] is, therefore, the key to a node that can be trusted to handle Key Content according to a certain agreed policy. To allow entities to access the "Yi '^ W distribution keys" or the "reachable nodes, in one mode, the link objects contain a" payload ". This payload allows any entity to have access to the private keys of the "node" links so that they also have access to the 5. private keys of the links "to the node". In this way, an entity can decipher any Key Content directed to a node that is reachable from its node. In this way, returning to FIG. 15, the link 1530a, which links the node 1500a to the node 1500b, contains a payload 0 that is created by encrypting the private keys 1515b and 1525b of the node 1500b with either the symmetric key 1515a of the 1500a node or, if not it is available (for example, due to its confidentiality) with public key 1525a from node 1500a. Similarly, the link 1 530b, which links the node 1500b to the node 5 1 500c, contains a payload that is created by encrypting the private keys 1515c and 1525c of the node 1500c with either the symmetric key 1515b of the node 1500b or , if it is not available, with public key 1525b of node 1500b. When a DRM machine processes link objects, 0 processes the payload of each link to update an internal 1550 string of keys to which it has access. In one embodiment, the payload of a link from node A to node B consists of either: Public derivation information Ep (Kpub [A], {Ks [Bj \ Kpriv [B].}.). 5) or - _- == __- __ ^ Symmetric derivation information - ~ "~" - ~ '- Es (Ks [A], {Ks [B], Kpriv [B].}.) Where. { Ks [B], Kphv [B]} it is a data structure that contains Ks [B] and KprivfB]. The public derivation information is used to transport the private keys of node B, Ks [B] and Kpriv [B], to any entity that has access to the private key of node A, Kpriv [A]. The symmetric derivation information is used to transport the private keys of node B, Ks [B] and KprivfB], to any entity that has access to the symmetric key of node A, Kpriv [A]. Thus, with respect to the key chain 1550, any entity that has access to the private keys of the node 1550a (private key 1515a and symmetric key 1525a) allows the DRM machine to use these private keys 1560 as a "first link" in (and starting point in the generation of the remainder of) the key chain 1550. The 1 560 scuba keys are used to decipher 1 555a the ContentKey object within link 1530a (using private key 1515a for public bypass if used public connection through public key 1505a, or symmetric key 1525a for symmetric derivation if symmetric connection was used through the symmetric keys 1525a), resulting in the following link 1 570 in the key chain 1525b). The DRM machine uses these keys 1 570 to decrypt, at the same time, 1555b, the ContentKey object within the link 1530b (using the private key 1515b ^ for derivation, public if you know "used" public connection through public key 1505b, or symmetric key 1525b for symmetric derivation if symmetric connection was used through the symmetric key 1525b), resulting in the final link 1580 in the key chain 1550 - i.e., the confidential keys of the node 1500c (private key 1515c and the symmetric key 1525c). Since, in one modality, the DRM machine can process links in any order, it may not be able to carry out a key derivation at the time a link is processed (for example, because the keys of "originating from "node of that link have not yet been derived). In that case, the link is remembered and processed again when such information becomes available (for example, when a link is processed in which that node is the "toward" node). 3. 1 1. DRM Certificates As noted above, in one modality certificates are used to verify the credentials associated with cryptographic keys before making decisions based on the digital signature created with those keys. In one modality, multiple certificate technologies can be supported, leveling out the existing information typically available as standard certificate elements, such as periods of validity, names, etc. In addition to these standard elements, additional constraints may be encoded to allow the potential use of a certified key.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The information encoded in such extensions could be used to allow the DRM machine to determine if the key that has signed a specific object was authorized to be used for that purpose. For example, a certain key can have a certificate that allows it to sign only those link objects in which the link is from a node with a specific attribute and / or towards a node with another specific attribute. The base technology used to express the certificate typically is not capable of expressing such a constraint, since its semantics can be found unconscious of elements such as links and nodes. In one embodiment, such specific constraints are transported, therefore, as extensions of key use of the basic certificate, including a corresponding "use category" and "constraint program". The category of use specifies which type of objects are authorized to sign a key. The constriction program can express dynamic conditions based on context. In a modality, a verifier who is asked to verify the validity of such a certificate is required to understand the relevant semantics, although the evaluation of the key use extension expression is delegated to the DRM machine. The certificate is considered valid only if the execution of that program generates a successful result. In one embodiment, the function of a constraint program is to break a boolean value - for example, "true" indicating that the constraint conditions are met and "false" indicating that they are not met. Some context information that can be used to arrive at a decision The available context information may depend on the type of decision made by the DRM machine when requesting verification of the certificate, for example, before using the information in an object link, a DRM machine can verify that the certificate of the key that signed the object allows that key to be used for that purpose.When the constraint program is run, the environment of the DRM machine is populated with information regarding the link attributes, as well as the attributes of the nodes referenced by that link The constraint program embedded in the extension of The use of a key is encoded, in one modality, as a code module (described above). This code module preferably exports at least one named entry point, for example, "MachineName. Certifed. <Category> Verify", where Category is a name that indicates which category of certificates needs to be verified. The parameters for the verification program will be pushed into the stack before calling the entry point. The number and types of parameters passed to the stack depend on the category of certificate extension being evaluated. 4. SYSTEM OPERATION ^ 4.1"Basic Node-Basic Terminology ^ - ^ ~ '-" --- Having examined various modalities of the main architectural elements of the NEMO system, including modalities in the context of DRM applications, we now turn to the NEMO system in operation - that is, the sequence of events within and between NEMO nodes that establishes the foundation upon which the specific functionality of the application can be stratified. In a modality, before the NEMO nodes invoke application-specific functionality, they go through an initialization and authorization process. The nodes initially seek to discover desired services (through requests, registration, notification, etc.), and then obtain authorization to use those services (for example, by establishing that they are reliable and satisfy any relevant service provider policy). ). This process is illustrated in FIG. 16, which outlines a basic interaction between a 1600 Service Provider (in this mode, with shared functionality between a Service Provider Node 1610 and an Authorization Node 1620) and a Service Provider 1630 (for example, a service consumer) client). Note that this interaction does not need to be direct. Any number of Intermediary Nodes 1625 may lie in the path between the 1630 Service Applicant and the 1600 Service Provider. The basic stages in this process, which will be described in more detail below, are discussed from the perspective of both the Applicant- ciaY Sa vicio cltetrtá ~ 1-630 as of the Service Provider-1600. From the perspective of the Service Applicant 1630, the logical flow of events shown in FIG. 16 is as follows: Discovery of Service - In one modality, the Service Requestor 1630 initiates a service discovery request to locate any NEMO enabled node that provides the desired service, and obtain information regarding which service connections are supported for access to the relevant service interfaces. The 1630 Service Applicant may choose to associate information about discovered services. It should be noted that the interface / mechanism for the Service Discovery between NEMO Nodes is just another service that a NEMO Node chooses to implement and expose. The Service Discovery process is described in more detail below, including other forms of communication, such as notification by Service Providers to registered Service Requesters. Service Connection Selection - Once the candidate service provider nodes are found, the requesting node can choose to address (dispatch a request to) one or more of the service provider nodes based on a specific service connection. Negotiating an Acceptable Trust Relationship with the Service Provider - In one modality, before two Nodes can communicate in a secure manner, they must be able to establish a "trustworthy" relationship for this purpose. - This - may include an exchange of trusted trust credentials (for example, X.500 certificates, etc.) in some integrity protection wrapper that can be used to determine identity; and / or may include the establishment of a secure channel, such as an SSL channel, based on certificates that both parties trust. In some cases, the exchange and negotiation of these credentials can be an implicit property of the service interface connection (for example, WS-Security if the WS-I XML protocol is used when the interface is exposed as a network service, or an SSL request between two well-known nodes). In other cases, the exchange and negotiation of trust credentials can be an explicitly separate stage. NEMO provide a flexible and standard structure that allows the Nodes to establish trusted channels for communication. It depends on a given node, based on the characteristics of the node and the characteristics of the service involved in the interaction, to determine which credentials are sufficient to interact with another NEMO node, and to decide whether to trust a given node. In one modality, the NEMO structure levels existing and emerging standards, especially in the area of data types and protocols related to security. For example, in one modality, the structure will support the use of SAML to describe both credentials (evidence) given by service requesters to service providers when they wish to invoke a service, as well as the use of authorization responses. Creation of Request Message - The next step is to request the Node 1630 to create the appropriate request message (s), corresponding to the desired service. This operation can be hidden by the Service Access Point. As noted above, the Service Access Point provides an abstraction and interface to interact with service providers in the NEMO structure, and can hide certain service invocation themes, such as native interfaces for graphical representations of service messages, sorting / rearrangement of objects, negotiation of compatible message formats, transport mechanisms or message routing issues, etc. Request Dispatch - Once the request message is created. It is dispatched to the target service provider (s) node (s) - for example, node 1610. The communication style of the request can be synchronous / asynchronous or message-oriented RPC style, based on the connection of service and / or preferences of the requesting client. The interaction with a service can be done directly by the transmission and processing of service messages or be done through more native interfaces through the NEMO Service Access Point. Receipt of Response Message (s) - After dispatching the request, the Applicant Node 1610 receives one or more return responses. Depending on the specifics of the connection ~ "" "to the interface to" etvfcio "and" 1: to the requirements of the Applicant Node ^ 610, - the response (s) can be returned in various ways, including a response from RPC style or notification message. As noted above, the requests and responses can be mourned towards their target node through another Intermediate Node (s) 1625, the one (s) which can provide a number of services, including: routing, trust negotiation, classification and correlation functions, etc. All services in this modality are "standard" NEMO services described, discovered, authorized, linked to and interacted with, within the same consistent structure. The Service Access Point can hide the message level abstractions of a Node. For example, from the perspective of the Node, the invocation of a service can be considered as a standard function invocation with a set of simple fixed parameters. Confidence Semantics Validation Negotiated Response - In one modality, Requesting Node 1630 validates the response message to ensure that it adheres to the trust semantics negotiated between it and the 1610 Service Provider Node.

This logic is typically encapsulated entirely within the Service Access Point. Message Payload Processing - Finally, any suitable processing is then applied based on the type and content of the message payload (application specific). 25 Below is the logical flow (somewhat similar) to TeveTífós from the "Service Provider's perspective 1600-: - - - Determination of Service Support - A determination is made first as to whether the requested service is supported In one embodiment, the NEMO structure does not dictate the style or granulation capacity of the way the service interface represents an entry point to a service, in the simplest case, a service interface ambiguously represents a given service. , and the act of connecting and invoking that interface constitutes the support for the service, however, it may be the case that a single service interface handles multiple types of requests, or that a given service type contains additional attributes that need to be shown. before a determination is made as to whether the Node really supports the specifically desired functionality Negotiating Trustworthy Relationship with Soli Service Citing - In some cases, it may be necessary for the 1600 Service Provider to determine whether to trust the Requesting Node 1630, and establish a trusted communication channel. This process is explained above in detail. Authorization Request Dispatch to Nodes Authorizing Access to Service Interface - The Service Provider Node 1610 then determines if the Requesting Node 1630 is authorized or qualified to access the service and, if so, under what conditions. This can be a decision based on local information or an authorization decision mechanism supported natively. If not supported locally, the Provision Node "YI ^ rSafvi; ió" ': "1 r31 0 - can -dep-a-char an authorization request (s) to a NEMO authorization service provider known (for example, Authorization Node 1620) that dictates its services, in order to determine if the Requesting Node 1610 is authorized to have access to the services requested In many situations, the Authorization Node 1620 and the Service Provider Node 1610 they will be the same entity, in which case the dispatch and processing of the authorization request will be local operations invoked through a lightweight service interface connection, such as a function C entry point. However, once again , since this mechanism is in itself only a NEMO service, it is possible to have a fully distributed implementation.Application requests can refer to identification information and / or attributes associated with the NEMO Node itself, or in training associated with users and / or devices associated with the Node. Message Processing After Receipt of Authorization Response - After receiving the authorization response, if the Requesting Node 1630 is authorized, the 1600 Service Provider performs the processing necessary to satisfy the request. Otherwise, if the Requesting Node 1630 is not authorized, an appropriate response message of "denied authorization" may be generated. Response Message Return - The response is then returned based on the service interface connection and the communication methods, including an RPC style response or notification message. Again, as noted above, the requests and responses may be cast to their target Node via another Intermediate Node (s) 1625, the one (s) which can (s) yes provide a number of services, including routing, trust negotiation, classification and correlation functions, etc. An example of a necessary service provided by an Intermediary Node 1625 could be the provision to a processor node of Notification that the message can provide the message in a manner known to Applicant Node 1630. An example of a "value-added" service could be, for example, a coupon service that associates coupons with the response if it knows the interests of the Requesting Node. 1630. 15 4.2. Notification As noted above, in addition to communication patterns similar to RPC both asynchronous and synchronous, where the client specifically initiates a request and then either While waiting for answers or periodically verifying responses through the conversion of a ticket, some NEMO modalities also support a pure message type of communication pattern based on the notion of notification. The following elements constitute data and message types that support this notification concept in a modality: = - - = - __ = ^ s ^^ _.-._ Notification - a ^ mensájVque containing- a-tip? targeted payload specifics at interested endpoint nodes. Notification Interest - the criteria used to determine whether a given Node will accept a given notification. The 5 notification interests may include interests based on specific types of identity (eg, Node ID, User ID, etc.), events (eg, Node discovery, service discovery, etc.), affinity (for example, new jazz club content) or general categories (for example, advertisements). 10 Notification Useful Charge - the standardized content of a notification. The types of payload can vary from simple text messages to more complex objects. Service Manager Interface of Notification - the type of interface of the service provider in w 15 notifications can be received. The service provider also describes the notification interests associated with the interface, as well as the acceptable payload types. A Node that supports this interface can be the final destination for the notification or an intermediate processing endpoint. 20 Notification Processor Service - a service that is capable of attaching notifications to interested Nodes, delivering notifications based on some policy. Notification Sorter - a Node that sends a notification addressed to a set of interested Nodes and / or an intermediate set of Notification Processing Nodes.

"The" notification "in" technical "of" useful "and" useful "notification are preferably expandable. Additionally, the service interface of the notification handler is preferably subject to the same authorization process as any other NEMO service interface. Therefore, even when a given notification can be coupled in terms of interest and acceptable payload, a Node may refuse to accept a notification based on some associated interface policies, in relation to the intermediary issuer or source of the notification. FIG. 17a illustrates a set of Notification processing nodes 1710 that discover 1715 a Node 1720 that supports the notification handler service. As part of its service description, node 1720 designates its notification interests, as well as for w notification payload types are acceptable. FIG. 17b illustrates how notifications can be delivered. Any Node could be the source of origin as well as the notification processor and could be responsible for delivering the notification to Node 1720, w supports the notification handler service. In this way, Node 1710a could be the processing node of the origin notification; or such functionality could be divided between Node171 0c (source of notification origin) and Node 1710b (notification processor). Still another Node (not shown) could be responsible for the delivery of the notification. The notification processors that choose "m" anéja7"" ñó = t? Frc? Wo "ne ^ ~ ptotvantentes" -de Nodes of origin -notification of others, can be integrated with a commercial notification processing machine, such as Microsoft Notification Services in order to improve efficiency. 4. 3. Service Discovery In order to use NEMO services, the NEMO Nodes will need to know about them first. A NEMO modality supports three dynamic discovery mechanisms, illustrated in FIGS. 18a-c: Powered by Client - a NEMO Node 1810a (in FIG.18a) explicitly sends a request to a certain set of Target Nodes (eg, 1820a) that supports a "Service Inquiry" service interface 1815a , asking the request if the target nodes support a specific set of services. If Claimant Node 1810a is authorized, the Service Provider Node 1820a will send a response indicating whether it supports the requested interfaces and the associated service interface connections. This is one of the most common interfaces that Nodes will support if exposed to any service. Node Record - A NEMO Node 1 81 0b (in FIG. 18b) can record its description, including its supported services, with other Nodes, such as the Service Provider Node 1820b. If a Node supports this step 1815b, it will be able to accept requests from other Nodes and then store those -descriptions based on a certain policy. These -der node descriptions are then directly available for use by the receiving node or by other nodes that perform service queries directed to nodes that have stored descriptions. As an alternative to P2P registration, a Node could also use a public registry, such as a standard UDDI registry (Universal Discovery, Description and Integration) for location services. Based on Events - the Nodes (such as Node 181 0c in FIG.18c) send notifications 1815c to Interested Nodes 1820c (which are "aware of notification" and previously indicated their interest), indicating a change in status (eg , Active / available node), or a node warns that it supports a specific service. Notification 1 815c may contain a complete description of the node and its services, or only the I D of the node associated with the event. Interested nodes can then choose to accept and process the notification. 4. 4. Service Authorization and Establishment of Trust As noted above, in one modality, before a Node NEMO allows access to a requested service, first determines if, and under what conditions, the requesting Node allows access to that service. The access permission is based on a context of trust for interactions between the service requester and the srvTc supplier. As the "discourse will continue-to-be" even if a Node establishes that it can be reliable, a Node service provider may also require that a specified policy be satisfied before allowing access to a particular service or set of services In one modality, NEMO does not indicate the specific requirements, criteria or decision-making logic employed by an arbitrary set Node in the determination of whether or not to trust each other Reliable semantics can vary radically from Node to Node Instead, NEMO provides a standard set of equipment that allows the Nodes to negotiate a mutually acceptable relationship of trust. and establishing trust between nodes, NEMO supports the exchange of credentials (and / or related information) between nodes, which can be used for the establishment of a trusting context. Such trust-related credentials can be exchanged through the use of a variety of different models, including the following: Service Connection Properties - a model where trust credentials are implicitly exchanged as part of the service interface connection. For example, if a Node 1920a (in Figure 19a) exposes a service in the form of an HTTP Post over SSL, or as a Network Service that requires a WS-Security XML Signature, then the actual properties of this connection can communicate all credentials "TelaciOna" das "~: kíot ^ a ~ - c ^ 1 915a, with a Node Applicant 1 910a. Request / Response Attributes - a model where trusted credentials are exchanged via request and response WSDL messages (see FIG.19b) between a Requesting Node 1910b and a Service Provider Node 1 920b, optionally including credentials as attributes of messages 191 5b. For example, digital certificates could be attached to, and flow with, the request and response messages, and could be used for the formation of a trusting relationship. Explicit Exchange - a model where trusted credentials are explicitly exchanged through a service provider interface (1915c in FIG.19c) that allows the query of information related to the trusted credentials that a given node contains. This is usually the most involved model, which typically requires a separate round session in order to exchange credentials between a Requesting Node 1 91 0c and a Service Provider Node 1 920c. The service interface connection itself provides a mutually acceptable trusted channel for the explicit exchange of credentials. In addition to these basic models, NEMO can also support combinations of these different approaches. For example, the communication channel associated with a semi-trusted service connection can be used to restart the exchange of other security-related credentials more directly, or the security-related credentials can be used to secure certain security credentials. inherent integrity type) directly and through its use to establish a secure communication channel, associated with a certain service interface connection. As noted above, the semantics of the trust model and the processes for establishing trust can vary from entity to entity. In some situations, mutual trust between nodes may not be required. This type of dynamic heterogeneous environment calls for a flexible model that provides a common set of equipment that allows different entities to negotiate trust-sensitive semantics. 4. 5. Policy Managed Access In a modality (as noted above), a service provider node, in addition to requiring the establishment of a trusted context before allowing a requesting node to access a resource, may also require that the node applicant satisfies a policy associated with that resource. The policy decision mechanism used for this purpose can be local and / or private. In one modality, NEMO provides a flexible, consistent mechanism to support this functionality. As part of the service description, one can designate specific NEMO nodes as service providers of "authorization". In one embodiment, a Node Authorization Service Provider implements a standard service for handling and responding "to" requests for 'Authorization Query. "Before access to a service interface is allowed, the target service provider dispatches an "Authorization" query request to any authorization node for its service and access will be allowed only if one or more such Nodes (or a pre-specified combination thereof) responds indicating that access is permitted. illustrated in FIG 20, a 2010 Requesting Node exchanges 2015 messages with a 2020 Service Provider Node, including an initial request for a particular service, and the 2020 Service Provider Node then determines whether the 2010 Requesting Node is authorized to invoke that service, and thus exchanges 2025 authorization messages with the 2025 authorization nodes that handle access to the requested service, including a request Initial authorization period for these 2030 Nodes. Based on the responses you receive, the 2020 Service Provider Node is then processed and returns the applicable service response or returns a response indicating that access was denied. In this way, the Authorization service allows a NEMO node to participate in the policy decision point function 8PDP). In a preferred modality, NEMO is a management system by neutral policy; it does not dictate how an authorization node reaches decisions about authorizations based on an authorization query. In addition, for interoperability, it is preferable that authorization requests and responses adhere to a certain standard and - - be sufficiently extensive - to contain a flexible payload so that they can accommodate different types of authorization inquiry requests in the context of different policy management systems. In one embodiment, support is provided for at least two authorization formats: (1) a simple format that provides a very simple wrapper that uses some less common denominator criteria, such as input, a simple requester ID, resource ID and / o Action ID, and (2) the standard format of "Security Determination Markup Language" (SAML) to 0 wrap an authorization query. In an embodiment, an authorization node must recognize and support at least a predefined "simple" format and be able to represent it in any native policy expression format that exists in the authorization node. For other formats, the 5 Authorization Node returns an appropriate error response if it does not handle or understand the payload of an "Authorization" query request. The extensions may include the ability for the Nodes to negotiate on acceptable forms of an authorization query, and for the Nodes to consult to determine which 0 formats are supported by a given Authorization Service Provider Node. 4. 6. Basic DRM Node Interaction Returning to the specific NEMO case of a DRM application, FIG. 21 is a DRM (or Vertex) Node Plot that can "" "illustrate the interaction between Nodürs ORl l, as well as their relationships. Consider the following scenario in which the portable device 21 10 is a reproductive device. content (for example, a Pod 1) Nip1 is the Node that represents this device, Kip1 is the content encryption key associated with Nip1. "User" is the owner of the portable device and Ng is the Node that represents to the user Kg is the content encryption key associated with Ng. Publi is a Public Library. members of this library and Kp1 is the content encryption key associated with Np1. ACME represents all Music players manufactured by ACMÉ. Namp represents that class of devices and Kamp is the key to content encryption associated with this group. 15 L1 is a link from Nip1 to Ng, which means that the portable device belongs to the user (and has access to user keys). L2 is a link from Ng to Np1, which means that the user is a member of the Public Library (and has access to their passwords). L3 is a link from Nip1 to Namp, which means that the portable device is an ACME device (mere membership, since the company has no keys). L4 is a link from Np1 to Nap1, which is the Node that represents all public libraries (and has access to the keys of the entire group). C1 is a movie file that the Public Library makes available to its members. Kc1 is a key used "for cryptography" C "1" GB [C1] (not shown) is the authority information for C1 (for example, rules and associated information that is used to indicate access to the content). E (a, b) means 'b' which is cryptographed with the key 'a'. For purposes of illustration, suppose you want to establish a rule that a device can play the C1 content as long as (a) the device belongs to someone who is a member of the library and (b) the device is manufactured by ACME. The content C1 is cryptographed with Kc1. The rules program is created, as well as the cryptographic content key RKfC1] = E (Kamp, E (Kp1, Kc1)). Both the rules program and RK [C1] can be included in the authority block for the GB [C1] content. The portable device receives C1 and GB [C1 j \ For example, both could be packaged in the same file, or received separately. The device after buying it. The portable device received L2 when the user paid his subscription fee to the Public Library. The portable device received L3 when it was manufactured (for example, L3 was built). From L1, L2 and L3, the portable device is able to verify that Nip1 has a graphical trajectory towards Ng (L1), Np1 (L1 + L2) and Namp (L3). The portable device wants to play C1. The portable device executes the rule found in GB [C1]. The rule can verify that Nip1 is in fact an ACMÉ device (trajectory to Namp) and belongs -to a member- of the -) tbli) taca ~ public (trajectory to Np1). In this way, the rule returns "yes" and the list returns (Namp, Np1). The portable device uses L1 to calculate Kg, and then L2 to calculate Kp1 from Kg. The portable device also uses L3 to calculate Kamp. The portable device applies Kpl and Kamp to RK [C1], found in GB [C1] and calculates Kc1. Then use Kc1 to decipher and play C1. When the Node keys are symmetric keys, as in the previous examples, the content packer needs access to the keys of the Nodes to which you want to "connect" the content. This can be achieved by creating a Node representing the packer, and a link between that Node and the Nodes to which you want to connect the rule. This can also be achieved "out of band" through a service, for example. But in some situations, it may not be possible, or practical to use symmetric keys. In this case, it is possible to assign a pair of keys to the Nodes to which a connection is needed without shared knowledge. In that case, the packer would connect a content key to a Node by encrypting the content key with the public key of the target Node. To obtain the description key, the client would have access to the node's private key through a link to that node. In the most general case, the nodes used for the rules and the nodes used for the calculation of content encryption keys do not need to be the same. It is natural to use the same nodes, since there is a strong relationship between a rule that dictates the content and the key used to encrypt it, but it is not necessary. In some systems, some Nodes can be used for content protection keys that are not used to express membership conditions and vice versa and in some situations two different Node graphs can be used, one for rules and one for content protection. For example, a route might say that all the members of the group Np1 can access the content C1, but the content key Kc1 may not be protected by Kp1, but may instead be protected by the node key Kap1 of the node Nap1, the which represents all public libraries, not just Np1. Or a rule could say it needs to be a Namp member, but the content encryption key could be joined only to Npl. 4. 7. Operation of Virtual Machine DRM (VM) The discussion with respect to FIG. 21 described above the operation of a DRM system at a high level (Node and Link), including the formation and reinforcement of content authority policies. FIG. 22 illustrates an exemplary code module 2200 of a DRM machine VM that implements the formation and enforcement of such content authority policies. Four main elements of the illustrative Code Module 2200, shown in FIG. 22, include: Atom pkCM: Atom pkCM 221 0 is the Atom of the High Level Code Module. It contains a sequence of sub-atoms. Atom pkDS: Atom pkDS 2220 contains a memory image that can be loaded in the Data Segment. The Atom payload is a raw sequence of octet values. Atom pkCS: Atom pkCS 2230 contains a memory image that can be loaded in the Code Segment. The Atom payload is a raw sequence of octet values. Atom pkEX: The Atom pkEX 2240 contains a list of export entries. Each export entry consists of a name, encoded as an 8-bit name size, followed by the characters of the name, including a 0 ending, followed by a 32-bit integer representing the offset of the mentioned entry point ( this is a displacement of the beginning of the data stored in the atom pkCS). 4. 7.1. Module Loader In one mode, the Control VM is responsible for loading Code Modules. When a Code Module is loaded, the memory image encoded in the pkDS Atom 2220 is loaded into a memory address in the Data Segment. That address is chosen by the VM Loader, and stored in the DS pseudo-registrar. The memory image encoded in the Atom pkCS 2230 is loaded into a memory address in the Code Segment. That address is chosen by the VM Loader, and it is stored in the pseudo-registrar-CS; - - - 4. 7.2. System Calls In a modality, the Control VM Programs can call functions implemented outside their Segment of Code Module Codes. This is done through the use of the instruction OP_LLAMADA, which takes an integer stack operand that specifies the System Call Number to be called.

Depending on the System Call, the implementation can be a VM Control Bite Code routine in a Control Module.

Different code (for example, a library of utility functions), directly by the VM in the native VM implementation format or delegated to an external software module, such as the VM Host Environment. In one modality, several Numbers of System Call: SYS_NOP = 0: This call is a no operation call. Just return (nothing more). It is basically used to examine the VM. SYS_DEPURAR_IMPRIMIR = 1: Prints a text string to a debug output. This call expects a single stack argument, specifying the address of the memory location containing the null-terminated string to be printed. SYS_FIN_SYS_LAMED_TO_NAME = 2: Determines if the VM implements a named System Call.

If it does, the System Call Number is returned to the stack; otherwise the -1 value is returned. This call expects a single stack argument, specifying the address of the memory location that contains the null-terminated System Call name that is requested. 4. 7.3. Assignment of System Call Numbers In a modality, the Control VM reserves Numbers of System Call 0 to 1 023 for Mandatory System Calls (System Calls that have been implemented by all VM profiles). The System Call Numbers 16384 to 32767 are available for the VM to allocate dynamically (for example, the System Call Numbers returned by SYS_FIN_STAND_SYS_LAY_NO_NAME can be assigned dynamically by the VM and do not have to be the same numbers in all VM implementations). 4. 7.4 Standard System Calls In one mode, several Calls are provided.

System Standards to facilitate the writing of Control Programs. Such standard system calls may include a call to obtain a time stamp from the guest, a call to determine if a node is reachable and / or the like. The system calls preferably have dynamically determined numbers (for example, -your System Call Number can be retrieved by calling the System Call SYS_FIN_SYS_LAYED_BY_NAME with its last name as the argument). 4. 8. Interfaces Between DRM Machine Interface and Host Application Below are some high-level exemplary descriptions of the types of interfaces provided by an illustrative DRM machine (client consumption) for a Guest Application: System Name:: Create Session (guestContextObject) - > Session Create a session given a Guest Application Context. The context object is used by the DRM machine to make calls back to the application. Session r. ProcessObject (drmObject) This function could be called by the Guest Application when it finds certain types of objects in the media files that can be identified as belonging to the DRM subsystem. Such objects include content control programs, membership badges, etc. The syntax and semantics of these objects is opaque to the Guest Application. Session :: Open Content (contentReference)? Content The guest application calls this function when it needs interaction-tuari. with - a - multimedia content file. The DRM machine returns a Content object that can be subsequently used to retrieve DRM information about the content and interact with that information. Content :: GetDrmlnfo () Returns DRM metadata about content that is otherwise not available in the regular metadata for the file. Content :: CreateAction (actionlnfo)? Action The Guest Application calls this function when it wishes to interact with a Content object. The lnfo action parameter specifies what type of action the application needs to perform (for example, Play), as well as any associated parameters, if necessary. The function returns an Action object that can be used later to perform the action and retrieve the content key. Action:: GetClavelnfo () Returns information that is necessary for the description of the subsystem in order to decipher the content. A ction :: VerifyQ Verify if the DRM subsystem will authorize the performance of this action (ie, if Action:: Perform () would happen). Action :: Perform () Performs the action and performs any consequence (with its side effects) as specified by the rule (s) - • - that dictates (n) this action. - J ~ Below are some high-level exemplary descriptions of the type of interface provided by an illustrative Guest Application to a DRM machine (client consumption): GuestContext :: Get FileSystem (type)? FileSystem Returns an object of Virtual FileSystem to which the DRM subsystem has exclusive access. This VirtualSystem File will be used to store DRM status information. The data within this SystemSystem is legible and can only be written by the DRM subsystem. GuestContext:: GetRealTime () Returns the actual date / time as it is maintained by the guest system. GuestContext:: Get Identity () Returns the unique ID of this guest. Guest Context:: ProcessObject (ObjectObject) Returns to the guest services a data object that may have been embedded in the back of a DRM object, but which the DRM subsystem has identified as being managed by the guest (for example, certificates). GuestContext: Verify Signature (firmalnfo) Verifies the validity of a digital signature for a data object. Preferably, the signature object contains information equivalent to the information found in an XMLSig element. Guest Services are responsible for handling the keys and key certificates needed to validate the signature. Guest Context:: CreateCifra (numberType, nfo carnation) Number Creates a Cipher object that the DRM subsystem can use to encrypt and decrypt data. A minimum set of cipher types will preferably be defined and for each a format to describe the key info required by the cipher implementation. Number:: Crip togra fia r (da cough) The above mentioned Cipher object, used to encrypt data. C ifra r.Descifrar (data) The object of the above-mentioned figure, used to decipher data. GuestContext :: CreateDigestor (typeDigestor)? Digestor Create a Digestor object that the DRM subsystem can use to calculate a safe mix over some data. A minimum set of digester types will be defined. Digestor :: Update (d atos) The Digester object referred to above used to calculate the safe mix. Digestor:: Get Digestion () The Digester object referred to above, used to obtain the safe mix calculated by the DRM subsystem. Below are some descriptions-high-level-of-interface type provided by an illustrative DRM machine (for service-side packaging) for a Guest Application: System Name: Create Session (guestObjectObject) Session Creates a Session given a Host Application Context.

The context object is used by the DRM packaging machine to make calls in the application. Session :: CreateContent (Content References)? Content The Guest Application will call this function in order to create a Content object that will be associated with the license objects in later stages. Having more than one content reference in the installation of contentReferences, implies that they are joined together in a bundle (the audio and video track, for example) and that the issued license should be addressed to them as an indivisible group. Content:: SetDrmlnfo (drfo nfo) The drmlnfo parameter specifies the metadata of the license to be issued. The structure will be read and act as a guide to calculate the license in the code of bits for the VM. Content:: ObtainDRMObjects (format)? DrmObjects This function is called when the Guest Application is ready to obtain the drmObjects that the DRM packaging machine creates. The format parameter will indicate the expected format for these objects (for example, XML or binary atoms). - _, _ - Gontenido :: GetC! OsO? keysO * - "'*" - "' This function is called by the Guest Application when it needs the keys in order to encrypt the content. In one modality, there will be a key by content reference. Some high-level exemplary descriptions of the type of interface provided by an illustrative Host Application for a DRM machine (service-side packaging) are presented below: ContextHouse :. -Obtaining SystemFile (type)? SystemFile Returns an object from VirtualFileSystem for which the DRM subsystem has exclusive access. The VirtualSystem File would be used to store DRM status information. The data within this SystemSystem should only be able to be read and written by the DRM subsystem. GuestContext:: GetActualTime ()? Time Returns the current date / time as it is maintained by the guest system. GuestContext:: Get Identity ()? ID Returns the unique ID of this guest. GuestContext :: Perform Sign (signature, data) You will have to rely on some DRM objects created by the DRM packaging machine. This service, provided by the guest, will be used to sign the specific object. GuestContext:: CreateCifra (Type figure, carnation)? Figure Create an object of "Number that the" Packaging machine " DRM can use to encrypt and decrypt data. This is used to encrypt the key content data in the ContentKey object. Number:: Crip togra fia r (da cough) The above mentioned Cipher object, used to encrypt data. Number:: Decrypt (d atos) The above-mentioned Cipher object, used to decipher data. GuestContext:: CreateDigestor (digesterType)? Digester Create a Digestor object that the Packaging machine DRM can use to calculate a safe mix over some data. Digestor:: Update (d atos) The Digester object referred to above, used to calculate the safe mix. D manager:: Get Digestion () The Digester object referred to above, used to obtain the safe mix, calculated by the DRM subsystem. Guest Context:: Generate Random Number Generates a random number that can be used to generate a key.

. SERVICES 5.1. Overview - - - l- opening -described- the 'NEMO / DRM system' from both an architectural and operational perspective, we now turn our attention to an illustrative collection of services, data types, and related objects ("profiles") ) that can be used to implement system functionality As noted above, a preferred modality of the NEMO architecture employs a flexible and portable way to describe the syntax of requests and responses associated with invocation of services, data types used within the structure, wrapper of messages and data values exposed by and used within the NEMO structure. WSDL 1 .1 and the foregoing provide sufficient flexibility to describe and represent a variety of service interface types and invocation patterns, and have an abstraction enough to accommodate connections to a variety of different endpoint nodes through various communication protocols unication In one modality, we define a profile as a set of data types and thematically related interfaces defined in the WSDL. NEMO distinguishes a "Core" profile (which includes the foundational set of data types and service messages needed to support fundamental interaction patterns of NEMO Node and Infrastructure functionality!) From a specific application profile, such as a DRM Profile (the which describes the Digital Rights Management services that can be performed with NEMO) both of which are discussed below. _ _--. - _-_.- -, - It will be appreciated that many of the "types" of data and services "defined in these profiles are abstract and should be specialized before they are used. Other profiles are built in the upper part of the Core profile. 5 5.2. NEMO Profile Hierarchy In one modality, the definition of service interfaces and related data types is structured as a set of mandatory and optional profiles that are built on top of each other and 10 can be extended. The difference between a profile and a profile extension is relatively a subtitle. In general, profile extensions do not add new data types or service type definitions. They only extend existing abstract and concrete types. FIG. 23 illustrates an exemplary profile hierarchy for 15 NEMO and DRM functionality. The main elements of this profile hierarchy include: Core Profile - At the base of this profile hierarchy lies the Core Profile 2300, which preferably shares both NEMO and DRM functionality. This is the profile on which all other profiles are based. It includes a basic set of generic types (discussed below) that serve as the basis for creating more complex types in the structure. Many of the types in the Core Profile are abstract and will need to specialize before use. Core Profile Extensions - Immediately above 5 of the 2300 Core Profile are the 2320 Core Profile Extensions, -which are the "primary" specializations of the types in the 2300 Core Profile, resulting in representations Core Services Profile - Also immediately above Core Profile 2300, Core Services Profile 2310 defines a set of infrastructure services in general, also discussed below: In this profile, service definitions are abstract and will need to specialize before use Core Profile Profile Extensions -constructed on both the Core Profile Extensions 2320 and the Core Services Profile 231 0 are the Core Services Profile Extensions 2330, which are the primary specializations of the services defined in the Núcleo 2310 Services Profile, giving or result concrete representations. DRM Profile - Immediately above the 2300 Core Profile lies the DRM 2340 Profile, on which other profiles related to DRM are based. DRM Profile 2340 includes a basic set of generic types (discussed below) that serve as the basis for creating spic types of more complex DRMs. Many of the types in the DRM 2340 Profile are abstract and will need to splize before use. DRM Profile Extensions - Built on the DRM 2340 Profile are the DRM 2350 Profile Extensions, which are the primary splizations of the types in the DRM-2340r Profile, which results in spic representations. "- - Profile of DRM Services - Also built on the Profile DRM 2340 is the DRM 2360 Services Profile, which defines a set of general DRM services (discussed below). In this profile, service definitions are abstract and need to specialize before use. Specific DRM Profile - Built on both the DRM 2350 Profile Extensions and the DRM 2360 Services Profile, there is the Specific DRM Profile 2370, which is an additional specialization of the DRM services defined in the DRM 2360 Services Profile. Profile also introduces new types and extends even more certain types specified in the Core Profile Extensions 2320. . 3 NEMO Services and Service Specifications Within this profile hierarchy lies, in one modality, the following major service constructs (as described in more detail above): Parity Discovery - the ability to have parities in the system discovered from each other . Service Discovery - the ability to discover and obtain information about services offered by different parities. Authorization - the ability to determine whether a given parity (eg, a Node) is authorized to have access to a csmo-a service). - - - - ___._-.-. Notification - services related to the provision of targeted messages, based on specific criteria, to a given set of parities (eg, Nodes). The following are definitions (also discussed above) of some of the main DRM constructs within this exemplary profile hierarchy: Customization - services to obtain the credentials, policies and other objects necessary for a DRM related endpoint (such as a CE device, music player, DRM license server, etc.) establish a valid identity in the context of a specific DRM system. Acquisition of License - services to obtain new DRM licenses. License Translation - services to exchange a new DRM license format for another. Membership - services to obtain various types of objects that establish membership within some designated domains. The NEMO / DRM profile hierarchy can be described, in one modality, as a set of Generic Interface Specifications (describing an abstract set of services, communication patterns and operations), Type Specifications (containing the data types defined in the NEMO profiles) and Concrete Specifications (graphic representation of abstract service interfaces to "specify what is to be done" to "specific protocols.) One modality of these specifications, in the form of Service Definitions and Profile Schemes, is set out in Appendix C attached hereto. 6. ADDITIONAL APPLICATION SCENARIOS FIG. 24 illustrates a relatively simple example of a NEMO mode in operation in the context of a consumer using a new music player to play a song protected by DRM. However, as shown below, even this simple example illustrates many different related application scenarios. This example demonstrates the bridge of discovery services - using discovery of services based on connection and universal reproduction! (UPnP) as a mechanism to find and link to a directory service based on UDDI. It also details service interactions between Personal Area Network (PAN) and Wide Area Network (WAN) services, negotiation of a trusted context for service use and provision of a new device and DRM service. Referring to FIG. 24, a consumer who has purchased a new 2400 music player, wants to play a song protected by DRM. The 2400 player can support this DRM system, but needs to be customized. In other words, the 2400 Player, although it includes certain elements (not shown) that make it both enabled by NEMO as well as DRM capable, a first personalization process to become part of this system. Typically, a NEMO client would include certain basic elements illustrated in FIGS. 5a and 6 above, such as a Service Access Point to invoke other Node services, the Trust Management Processing to demonstrate that it is a trusted resource for reproduction. of certain protected content, as well as a Network Services Stratum to support service invocations and the creation and reception of messages. However, as discussed below, not all of these elements are necessary to allow a Node to participate in a NEMO system. In some embodiments, the client nodes may also include certain basic elements related to DRM, as illustrated in FIG 12a and 13-15 above, such as a DRM client machine and cryptographic services (and related cryptographic objects and keys) in order to allow the processing of protected content, including decryption of protected songs, as well as a media conversion machine to play those songs. Here, some of these elements are not needed either. For example, if the 2400 Player had been a music player that was only capable of playing unprotected content, it might not require the core cryptographic elements present in other music players. More specifically, in the example shown in FIG. 24, the 2400 Player is wireless, supports the UPnP protocols "= - and-Bluetool" -and has a set of certificates ~ "X.509- that you can use to validate signatures and signing messages. The 2400 Player is enabled by NEMO since it can form and process a limited number of NEMO service messages, but does not contain a NEMO Service Access Point due to resource constraints, however, the 2400 Player is able to participate in a Personal Area Network (PAN) ) 2410 in the user's home, which includes a Home Access Route Device, connected to the Internet, enabled by NEMO, 2420, with Bluetooth and an SAP NEMO 2430. The UPnP batteries of both the 2400 and 2420 Access Roads have been extended to support a new type of service profile for a "Pathway enabled by NEMO" service, discussed below When the user downloads a song and attempts to play it, the 2400 Player determines what person needs start and start the process. For example, the 2400 Player can initiate a UPnP service request for a NEMO path in PAN 2410. It locates a NEMO path service and the Access Path 2420 returns the necessary information to allow the 2400 Player to connect to that service. The 2400 Player then forms a NEMO Customization request message and sends it to the access service. The application includes an X.509 certificate associated with the device identity of the 2400 Player. The Access Route 2420, after receiving the request, determines that it can not satisfy the- request- of.- -manage- local, -_ but has -Ya ^ hability - discover other potential service providers. However, Access Route 2420 has a policy that all messages received must be digitally signed and therefore reject the request and return an authorization failure that establishes the policy associated with the processing of this type of request. The player 2400, after receiving this rejection, observes the reason for the service rejection and then digitally signs (for example, as discussed above in connection with the F1G.15) and resubmits the request to the Access Way 2420, which then accepts the message. As previously mentioned, Access Route 2420 can not satisfy this request locally, but it can carry out service discovery. Access Route 2420 is not aware of the specific discovery protocols that support its SAP 2430 implementation and thus composes a service discovery request based on general attributes, based on the type of service desired (personalization) and dispatch the request through SAP 2430. The SAP 2430, configured with the necessary information to speak to UDDl registers, such as a UDDl Registry in Internet Base 2440, converts the request in a native UDDl query the appropriate way and send the query. The UDDL 2440 Registry knows of a service provider that supports DRM personalization and returns the results of the query. SAP 2430 receives these results and returns an appropriate response, with the provider information of ~ 'service n "and" césariá-en "' e1JT: OtmáfcPád" écuádó ^ towards the Viáf de "Acc" escT 2420. Access Route 2420 It extracts the service provider information from the service discovery response and composes a new Customization request based on the initial request on behalf of the 2400 Player. This request is submitted to SAP 2430. The information of the service provider (in in particular, the service interface description of the Customization Service 2450) reveals how SAP 2430 should communicate with a personalization service that exposes its service through a network service described in WSDL. SAP 2430, which adheres to these requirements, invokes the 2450 Customization Service and receives the response. The Access Way 2420 then returns the response to the 2400 Player, which can use the payload of the response to customize its DRM machine. At this point, the 2400 Player is prepared and can participate fully in a variety of consumer-oriented, global and local services. This can provide full visibility and access to a variety of local and remote content services, search, link and license services, and additional automated provisioning services, all cooperating in the consumer service. As explained above, different decryption keys may be necessary to access certain protected content, assuming that the consumer and Player 2400"" "^ satisfy any" policy "that is imposed by the" content provider. " In this way, a consumer who uses a personal media player in the home can enjoy the simplicity of an EC device, but it levels out the services provided by the access path and the parity devices. When the consumer travels to another jurisdiction, the device can rediscover and use most or all of the services available in the home and, through new access path services, logically connect to the home network, while enjoying the services available in the same jurisdiction that are allowed in accordance with the various policies associated with those services. On the contrary, the consumer device can provide parity services found in the new jurisdiction. Clearly, by using some or all of these same constructs (NEMO nodes, SAPs, Service Adaptation Strata, various standards such as XML, WSDL, SOAP, UDDl, etc.), many other scenarios are possible, even within this example of DRM music player. For example, the 2400 Player might have contained its own SAP, perhaps eliminating the need for Access Route 2420. The UDDL 2440 Registry could have been used for other purposes, such as the location and / or licensing of music content. In addition, many other DRM applications could be built, for example, involving a licensing scheme that imposes complex usage and distribution policies-for many different types of -aircHo-and-video, for a variety of different user categories. Also, outside the DRM context, virtually any other service-based application could be built by using the NEMO structure. As another example, consider the application of NEMO in a peer-to-peer business environment. Business application development and integration techniques rapidly evolve beyond the limits of traditional software development tools and lifecycles, as practiced in most IT departments. This includes the development of text processing documents, graphic representations and dissemination sheets. Although some would debate whether these documents in their simplest form represent true applications, consider that many forms of these documents have well-defined and complex object models that are formally described. Such documents or other objects could include, for example, status information that can be inspected and updated during the life cycle of the object, the ability of multiple users to work on the objects concurrently and / or additional arbitrary functionality. In more complicated scenarios, document-based information objects can be assembled schematically to behave as complete applications. As with traditional software development, these types of objects can also benefit from source control and accounting. There are many systems currently that support "" e fná "* ñ" ej'ó ^ "" d * e ~ documents, and many applications directly support a certain form of document control. However, most of these systems in the context of distributed processing environments exhibit limitations, including a centralized approach to managing the version with explicit external and internal verification models and non-flexible coherence policies (very weak or very rigid). ) that relate to client conversion applications or formats particularly within the context of a particular application (for example, a document). Preferred NEMO modalities can be used to address this limitation through a P2P policy architecture that strains the ability to discover and negotiate format. It is possible to structure the creation of an application (for example, a document) in richer ways, which provide multiple advantages. The rich policy can be applied to the objects and the structure of the application. For example, a policy could specify some or all of the following: m Only certain modules can be modified. u Only object interfaces can be extended or exchanged implementations. m Only omissions but not extensions are allowed. * The way in which updates are applied, including functionality such as the automatic emergence of updates without conflict, and the - - ^ "- - ^ - ------ - - - application of updates before" given parity " They can send any of their updates to other parities H Policy-based notification so that all parities can be notified of notifications if they choose it, in order to participate in direct synchronization through the most appropriate mechanisms. It supports updates of different types of 10 clients based on their capabilities.In order to achieve this functionality, the authorization application used by each participant can be a parity enabled by NEMO.For the document that is created, a pattern can be used that describes the policy, including who is authorized and what each part of the document can do (in addition to the normal formatting rules of the document) Since the policy machine used by the NEMO parity can interpret and reinforce policy rules consistent with its semantics, and since the operations supported by the parity interfaces allowed in the creation of the document can be represented in a given parity environment through the Service Adaptation Stratum, then any parity can participate, but it can internally represent the document in a different way. Consider the case of a system that consists of 25 different NEMO parities through the use of services built into the "NEMO structure for collaboration that involves a document of presentation., a wireless PDA application runs an application written in Java, which uses the processing and conversion of the document as text. A different implementation running in Microsoft Windows® on a desktop workstation processes the same document by using the Microsoft Word® format. Both the PDA and the workstation are able to communicate, for example, by connecting over a local area network, thus allowing the user of the PDA and the user of the workstation to collaborate in the same document application. In this example: m NEMO parities involved in the collaboration can discover each other, their current status and their capabilities. m Each NEMO parity is subject to each perceptible change, its identity, change and operation (eg, omission, extension, etc.). * All changes are propagated to each NEMO parity. This is possible because each NEMO parity can discover the profile and capabilities of another parity if it is noticed. At this point, the notification parity may have the content change encoding in an acceptable manner by the notified parity if it is unable to do so. Alternatively, the accepting parity may be presented in any format that fits after reception at its interface. m Before accepting a change, the parity verifies that it comes from an authorized NEMO participant. a The change is applied based on the document policy. As another example, consider the case of a portable wireless consumer electronic device (CE) that is a node enabled by NEMO (X) and that supports DRM A format, but wants to play content in DRM format B. X announces its desire to convert the content as well as a description of its characteristics (for example, what is its identity, which OS does it support, its profile of renewal capacity, payment methods that it supports and / or similar) and it wants answers of return of the other parities N EMO that provide potential solutions. In response to your inquiry, X receives three responses: (1) Parity 1 can provide a low quality downloadable version of content in clear MP3 format for a fee of $ 2.00. (2) Parity 2 can provide payment streams for high quality content execution on a secure channel for $ 0.50 per execution. (3) Parity 3 can provide a software update in X that allows conversion of the content in DRM B format for a fee of _ s- ~ _ _-- - - - $ 10.00. - '"- After reviewing the offers, X determines that option one is the best option Submit a request for content through offer number 1. The request includes a determination of 5 a delegation that allows parity 1 to deduce $ 2.00 from the X payment account through another NEMO service Once X has been loaded, then X is returned in a Parity 1 response with a badge that allows you to download the MP3 file. X would decide that option three was the best solution, a more complicated business transaction could be secured For example, option three may need to be represented as a transactional business process described through the use of a NEMO Orchestration Descriptor (NOD). implemented by the elements of the NEMO Workflow Classifier 5 (WFC) contained in the parities enabled by participating NEMOs In order to carry out the necessary software update for X, the following actions could be executed using the NEMO structure: _. X obtains permission from its wireless service provider (B) that is allowed to receive the update. m The wireless service provider B directly validates the parity three credentials in order to establish their identity. 5 m X download from B a mandatory update that allows you to install updates from third parties, there is no restriction policy for this, but this scenario is the first activating event that originates this action. i X is loaded for the update that provides parity three. * X downloads the parity three update. In this business process, some actions may be able to be carried out concurrently by the WFC elements, while other activities may need to be authorized and executed in a specific sequence. Yet another example of a potential application of the NEMO structure is in the context of online gaming. Many popular multiplayer gaming environment networks are structured as centralized closed portals that allow online players to create and participate in gaming sessions. One of the limitations of these environments is that users must generally have a close relationship with the gaming network and must have an account (usually associated with a particular game title) in order to use the service. The typical player must normally manage multiple game accounts through multiple titles through multi-game networks and interact with specific client applications of the game provider in order to organize multiplayer games and participate within the networks, Co- Trecuencia ,,, esi: o ~ is inconvenient and does not promote online use. The modalities of the NEMO structure can be used to enhance the online gaming experience by creating an environment that supports a more ordered distributed gaming experience, making the user and the service provider transparent to the details of specific online gaming networks. This not only provides a better user experience, thus promoting the adoption and use of these services, but also reduces administrative hassles in the network providers of games. In order to achieve these benefits, game clients can be customized with NEMO modules so that they can participate as NEMO parities. In addition, game networks can be customized with NEMO modules so that they can expose their administrative interfaces in standardized ways. Finally, the NEMO trust management can be used to ensure that only authorized parities interact in proposed ways. For example, suppose there are three gaming network providers A, B, and C, and two users X and Y. User X has an account with A and User Y has an account with B. X and Y both acquire a new account. title that works with C and they want to play with each other. Using the N EMO structure, the game parity of X can automatically discover the online game provider C. The account information of X can be transmitted to C from A, after A - - confirms -qe C is a network give legitimate play. X sé'kégistFa now corór C and can be provisioned with correct badges to interact with C. User Y goes through the same process to gain access to C through the use of his credentials B. Once 5 are registered both X e And, they can now discover each other and create an online game session. This simple example of registration can also be expanded to deal with other services that could provide online gaming environments, including, for example, storage of game badges (for example, in file cabinets), bill payment, and shared status information, such as historical scorecards. Although several examples are presented in the context of business document management, online gambling and consumption of In the case of media content, it will be appreciated that the NEMO structure and the DRM system described herein may be used in any suitable context and are not limited to those specific examples. twenty - - "APPENDIX A" - "" - - - ~~ = SEE 83 FINAL PAGES OF THE SPECIFICATION . . - ____- APPENDIX B SEE 83 FINAL PAGES OF THE SPECIFICATION APPENDIX C Service Definitions and Configuration Schemes Definitions element nsdlc: Base n * d_e_Bwc Complex type nsd! C: Base (n * tttc_Bage J ..-; HUM-- II Complex type nsdlc: Ev? Dencia ÍRftdfc evidence] Complex type nsdlc: Interface connection • • •. { Required evidence tj nsdlc.Connectionofthephase i? HST-I 0..O. TGÍV * "" "Evidence given! '0 ..? - children optional nsdlc element.Connection of thephase / Required evidence Required evidence element nsdlc.Copexiónde.nterfase / Evidence required Evidence given First name Complex type nsdlc: Node Element nsdlc.Node / Servicro Complex type nsdlc Node / lnfodeldentity Kind Complex type nsdlc Infodeldentidad Type complex nsdlc Politics I nsdlc Politics Name space type elements Complex types Id Full type nsdlc-AtpbutodeServicio Complex type nsdlc AtnbutodeServí cío / valor valor Complex type nsdlc ServiceAtpbuto Value I nsdlc alordeAtpbutodeServicio V «__ ._. __ ,,.

Complex type nsdlc.InfodeServic? Element nsdlc Serviceinfo / Interface Element nsdlc InfodeServicio / Atnbuto Complex type nsdlci servicesample nsdIc element: IVService? service / payload nsdIc element: service / state psdlc status: State Status NSWWBKJ element nsdlc.Mensaj'edeService / Service nsdlc element. Service / Use essay Complex type nsdlc.CargaUtildelServicio Complex type elements Type complex nsdlc State Complex type nsdlc CptenoObjective I nsdlc CptenoObjective Simple type nsdlc Message / Use element nsdlc Cr? te_? oObjet? volnfodeldent? dadde_odo element CriteriaObject? voInfodedededededede / Identityinfo mfade identity _r = ü Complex type Infodededededededeferende InfoNodeofReferenceNode element / reference Complex type EvidenceofAssertSAML Í EvidenceAsertoSAlvlL Complex type PoliticsofAsartoSAIVIL Complex type Infode? DentidadSimple JiHS? N !. element InfodeldentidadS.mple / .dsimple Complex type NodoNombradoSimple NodeNombradoSimple element / name E name Complex type C.itertoObjet? VodeTypeofPropertySimple children type Atnbutos Name Id descppci n element CriteriaObjective ofTypePropiedadSimple / servicio_profile serv? c_o_profile Name of Item CriteriaObjective ofType ofPropertySimpIe / service_ _ service Name of CriteriaObjetívodeTipodePropiedadSimpIe / servicioJd servicio id II Name of Complex type Infode.Number of SerialNurner? Rnple f IdentityNodeNumberSepaSimple B ^ 'BI "" j? H "Pnuuuuuuuuuuuuuuuuuuuuuuuuuuuu Id Id xsdxualquier optional URI description xsd: optional string Element Infoof Serial NumberSimple / numberof serial numbers Name ht ??: / www.nemo-commup¡ty.com schemas / pemo / nsdI / 2003 / Q9 / core / ext 01 space type xsd.cadepa Complex type Críter? OObjetivodeTipodeServ? C? OSimpIe diagram extension of nsdlcrCriterioObietivo Service profile service service Id Optional fixed element CriteriaObje_ivoofServÍcioSimpIe / serv? cio_? erfil servici __perfil _ Name of htpp-JwvM.pemo-communÍty.conVscí? Ep.as/nemo/nsdl 20_3 / 09 / core / exU01 space xsdxualquier URI CriteriaObjective element of SimpleServiceType / service_G service Name of the htpp _, / www.nemo-community.com/schemas/nemo/psdl/2003/09/core/exl/01 xsd.cualquter URI Element CriterionSimpleServicePointObjective / serviceJd service id Complex Type Scale Service Value String I Va.Service.Service.And Chain value string element ChainServiceAttribute / chain value chain value Complex type Connection of Network Service Interface Complex type Connection of the Literal Network Service Interface * Interface Network Service Connection • -} Evidence required? ! ConnectionfileServiceLiteralNet -S "" ~ 0 .. «D • -. { Evidence given íjj O .. o service_name_name v ". ,. ._-, .mi-i-n, -_ sri. I- j soap_acc? On I serv? Cto_nombret nterfase R serv? C? Q_URI? nterfase Name of element Connection of the Network Service Interface Literal / service ^ name of the service port_nom brees paciot Element Network Connection Interface Interface / soap_access • soap_action j element Connection of the Literal Network Service Interface / service "name of the Interphase C Serial interface name - Connected element of the Network Literal Service Interface / Service Interface URlmterfase service Complex type Connection of the Network Service Interface WSDL Fixed element Connection of Network Service Interface WSDL wsdLdescription | wsdl_descr? pción 'k i. At, .Ul- ..,.

First name Complex type EvidenceofAssertPolicyWS Name space type Name Id Complex type PoliticadeAsertodePolíticaWS C PoliticaAsertoPoliticaWS (Q Complex type lnfodeldentityofCertifiedX509 lnfoidentityCertifiedX509 _ H3H datacertx509 lnfodeIdentityCertificate elementX509 / datacertificateX509 C datacertx509 Complex type Authorization Complex type Notification Complex type Discopmientual Complex type Discovery Service htpp // www nemo-commumty com / schemas / nemo / psdl 2003/09 / core ext / 01 type extension of nsdlc InfodeServicto filter Interface Attribute Used by Complex Type Discovery of Service Based on Attribute Discovery of Service Based onUDDI Atpbutos Name Fixed Failure Id xsd any optional optional URt Serv? C? O_? Eríi requepdo Service required category requendo Complex type Discovery of Service in Based Service Complex type Request for Discovery of Service Based on Attribute nsdlc LoadUtiService Name of children Name Item ServiceDebugSubstanceBashed inAtpbuto / service_perfÍI ^ serv? c_o_ _ppeerrffiill O Name space type ItemDeviceDiscoveringServiceBasedinAtpbuto / service_category ™ service_category ItemDeleteBuiltServiceDevice inAtpbuto / service_type serv? c? o_j? po Type name Complex type SolIcitud deDecubrimiento de ServicioBasado en Attribute / attribute Complex type ServiceDeviceDevice Response in nsdlc.CargaUülServiceAttribute Complex type ServiceDeviceDevice Response in Attribute / service Complex type Authorization of the service interface Complex type Request for Authorization of the Service Interface Name tppjwww nemo-community com / schemas / nemo / nsdl / 2003/09 / core / exl.01 space type Extension of nsdlc CaroaUtiIdeServicio children Info deserví cío evidence Id descppcióp Complex type Request for Authorization of the Service / infodesservice interface Complex type Request forAutonzation of the service / evidence interface Evidence Complex type Response of Authorization of the Service Interface Fixed Response elementAutonization of the service / infodessy service interface Item ServiceAuthorization Responsepolicy / policy_address political_address Complex type DiscoveryServiceBased inUDDl Complex type SoIicidaddeDecubrimiento deServicioBasado enUDDI RequestDisplayDeviceDeviceBased onUDDl / search criteria diagram Name htpp ^ / www.nemo--ommunity.com / sc emas / nemo / nsdl / 2003 / D9 / core / ext 01 space lipo tmode oclave key value Name Use Fixed Id description Complex type Answer of Discover? M? EntodeServicioBasadoenUDDI diagram Name htp?: //www.nemo-community.com/schemas nemo / nsdl / 2003/09 / core / ext / 01 space type extension of nsdlc: CaroaÜtH disservice service Name Fixed Use Id description Complex type Answer of Service DiscoveryBased onUDDI / servicelarama ht ?? 7 / www.nemo-communiíy.com / schemas / nemo / nsdl / 2003/09 / core / ext / 01 nsdlc: lnfo disservice Attributes Name Type Fixed xsdxualquier URI description xsd.-optional string xsdxualquier URI required Servlcio_categoria? sd -C_alq_yer URI required Service_type xsdxualquire URI required Complex type ReferenceCurveDUD 'tmodeloclave fReferenceconclaveUDDI' keyvalue element ReferenceDVDKey / tmodelocIave element ReferenceCurveUDDI / keyvalor Z clavev vaalloorr j Complex type Discovery.gualUpnP Complex type Request for Discovering Up-to-date UPnP Element for Discovery of Water? UpnP / newsearch Element of Discovery in the UpUpPP / search method -P RequestUpperPolicyUpnP element / searchobject? ? rzt? Element of DiscoveryUpual Unduplication / search data Complex type Answer from DisappaintualualUpnP Type Use xsd any optional URi xsd optional chain Simple Type WletododeBusquedalgualUPnP Simple Type Purpose of SearchlgualUPnP Name of espaao Complex type InfodeClaveCpptografiada InfodeClaveCpptografiada / encpptada Complex type InfodeClaveCpptografiadaPar InfodeCIaveCpptografiadaPar / cIave private element InfodeCiaveCriptograf? adaPar / clavepública Complex type InfoDRM jnfoDRM Complex type License G License | r- > , InfoDRM sa_ Element Ucenc? a /? nfodrm InfoDRM Complex type MembershipTaking MembershipTaking • J InfoDR ^ cESr-SSía. O..co Membership elementTomada / infodrm InfoDR] Complex type Personality Personality element / .nfodrm InfoDRM Complex type Acquisition of License p nsdlc InfoServiciQ Complex type Translation License Complex type Acquisition of embresíaTomada Complex type Personalization Complex type Customization of High Frequency Amplifier Complex type NodeAmpI.ficadordeAltaFrecuenciaDisposit.voA Name Id descppct? N Complex type NodeAffectAffectAsynth / contentprotection key Name Id Complex type NodeAlarm AmplifierFrequencyA device / secretprotection key First name Complex type InfoDRMofAffectAffect INFRARED INFRINGER Name Id descppcton xsd string Complex type LicenseofApplicationAffix í1 LicenseAmplificadi Ut,.,? r gSgS 0 .. D Name D Complex type AcquisitionofAmpHFactorAltaFrequency Complex Type Acquisition of High Frequency Acquisition License Complex Type High Frequency Amplifier Acquisition Response | nsdlc.CargaUtilServicio I j or • * I Complex type UcenciadeAmplifficationofA.taFrecuenc? A Complex Type Request for High Amplifier Transformation Rate Frequency Complex Type Translation Answer Translation ónde Alta Amplifier Frequency Complex type MembershipAffectAffix MembershipTaking MembershipTomada "rviembresIaTomadaAmpfiíicador .. - info 3DDRR oi.» Name htp?: //www.nemo-community.com/schemas/nemo/psdl 2003/09 / drm / svc / ext octopus space type extension of MembreslaTomada Infodrm Fixed Attributes Id description Complex type NodeAmp.AltaFecuencia diagram NodoAmpI¡fícador. " Name of htpp ^ / www.nemo-commupty.com / schemas / pemo / nsdl / 2003/09 / drm / svc / exi octopus space extension type of nsdlc: Base Used by elements Answers to Customization of HighFrequency Amplifier / node of personality Complex type NodeofAltarecuepciaApplianceA Name Type Fixed Fault Id xsdxualquier URI description xsdxadepa optional node type xsdxualquier URI Complex type PersonalityofAmplifierofAltaFrecuenciaTomada diagrama | ' _l "'~' '* ^ Personality PersopalidadAmpliíadorador ... J ¡nfoDRM O..eo Name htpp: //vww.nemo-community.com/sci? Emas / nemo / psdl2003 / 09 / dpt? / Svc / ext / octopus space type extension of Personality Attributes description Complex type Customization of High Frequency Amplifier Complex Type Customization ofAffixAmplifier Frequency nsdlc ChargeUtilService identity Complex type Request for Customization of High Amplifier Frequency / Identity diagram. __ • - •• - _ __ -__ ^ _ - _ ~. I lnfoldent? CedCert? X509 identity datacertx509 'L Complex type High Frequency Amplifier Customization Response Children Name Optional Fixed Id optional description Complex type High-Amplitude Amplifier User Response Frequency / node of personality diagram node-personality.

Fixed Profile Schemes Main Profile Location of the workspace: C: /ws/nemo/schema/nemo-schema-core-01.xsd name of the target space-. http://www.nemo-community.com/schemas/nemo/nsdl/2003/09/core Elements Complex Types Simple Types Base Base Message Use Evidence Interface Connection Node Node Identity Info Policy Service Attribute Service Attribute Value Service Info Service Message Service Payload Status Criteria Objective Main Profile Extension Location of the workspace: C: /ws/nemo/schema/nemo-schema-core-01.xsd name of the target space: http://www.nemo-community.com/schemas/nemo/nsdl/2003/09/core/ext/01 Complex Types Criterion Objective of Node Identity Info Reference Node Identity Info SAML Claim Evidence SAML Assignment Policy Simple ID Identity Node Simple Named Node Criterion Objective of Simple Property Type Identity of Serial Number Node Simple Criteria Simple Service Type Objective Value Chain Service Attribute Network Service Interface Connection Literal Network Service Interface Connection WSDL Network Service Interface Connection WS Policy Awareness WS Policy Awareness Policy WS Certificate Identity Info X509 Main Service Profile location of the burn- C: /ws/nemo/schema/nemo-schema-core-01.xsd name of the target space: http://www.nemo-community.com/schemas/nemo/nsdl/2003/09/core/svc Complex Types Authorization Notification Discovery Equal Discovery of Service Main Service Profile Extension Location of the workspace: C: /ws/nemo/schema/nemo-schema-core-01.xsd name of the target space: http://www.nemo-community.com/schemas/nemo/nsdl/2003/09/core/ext/01 Complex Types Simple Types Discovery of Service Based on Attribute Equal Search Method UPnPP Service Discovery Request Based on Equal Search Objective UPnPP Service Discovery Response Based On Attribute Service Interface Authorization Service Interface Authorization Request Service Interface Authorization Response Service Discovery Based on UDDl Service Discovery Request Based on UDDl Service Discovery Response Based on UDD Reference With UDDl Key Uneven Discovery UPnP Uneven Discovery Request UPnP Uneven Discovery Response UPnP DRM Profile Location of the workspace: C: /ws/nemo/schema/nemo-schema-core-01.xsd name of the target space: http://www.nemo-community.com/schemas/nemo/nsdl/2003/09/drm Complex Types Cryptographed Key Info Cryptographed Key Info Par Info DRM Membership License Taken Personality Profile Extension DRM Location of the workspace: C: /ws/nemo/schema/nemo-schema-core-01.xsd name of the target space: http://www.nemo-community.com/schemas/nemo/nsdl/2003/09/drm/scv Complex Types Acquisition of License Translation License Acquisition of Membership Taken Personalization DRM Profile of High Frequency Amplification Location of the workspace: C: /ws/nemo/schema/nemo-schema-core-01.xsd name of the target space: http: //www.nemo-community.com/schemas/nemo/nsdl/2003/09/drm/scv/ext/ octopus Elements Customization of High Frequency Amplifier Complex types High Frequency Amplifier Node Device A High Frequency Amplifier DRM Info High Frequency Amplifier License Acquisition of High Frequency Amplifier License Application for High Frequency Amplifier License Adquisition High Frequency Amplifier License Acquisition Response High Frequency Amplifier Translation License Application for High Frequency Amplifier Translation License High Frequency Amplifier Translation License Response Membership High Frequency Amplifier Pickup High Frequency Amplifier Node High Frequency Amplifier Personality Amplifier Customization High Frequency Customization Request for High Frequency Amplifier High Frequency Amplifier Customization Response Although the above has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be appreciated within the scope of the appended claims. It should be noted that there are many alternative ways of implementing both the processes and the apparatuses of the present inventions. According to the foregoing, the present embodiments should be considered as illustrative and not restrictive, and the inventive body of work should not be limited to the details given herein, but may be modified within the scope and equivalences of the appended claims. WHAT IS REVINDED IS:

Claims (9)

1. CLAIMS 1. A system for orchestrating services provided by network parities with sufficient interoperability to allow the exchange of values through participation in distributed applications, characterized the system because it comprises: a. a first service provider that has a first layer of service adaptation that exposes a first service interface that enables network working parities to have access, through a first discoverable connection, to a first service offered by the first provider of service; b. a first service consumer having a first service access point that has access to the first service interface exposed by the first service provider, discovers the first connection and invokes the first service by using that connection; and c. a first workflow classifier that orchestrates the necessary steps to enable the first service provider in order to carry out the first service for the first service consumer. The system according to claim 1, characterized in that the first service provides limited access to content of encrypted media, located on a remote server based on the Internet, and the first workflow classifier includes a first control program that verifies if the first service consumer is authorized to have access to the content and, if so, locates the content and provides it to the first service consumer through the first service adaptation stratum. The system according to claim 1, characterized in that the first service interface is specified in WSDL. 4. A system for orchestrating services provided by working parities in res, characterized the system because it includes: a. a first service provider that has a first layer of service adaptation that exposes a first service interface that enables network working parities to have access, through a first discoverable connection, to a first service offered by the first provider of services. service; b. a first service consumer having a first service access point that has access to the first service interface exposed by the first service provider, discovers the first connection and invokes the first service by using that connection; c. a first workflow classifier that orchestrates the steps necessary to enable the first service provider in order to carry out the first service for the first service consumer; and d. a second service provider that has a second layer of service adaptation that exposes a second service interface that enables network working parities to have access, through a second discoverable connection, to the second service that provides access to a registry service that has a directory entry with information to locate and access the first service, where the first service access point has access to the directory entry and uses the information to locate and invoke the first service. The system according to claim 4, characterized in that the service record is a UDDI register. 6. A system characterized in that it comprises: a. a first service provider that has a first layer of service adaptation that exposes a first service interface that enables network working parities to have access, through a first discoverable connection, to a first service offered by the first provider of service; b. a first service consumer having a first service access point that has access to the first service interface exposed by the first service provider, discovers the first connection and invokes the first service by using that connection; c. a first workflow classifier that orchestrates the necessary steps to enable the first service provider in order to carry out the first service for the first service consumer; d. a certificate of trust management to certify the first service to have access only by authorized service consumers; and e. a control program to provide limited access to the first service by using the trusted management certificate, where the first access point uses the trusted management certificate to validate the first service consumer for authorized access to the first service. The system according to claim 6, characterized in that the trust management certificate is an X.509 certificate. The system according to claim 6, characterized in that the trust management certificate is an SSL certificate. 9. "A method for orchestrating services provided by network working parities with sufficient interoperability to allow the exchange of values through participation in distributed applications, characterized the method because it comprises: a. Exposing, from a first stratum of service adaptation of a first service provider, a first service interface that enables a network parity to have access, through a first discoverable connection, to a first service offered by the first service provider; b. to have access, from a first point accessing service from a service consumer, the first service interface exposed by the first service provider, discovering the first connection and invoking the first service by using that connection, and c.contributing, by using a first classifier of workflow, the steps necessary to allow the first service provider to carry out the work First service for the first service consumer. The method according to claim 9, characterized in that the first service provides limited access to encrypted media content, located on a remote server based on the Internet, and the first workflow classifier includes a first control program that verifies if the first service consumer is authorized to have access to the content and, if so, locates the content and provides it to the first service consumer through the first service adaptation stratum. eleven . The method according to claim 9, characterized 'because the first service interface is specified in WSDL. 12. A method for orchestrating services, characterized the method because it comprises: a. exposing, from a first stratum of service adaptation of a first service provider, a first service interface that enables a network parity to have access, through a first discoverable connection, to a first service offered by the first provider of service; b. have access, from a first service access point of a service consumer, to the first service interface exposed by the first service provider, discovering the first connection and invoking the first service by using that connection; and c. orchestrate, through the use of a first workflow classifier, the steps necessary to allow the first service provider to perform the first service for the first service consumer; and d. expose, _from a second stratum-of. adaptation of a second service provider, a second service interface that enables network parities to have access, through a second discoverable connection, a second service offered by the second service provider, providing the second service access to a service record that has a directory entry with information to locate and access the first service, where the first access point to the service has access to the directory entry and uses the information to locate and invoke the first service. The method according to claim 12, characterized in that the service record is a UDDI register. 14. A method characterized in that it comprises: a. exposing, from a first stratum of service adaptation of a first service provider, a first service interface that enables a network parity to have access, through a first discoverable connection, to a first service offered by the first provider of service; b. have access, from a first service access point of a service consumer, to the first service interface exposed by the first service provider, discovering the first connection and invoking the first service by using that connection; orchestrate, by using a first workflow classifier, the steps necessary to allow the first service provider to perform the first service for the first service consumer; d. certify that service, through the use of a trusted management certificate, to have access only by authorized service consumers; and e. execute a control program to provide limited access to the first service by using the trusted management certificate, where the first access point uses the trusted management certificate to validate the first service consumer to have authorized access to the first service. The method according to claim 14, characterized in that the trust management certificate is an X.509 certificate. 16. The method according to claim 14, characterized in that the trust management certificate is an SSL certificate. 17. A method for the orchestration of services, characterized the method because it comprises: a. having access, from a first access point to the service of a service consumer, to a first service interface exposed by a first service provider, the first service interface being operable to allow network parities to have access, through a first discoverable connection, to a first service offered by the first service provider; b. discover the first discoverable connection; and c. invoke the first service through the use of that connection, wherein the steps necessary to carry out the first service are orchestrated by using a first workflow classifier. The method according to claim 17, characterized in that the first service provider limits the access to the encrypted media content located on an Internet-based remote server and the first flow classifier includes a first control program that verifies whether the first The service consumer is authorized to access the content and, if so, locates the content and provides it to the first service consumer through a first stratum of service adaptation. 19. A method characterized in that it comprises: a. exposing, from a first stratum of service adaptation of a first service provider, a first service interface that allows network parities to have access, through a first unavailable connection, to first service offered by the first service provider; b. receive a request for the first service from a first service access point of a first service consumer; and c. orchestrate, by using a first workflow classifier, the steps necessary to allow the first service provider to perform the first service for the first service consumer. 20. A method characterized in that it comprises: a. expose, from a first stratum of service adaptation of a first service provider, a first service interface that allows network working parities to have access, through a first discoverable connection, to a first service offered by the first service provider; b. receive a request for the first service from a first service access point of a first service consumer; c. certify the first service, through the use of a trusted management certificate, to have access only by authorized service consumers; d. "Execute a control program to provide limited access to the first service through the use of the trust management certificate, and e-orchestrate, through the use of a first workflow classifier, the steps necessary to allow the first provider service performs the first service for the first service consumer.