U.S. patent application number 14/805914 was filed with the patent office on 2016-06-30 for layered abstraction systems and methods for persistent content identity.
The applicant listed for this patent is Digimarc Corporation. Invention is credited to Tony F. Rodriguez.
Application Number | 20160191661 14/805914 |
Document ID | / |
Family ID | 39888322 |
Filed Date | 2016-06-30 |
United States Patent
Application |
20160191661 |
Kind Code |
A1 |
Rodriguez; Tony F. |
June 30, 2016 |
LAYERED ABSTRACTION SYSTEMS AND METHODS FOR PERSISTENT CONTENT
IDENTITY
Abstract
This disclosure generally relates to methods and systems for
associating and identifying content, including both physical and
electronic objects, with metadata through networks. The disclosure
also generally relates to routing systems for handling requests
including content identifiers. One combination includes a system
comprising: an external interface including: i) a content interface
for receiving a content signal and a request to provide metadata
associated with the content signal, and ii) a metadata interface
for providing metadata associated with the content signal, in which
the metadata interface includes a variable metadata interface
allowing variable types of metadata to be communicated to a
requesting application through the metadata interface; and an
internal interface including an identity provider interface for
integrating an identity provider driver into the metadata client,
the identity provider driver operable to compute a content
identifier from the content signal and operable to provide the
content identifier to the metadata client; means for invoking the
identity provider driver through the internal interface to request
the content identifier, in which metadata associated with the
content signal is identified with the content identifier and
provided through the metadata interface. Of course, other
combinations are provided as well.
Inventors: |
Rodriguez; Tony F.;
(Portland, OR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Digimarc Corporation |
Beaverton |
OR |
US |
|
|
Family ID: |
39888322 |
Appl. No.: |
14/805914 |
Filed: |
July 22, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12059954 |
Mar 31, 2008 |
9092433 |
|
|
14805914 |
|
|
|
|
60909368 |
Mar 30, 2007 |
|
|
|
Current U.S.
Class: |
709/217 |
Current CPC
Class: |
H04L 67/32 20130101;
G06F 16/904 20190101; G06F 16/48 20190101 |
International
Class: |
H04L 29/08 20060101
H04L029/08; G06F 17/30 20060101 G06F017/30 |
Claims
1. A system comprising: an interface to receive a media content
signal; electronic memory for storing the media content signal;
means for computing a content identifier from the media content
signal, in which the content identifier is computed from the media
content signal using a persistent content identification technology
obtained from a first technology provider; means for forwarding the
content identifier to the first technology provider; means for
receiving metadata from the first technology provider that enables
an identity provider--which is different than the first technology
provider--to provide metadata about the media content signal that
is used to identify the media signal; means for forming a layered
content identifier, the layered content identifier including the
content identifier, an identity provider identifier and a metadata
claim; means for issuing a resolution request to a routing service
to obtain metadata associated with the layered content identifier,
the routing service interpreting the layered content identifier by
forwarding the metadata claim to an identity provider identified by
the identity provider identifier; and means for receiving the
metadata associated with the layered content identifier, in which
the metadata is received in response to the resolution request.
2. The system of claim 1 wherein the metadata claim comprises a
pointer to metadata.
3. The system of claim 1 wherein the metadata claim includes an
access control flag.
4. The system of claim 1 wherein the metadata claim includes a
ratings flag.
5. The system of claim 1 wherein the content identifier is decoded
from digital watermarking hidden in the media content signal.
6. The system of claim 1 wherein the routing service is accessed
over a wireless network.
7. A system comprising: an interface to receive a layered content
identifier, the layered content identifier including a content
identifier, an identity provider identifier and a metadata claim,
wherein the content identifier is computed from a media content
signal; memory for storing the layered content identifier; means
for parsing the layered content identifier to obtain the identity
provider identifier; means for issuing a request, including the
metadata claim, to an identity provider associated with the
identity provider identifier; and means for receiving metadata
associated with the content identifier from the identity provider
in accordance with business rules, the business rules associated
with the layered content identifier or with the identity provider;
and means for associating an identity provider identifier with the
identity provider, in response to a request to enroll an identity
provider.
8. The system of claim 7 wherein the layered content identifier is
received from a requesting metadata client, in which system further
comprises means for providing the metadata to the requesting
metadata client.
9. The system of claim 7 wherein the content identifier is computed
from perceptible attributes of the media signal.
10. A system comprising: an external interface including: i) a
content interface for receiving a content signal and a request to
provide metadata associated with the content signal, and ii) a
metadata interface for providing metadata associated with the
content signal, in which the metadata interface includes a variable
metadata interface allowing variable types of metadata to be
communicated to a requesting application through the metadata
interface; and an internal interface including an identity provider
interface for integrating an identity provider driver into the
metadata client, the identity provider driver operable to compute a
content identifier from the content signal and operable to provide
the content identifier to the metadata client; means for invoking
the identity provider driver through the internal interface to
request the content identifier, in which metadata associated with
the content signal is identified with the content identifier and
provided through the metadata interface.
11. The system of claim 10 including a communication interface that
provides a programmatic interface for communicating the content
identifier to a content resolution service and receiving metadata
in response, said system operable to provide the received response
metadata to a requesting application through the metadata
interface.
12. The system of claim 10 wherein the variable metadata interface
provides an XML representation of variable metadata.
13. The system of claim 10 wherein the content interface comprises
a file based interface for receiving the content signal in a file
format.
14. The system of claim 10 wherein the content interface comprises
a streaming interface for receiving the content signal in a
streaming format.
15. The system of claim 10 wherein the identity provider interface
enables an identity provider driver to be linked into the metadata
client at run time.
16. The system of claim 10 wherein the identity provider interface
enables different identity provider drivers to be linked into the
metadata client.
17. The system of claim 16 wherein the different identity provider
drivers include a digital watermark detector.
18. The system of claim 16 wherein the different identity provider
drivers include a content fingerprint calculator.
19. The system of claim 16 wherein the different identity provider
drivers include a digital watermark detector and a content
fingerprint calculator.
Description
RELATED APPLICATION DATA
[0001] This application is a continuation of U.S. patent
application Ser. No. 12/059,954, filed Mar. 31, 2008 (now U.S. Pat.
No. 9,092,433), which claims the benefit of U.S. Provisional Patent
Application No. 60/909,368, filed Mar. 30, 2007.
[0002] This application is also related to assignee's U.S. patent
application Ser. No. 11/208,441, filed Aug. 19, 2005 (published as
US 2006-0062426 A1), Ser. No. 11/614,921, filed Dec. 21, 2006
(published as US 2007-0156726 A1) and Ser. No. 11/614,947, filed
Dec. 21, 2006 (published as US 2007-0208711 A1).
[0003] Each of the above-mentioned patent documents is hereby
incorporated by reference.
TECHNICAL FIELD
[0004] The disclosure relates generally to methods, apparatus and
systems for associating and/or identifying content (including
physical and/or electronic objects) with metadata through networks.
The disclosure also relates generally to routing systems for
handling requests including content identifiers.
BACKGROUND AND SUMMARY
[0005] One embodiment of the disclosure relates to obtaining
metadata that is associated with content. The term metadata is
broadly used in this patent document and may include, e.g., data
that describes content, quality, condition, origin, and other
characteristics of data (e.g., a song or video title, an artist's
name, related songs or content, copyright information, online
purchase information, links to other information or websites,
ownership information, etc.) The term "content" also may encompass
a wide variety of items including, e.g., audio, video, imagery, and
other electronic content items. Sometimes we use the terms "media",
"media content" and even "signal" to describe "content."
[0006] Returning to the above mentioned embodiment, a "content
identifier" may be computed from a content signal. A content
identifier is a value or number used to identify the content. There
are numerous ways to compute a content identifier. For example,
digital watermarking may be used. Most commonly, digital
watermarking is applied to media such as images, audio signals, and
video signals through slight variations to sample values of the
media. For example, the variations may be introduced to samples in
a so-called orthogonal domain (also termed "non-perceptual," e.g.,
MPEG, DCT, wavelet, etc.) or in quantization values, pixel values,
audio samples, or data representing such. The assignee's U.S. Pat.
Nos. 5,862,260, 6,122,403 and 6,614,914 are illustrative of certain
digital watermarking technologies and are each hereby incorporated
by reference. We also expect that so-called "fingerprinting" can be
used to determine a CID. A fingerprint (e.g., a hash, derived
signature or reduce-bit representation of content) statistically
identifies content item.
[0007] Once a content identifier if obtained, as discussed above, a
"layered content identifier" can be formed. A layered content
identifier preferably includes the content identifier (discussed
above), an "identity provider identifier" and a "metadata claim."
The "identity provider identifier" is a value or number that
identifies an "Identity Provider". An Identity Provider is a party,
entity or system that provides identity preferably in the form of,
e.g., metadata related to content, typically in adherence with
predetermined direction and business rules. A "metadata claim" may
include, e.g., metadata or data indicating a preferred format or
scheme for metadata when obtained or supplied.
[0008] Again, returning to the above embodiment, a resolution
request is issued to a routing service to obtain metadata
associated with the layered content identifier. The routing service
interprets the layered content identifier by, e.g., forwarding the
metadata claim to an identity provider identified by the identity
provider identifier. Then, in response to the resolution request,
the metadata associated with the layered content identifier is
received.
[0009] Before discussing additional and alternative embodiments, a
few items of background are informative.
[0010] Generally, information exists if it has been "acted upon"
(e.g., interpreted, internalized, inferred; see also, dissected,
etc.) to gain understanding. One example of how this is
accomplished is based on an existence of metadata associated with
the information, whether it be implicit and/or explicit, that
allows an observer to climb a semantic stack and place the metadata
information within an ontological model. For discussion, let's
assume the following premise: [0011] (n) information: a message
received and understood
[0012] Information as represented in image, audio and video
content, is of immeasurable value, but is regularly disseminated
with incomplete (or incorrect) metadata that is essential to gain
understanding of the content, be it for an end user or an
associated infrastructure, e.g., the Semantic Web. (The Semantic
Web includes an extension of the World Wide Web in which semantics
of information and services are defined, helping to understand and
fulfill requests from people and machines to use web content.)
[0013] What is needed is a mechanism to identify content and
provide appropriate metadata to enable interpretation and action at
increasingly higher layers in a semantic stack, e.g., from
operations on raw data to execution of business rules. A related
discussion on business rules is found, e.g., in assignee's U.S.
patent application Ser. No. 11/614,947, filed Dec. 21, 2006
(published as US 2007-0208711 A1).
[0014] For small volumes of content that are relatively static,
Operating System (OS) constructs such as filenames, icons, etc.,
are typically used to carry metadata that is "self identifying",
for example, a picture may be named "FamilyVacation2007.mpg". As
the volume of content increases, OS constructs are relegated to
identifying labels that can be acted upon to extract metadata from
an implemented system/file format, such as with an asset management
system or from a file format that supports metadata (e.g., XMP,
etc.)
[0015] To enforce binding an actionable "label" (e.g., a content
identifier) to content, and to an implemented system for the
retrieval of metadata, cryptographic constructs have been used in
the form of traditional Digital Rights Management systems (DRM).
DRM systems allow content owners to determine where/when content is
accessed (e.g., decrypted), providing an opportunity to help ensure
that appropriate infrastructure is in place to make the label
actionable.
[0016] To contend with the existence of multiple DRM solutions,
efforts are underway to provide DRM interoperability in hopes that
content labels remain actionable and metadata can be
retrieved/distributed across DRM boundaries (e.g., DRM
interoperability project "Coral," etc.), but progress has been
slow.
[0017] Assuming the efforts are successful, these techniques are
still reliant on the identifying label (e.g., filename, header, or
other out-of-band information, etc.) remaining intact, something
that rarely occurs once the content is publicly available.
[0018] Also, the reality that all content is ultimately consumed in
an analog form that strips away any of the delivery and labeling
constructs, creates the ever present threat that content may be
re-captured and a new digital instance of the content created, with
the instance likely missing or having incorrect metadata and
incorrect (or missing) labels.
[0019] One result is that a significant volume of content cannot be
accurately identified, greatly complicating attempts to
manage/leverage the content and ultimately leading to confusion,
frustration and lower rates of consumption by consumers.
[0020] One challenge then is to create an infrastructure that
provides information in the form of identifying metadata from the
content itself, independent of representation and environment.
[0021] We return now to additional embodiments.
[0022] In one embodiment, a layered approach is provided, where
identifying metadata is provided by a tiered set of components,
each building on the services (or information) offered or provided
by a lower layer. One result includes an ecosystem, a "Content ID
System," that specifies labels (e.g., a Content ID) and
infrastructure to arrive at an implemented system that is open,
scalable and content agnostic.
[0023] In another embodiment, a method for media content identity
resolution is provided. The method includes: computing a content
identifier from a media content signal; forming a layered content
identifier, the layered content identifier including the content
identifier, an identity provider identifier and a metadata claim;
issuing a resolution request to a routing service to get metadata
associated with the layered content identifier, the routing service
interpreting the layered content identifier by forwarding the
metadata claim to an identity provider identified by the identity
provider identifier; and receiving in response to the resolution
request, the metadata associated with the layered content
identifier.
[0024] In yet another embodiment, a computer readable medium on
which is stored instructions comprising a metadata client is
provided. The metadata client includes: an external interface
including a content interface for receiving a content signal and a
request to provide metadata associated with the content signal, and
a metadata interface for providing metadata associated with the
content signal; and an internal interface including an identity
provider interface for integrating an identity provider driver into
the metadata client, the identity provider driver operable to
compute a content identifier from the content signal and provide
the content identifier to the metadata client. The metadata client
invokes the identity provider driver through the internal interface
to request the content identifier, and the metadata client provides
the metadata associated with the content signal via the content
identifier through the metadata interface.
[0025] The foregoing features, embodiments and advantages will be
even more readily apparent from the following detailed description,
which proceeds with reference to the accompanying drawings. Of
course, additional combinations and embodiments are provided as
well.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] FIG. 1 illustrates interaction with a Content ID System.
[0027] FIG. 2 illustrates one example of a layered content
identifier.
[0028] FIG. 3 illustrates a CID Metadata Client and a CID Router,
and various interactions.
[0029] FIG. 4 illustrates an internal interface.
[0030] FIG. 5 illustrates application layer interaction.
[0031] FIG. 6 illustrates one example of integration of Identity
Providers and Content Owners.
[0032] FIG. 7 illustrates communication paths (and data) relative
to FIG. 1.
DETAILED DESCRIPTION
Content ID System
[0033] A Content ID System may perform many actions including,
e.g.: i) read/form actionable labels (e.g., a Content ID ("CID"));
ii) retrieve/parse metadata based on CIDs; and iii) enable
applications. These actions may occur within an ecosystem that
balances the needs of primary actors in a distribution channel and
in support of, e.g., one or more of the following goals: [0034]
Content/Metadata owner management of meta-data. [0035] Minimal
disclosure of meta-data for a defined use. [0036] Justifiable
parties (security between elements in the ecosystem). [0037]
Pluralism of Identity Providers and technologies. [0038] Human
integration, incorporating content owners for sensitive
applications such as take down notices, warnings, legal actions,
etc. [0039] Consistent experience across contexts for end users.
[0040] Support for fluid migration from proprietary sources of
identity and metadata to fully federated embodiments.
[0041] To achieve one or more of these goals, three functional
layers are identified in Table 1, below. Of course, additional
layers may be provided, and functionality of one layer may be
distributed between several different layers. Thus, this example
should not limit the scope of this embodiment.
[0042] In the embodiment described in Table 1, layers build on each
other and share common characteristics with other layered,
abstraction models such as the, e.g., data, session and application
layers in an OSI Model ("Open Systems Interconnection Basic
Reference Model"). In Table 1, each layer may implement an opaque
interface, fostering interoperability and enabling multiple parties
to interact with the layer.
TABLE-US-00001 TABLE 1 System Functional Examples/Related Layers
Layer Responsibility: Technologies 3 Applications Applications for
content Searching, Content media management Filtering, Audience
Measurement, etc. 2 Content ID Routing and registration DNS,
EPCNET, Services services for Content IDs, Handle System, resulting
in management PURL, URN, etc. and retrieval of metadata 1 Content
ID Enroll/embed/analyze Digital Watermarking, content, resulting in
Fingerprinting, Image content identification Classification,
implementations that Tagging, Natural provide actionable Language,
etc. labels in the form of Content ID's based on a specific
instance of content, or content generally.
Roles
[0043] Identifying roles of existing entities involved in content
management & distribution is helpful when describing how a
Content ID System can be leveraged. A Content ID System may be
implemented to reflect these roles by providing components that
provide the appropriate functionality while minimizing impact to
workflow.
[0044] For example, and with reference to FIG. 1, the following
parties (or systems) are shown:
[0045] Content Owner (CO) [0046] Leverages an Identity Provider in
support of specific media and application scenarios, managing
metadata and routing business rules (e.g., studios and other
content providers). A Content Owner owns or controls content and/or
its associated metadata, and may provide direction and business
rules for its content.
[0047] Identity Provider (IP) [0048] Provides identity in the form
of, e.g., metadata related to a Content ID in adherence with
Content Owner direction and business rules.
[0049] Relying Party (RP) [0050] Distributor of content (e.g., User
Generated Content ("UGC") Operators, creator of Peer-2-Peer
clients, etc.) that benefits from accurate metadata for specific
instances of content.
[0051] Technology Provider (TP) [0052] Content identification
component or service provider leveraged by and/or used by Identity
Provider in support of identity services. One technology component
is a digital watermarking component; another component is a
fingerprinting generator component (e.g., where a Content ID is
derived from the content itself, like a hash or other reduce-bit
identifier). Other content identification technologies are also
known to those of ordinary skill in the art.
[0053] Content ID Enrollment & Routing service (CIDER) [0054]
Routing service, directing Content IDs to appropriate Identity
Providers for resolution (e.g., DNS for Content ID's), etc.
Functional Components
[0055] The Content ID System may be implemented using any number of
technologies, languages, platforms, etc., as long as they support
the functional interfaces defined by a predetermine standard or
specification. For example, a standard may include tags or payload
field identification, format, structure, etc. How the system is
packaged and in what granularity can also be influenced by the
roles discussed above. Still, the system must include a Content ID.
The Content ID represents identity of content within the
system.
Content ID
[0056] A Content ID ("CID" or "layered content identifier")
represents, includes or otherwise provides a First Class Name of a
specific instance of content at whatever granularity is needed
and/or enabled by a lower lever identification technology. This
takes the form of one or more metadata claims that consist of
either metadata itself or pointers to additional metadata. One
Content ID format is shown in FIG. 2 and may include, e.g., the
following fields. Of course, a Content ID may also include a
separate field for a content identifier, e.g., an identifier
derived from the media itself (fingerprint or watermark
identifier). [0057] Identity Provider Identifier: Identifying
number, value or characteristic for a specific Identity Provider
enrolled in the Content ID System. [0058] Examples: [0059]
121=Digital Cinema Identity Services offered by XCinea [0060]
87=Connected Content Identity offered by Digimarc [0061]
A =identifying an open or other standard rule repository [0062]
N-bit alphanumeric value=unique value associated with a party or
system that is enrolled in the Content ID System. [0063] Metadata
Claims: One or more metadata claims represented in public or
private schemas or pointers to such metadata claims. [0064]
Examples: [0065] A 32 bit opaque pointer to DDEX information
provided by an Identity Provider and 8 bits of access control
flags. [0066] 128 bit audio fingerprint. [0067] 96 bit ISAN and 4
bits of rating flags. [0068] 64 bit pointer Identity Provider to
return 96 bit EPCNET payload. [0069] N-bits associated with various
business rule, where N is an integer. [0070] M-bits associated with
a particular DRM system, where M is an integer. [0071] Private
Data: One or more metadata claims represented in public or private
schemas or pointers to such metadata. Private data may be shielded
from view, interpretation or parsing so that only certain parties
(or layers) can interpret such private data. [0072] Examples:
[0073] 32 bit opaque pointer to ISAN information provided by
Identity Provider+8 bits of access control flags. [0074] 96 bit
ISAN+4 bits of rating flags
[0075] Thus, a Content ID may include different fields (e.g.,
Identify Provider, Metadata Claims, and Private Data). In one
example, a Relying Party (FIG. 1) decodes or otherwise obtains a
content identifier (e.g., decodes a digital watermark payload or
calculates a fingerprint). The content identifier may be used as a
portion of a Metadata Claim. An Identity Provider is identified
(e.g., a Provider associated with a particular content identifier
technology or with a particular client device). This
information--perhaps with other information--is combined to form a
CID. The CID is forwarded to a CID Router (e.g., the "CIDER" as
shown in FIG. 1), which uses the Identity Provider identifier to
determine (e.g., via a database lookup) where to forward the CID,
and after so determining, forwards the CID to the Identity
Provider. The Identity Provider uses information from the CID to
provide or look up other related metadata and provides this
information back to the CID Router for forwarding onto the Relying
Party. In some cases the Identity Provider communicates this
metadata directly back to the Relying Party. (The Identity Provider
may hand CIDs and associated requests according to business rules
or other restrictions including in the CID or looked-up based on
information contained in the CID.)
[0076] Of course, these examples are not meant to limit the scope
of the invention. Indeed, a Content ID can carry any combination of
metadata and private data, at varying levels of resolution and
granularity.
[0077] As discussed above, a CID Router is provided a Content ID by
a Relying Party. The CID Router uses an Identity Provider
identifier in a CID to identify an Identity Provider, the remainder
of the CID is preferably passed through to the Identity Provider
with no attempt to parse or interpret either the Metadata Claims or
Private Data. Indeed, this aspect differentiates this system from
other routing system which may try to interpret, parse or otherwise
act on metadata (e.g., content identifiers) contained in
requests.
[0078] Referring now to Table 1, a CID can be generated by layer 1
of a CID system and passed upwards to layer 2 for routing and
resolution of Metadata, similar to an IP address being routing via
DNS server to arrive at specific web page. The metadata is then
provided back to a relying party to be used in accordance with
predetermined (or default) business rules. Examples of business
rules are provided in, e.g., assignee's U.S. patent application
Ser. No. 11/614,947, filed Dec. 21, 2006.
[0079] With reference to FIG. 3, a system is shown including at
least two Content ID system components, e.g., packaged as web
services. These system components may be a CID Metadata Client
(e.g., executing within a domain of a Relying Party) and a CID
Router (e.g., executing within the Content ID Enrollment and
Routing service).
[0080] Of course, an application layer (Layer 3) may interface,
interact or even call the CID metadata Client and/or CID Router.
This interaction is not shown in FIG. 3.
CID Metadata Client
[0081] The CID Metadata Client may include a public and tangible
portion of the CID system. The CID Metadata Client may sit or
reside, e.g., with a Relying Party, which is typically remote from
the CID Router. Indeed, whereas a CID Router may include a web
service operating remotely, the CID Metadata Client can be widely
deployed and may take on many implementations, e.g., from
lightweight libraries to be integrated into a P2P client to highly
optimized, scalable server-based services intended to exist at
point of ingest with UGC operators.
[0082] The CID Metadata Client may provide a singular, stable
interface to the Relying Party. The CID Metadata Client may export
different classes of interfaces to (or for) a Relying Party:
Content, Metadata and Communication.
[0083] Content Interface:
[0084] For a client to provide identity in the form of a CID for an
instance of content, it preferably includes access to content. This
may take on many forms, from a file-based interface in which the
client opens and parses various content file types (e.g., MP3, MPG,
etc.) to a streaming interface where sessions are initiated and
content is streamed in various forms to client (e.g., I frames,
MPEG elementary stream, etc.)
[0085] Metadata Interface:
[0086] While two metadata interfaces are discussed here, many more
may be implemented: i) a first class of interface supports known
schemas for applications such as play control, content filtering,
etc. This may take the form of control flags, ratings information,
etc; ii) a second class of interface provides an opaque interface
to metadata represented as in a standard format, e.g., XML or other
format, allowing any types of metadata to be provided.
[0087] Communication Interface:
[0088] In some embodiments, the client may be required to
communicate with a CID Router to resolve Metadata Claims; if so,
some type of network connectivity is preferred. Depending on the
implementation a Relying Party may need to provide programmatic
access to network resources, such as when integrating the CID
Metadata Client into a P2P implementation. And in server and other
implementations the Relying Party may never be exposed to the
Communication Interface as network access is implicit.
CID Metadata Client Extensibility
[0089] Relying Parties preferably integrate only a singular
component to identify content, regardless of underlying technology
leveraged. To facilitate this, an extensible approach can be used
that allows a CID Metadata Client to leverage new technologies
without changing its existing interface.
[0090] With reference to FIG. 4, an internal interface, e.g., an
Identity Provider Interface (IPI) is provided, allowing components
from Identity Providers to be plugged-into an existing CID Metadata
Client implementation, ideally at run time. The IPI can be thought
of as roughly analogous to a Service Provider Interface for sockets
and the IP Drivers similar in functionality to a mini-driver within
the Windows UniDriver architecture.
[0091] These components, or Identity Provider Drivers, would
encapsulate functionality of Layer 1, or the ability to create a
valid CIDs based on the presence of content. One example of an
Identity Provider component is a digital watermark detection
component provided by a digital watermark Technology Provider.
Another Identity Provider component is a fingerprinting generator
component provided by a fingerprinting Technology Provider. Of
course, there are other components that can be interchanged here as
well. (This illustrates my thought that a content user really
doesn't care which technology is used to identify his content.
Rather, the content user will rely on an Identity Provider to
obtain one or more identifying mechanism and plug-and-play them in
the system.)
[0092] The CID Metadata Client's communication with IP Drivers can
be accomplished through the TPI, which is meant to be opaque,
hiding the details of the CID generation process from the
client.
CID Router
[0093] In addition to the discussion of the CID Router above, a CID
Router may work in conjunction with a sibling service, a CID
Enrollment Service. Analogous to the architecture of DNS, a CID
Router can provide routing services through a single node or a
network of routing nodes that are kept in synchronization.
[0094] Some embodiments may include web services supporting a
common public web interface (e.g., SOAP, XML-RPC, etc.), which are
loosely coupled and may be operating from within the domain of an
Identity Provider. In other embodiments, a central CID Router
facilitates real-time resolution and fosters enrollment of Identity
Providers. As traffic grows, local implementations may also be used
for Relying Parties that generate significant traffic and for whom
caching requests is advantageous.
[0095] In most embodiments, the CID Router will not store metadata,
but may leverage caching schemes to increase performance. Such
caching schemes may be optionally limited by constraints put forth
by metadata owners, such as limiting the time-limits to be cached;
limiting what types of metadata may be cached, etc.
Content ID Resolution Sequence
[0096] The CID Metadata Client and CID Router together drive and
resolve CID requests through their various roles in the ecosystem.
At each step along the way, Metadata Claims can be leveraged if the
schema is known and/or they are resolved to enable further
interpretation.
[0097] An Application layer (e.g., a layer 3) may interact and/or
call the various illustrated services in FIG. 5.
Content ID Deployment
[0098] Similar to digital identity, most existing identity
solutions are monolithic, such as with the Passport system from
Microsoft. Currently Relying Parties and Content Owners are likely
the same entity for many applications and identity is provided by
vendors that combine the functionality of an Identity Provider
& Technology Provider.
[0099] While there will likely always be a need for closed content
identity systems for specific applications, either for reasons of
legacy infrastructure, legislation, etc., the goal however is that
over time the Content ID System become a de-facto standard.
[0100] Eventually those applications that allow for co-location of
roles within the same entity, such as pre-release content, asset
management, etc. also should be considered. Doing so will allow the
higher-level interfaces and functional assumptions to be validated,
without fully implement aspects of Layers 1 & 2 for full
technical interoperability.
[0101] As other applications emerge, a Relying Party as shown in
FIG. 6, will likely represent third parties involved in the
distribution and consumption of content, benefiting, perhaps, from
a federated approach. See, e.g., Ser. No. 11/614,947, filed Dec.
21, 2006 for a related discussion (published as US 2007-0208711
A1). An Identity Provider (#1) may include or closely cooperate
with a Technology Provider, and the Content Owner may include or
closely cooperate with a Relying Party. Metadata claims can be
requested and resolved through communication between such
parties.
[0102] FIG. 7 illustrates even more detailed communication paths
relative to FIG. 1. For example, private data carried by a layered
content identifier can be communicated between and Identity
Provider and a Technology Provider. FIG. 7 shows additional
communication paths as well.
[0103] A broad array of Relying Parties will be become enabled with
a Content ID System. Content distributors and Search Engine
operators (by way of example) can adopt such a system to fulfill
the promise of the Semantic Web, ease navigation of long-tail
content and optimize implementation of business rules.
Additional Details
[0104] A Relying Party may include a Fingerprint generator to
derive an identifier. For example, a CID Metadata Client may
include or cooperate with such a generator, and may include a
generated fingerprint identifier as at least a portion of the
Metadata Claims in a CID. A Relying Party may also include a
watermark decoder to decode an identifier from content. For
example, a CID Metadata Client may include or cooperate with a
watermark detector to decode a watermark from a content item. Some
or all of a decoded watermark identifier can be included as a
portion of a Metadata Claim in a CID.
[0105] A Relying Party may, of course, include both fingerprinting
and watermarking functionality.
CONCLUDING REMARKS
[0106] Having described and illustrated the principles of the
technology with reference to specific implementations, it will be
recognized that the technology can be implemented in many other,
different, forms. To provide a comprehensive disclosure without
unduly lengthening the specification, applicants hereby incorporate
by reference each of the U.S. Patent documents mentioned above.
[0107] The various section headings in this document are provided
for the reader's convenience and provide no substantive
limitations. Of course, the subject matter under one section can be
readily combined with the subject matter under another section.
[0108] The methods, processes, and systems described above may be
implemented in hardware, software or a combination of hardware and
software. For example, the watermark data decoding processes may be
implemented in a programmable computer or a special purpose digital
circuit. Similarly, watermark data decoding may be implemented in
software, firmware, hardware, or combinations of software, firmware
and hardware. The methods and processes described above may be
implemented in programs executed from a system's memory (a computer
readable medium, such as an electronic, optical or magnetic storage
device).
[0109] The various communication lines discusses above and in the
figures may be carried out over local or remote networks,
including, e.g., the internet, cellular (or other wireless)
networks and intranets.
[0110] The particular combinations of elements and features in the
above-detailed embodiments are exemplary only; the interchanging
and substitution of these teachings with other teachings in this
and the incorporated-by-reference US patent documents are also
contemplated.
* * * * *