U.S. patent application number 11/080352 was filed with the patent office on 2005-09-29 for method and apparatus for automatic id management.
Invention is credited to Levy, Kenneth L..
Application Number | 20050216513 11/080352 |
Document ID | / |
Family ID | 34277956 |
Filed Date | 2005-09-29 |
United States Patent
Application |
20050216513 |
Kind Code |
A1 |
Levy, Kenneth L. |
September 29, 2005 |
Method and apparatus for automatic ID management
Abstract
To stop illegal digital content distribution, IDs will be
included in the content. However, current ideas of how to use the
IDs are unacceptable. The automatic ID management process and
apparatus increases the ease of access to protected content for the
consumer, with desired content protection and minimal
implementation costs. The process includes tracking the IDs of the
previously accessed content of a rendering device, reviewing rules
contained within the new content and rendering device, and
restricting access if the new content does not meet the rules. For
example, devices may be limited to accessing content with N
different IDs over a specific time period, where the time period is
influenced by the number of times content with a specific ID is
accessed. The apparatus includes a logic processor and memory that
implements the automatic ID management process.
Inventors: |
Levy, Kenneth L.;
(Stevenson, WA) |
Correspondence
Address: |
DIGIMARC CORPORATION
9405 SW GEMINI DRIVE
BEAVERTON
OR
97008
US
|
Family ID: |
34277956 |
Appl. No.: |
11/080352 |
Filed: |
March 14, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11080352 |
Mar 14, 2005 |
|
|
|
09522312 |
Mar 9, 2000 |
|
|
|
6868497 |
|
|
|
|
60123587 |
Mar 10, 1999 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.107 |
Current CPC
Class: |
H04N 1/32101 20130101;
H04N 2201/3246 20130101; H04N 1/32128 20130101; G06F 21/10
20130101; H04N 2201/3226 20130101 |
Class at
Publication: |
707/104.1 |
International
Class: |
G06F 007/00 |
Claims
What is claimed is:
1. A portable media rendering apparatus comprising: electronic
processing circuitry; and memory, wherein said memory comprises
executable instructions stored therein for execution by the
electronic processing circuitry, the instructions comprising
instructions to: determine an identifier associated with first
media stored in the portable apparatus; control rendering of the
first media by the apparatus through reference to at least i) usage
rules associated with the identifier or first content, and ii) at
least two identifiers associated with second and third media.
2. A method of restricting rendering of content on an apparatus
comprising: i. determining an identifier associated with a content
item prior to rendering the content item; ii. storing the
identifier in list or memory, along with a date the content item is
accessed; iii. rendering the content item; iv. repeating i.-iii.
for each new content item requested for rendering until a
predetermined limit of content identifiers are stored in the list
or memory; and then v. determining whether to allow rendering of
additional content based on usage rules.
3. The method of claim 2 wherein the usage rules comprise a rule to
determine whether to drop an identifier from the list or memory
based on its date.
4. The method of claim 2 wherein the usage rules comprise a rule to
replace an identifier from the list or memory.
5. The method of claim 2 wherein the usage rules comprise a rule to
warn a user of the limit.
6. A method comprising: maintaining a listing of content
identifiers; and deciding whether to render new content based at
least in part on the listing of content identifiers, wherein the
new content includes a content identifier that is not included in
the listing.
7. The method of claim 6 wherein the deciding whether to render new
content is also based on usage rules associated with the new
content.
8. The method of claim 6 further comprising warning a user that the
new content can not be rendered unless an action is taken by the
user.
9. The method of claim 8 wherein the action comprises a purchase.
Description
RELATED APPLICATION DATA
[0001] This application is a continuation of U.S. patent
application Ser. No. 09/522,312, filed Mar. 9, 2000, which claims
the benefit of U.S. Provisional Patent Application No. 60/123,587
filed Mar. 10, 1999. Each of these patent documents is incorporated
herein by reference.
BACKGROUND OF THE INVENTION
[0002] With the influx of digital compression schemes, digital
media copiers, digital playing devices, and the Internet, it has
become relatively simple to illegally copy and distribute digital
content. Therefore, content providers want to allow only the person
who bought content to access (i.e. play, copy or record) that
content. One way to do this is to provide content that contains an
ID, and lock the ID to the consumer, the rendering device or the
storage unit. However, these existing solutions of how to use the
ID produce unreasonable burdens for consumers.
[0003] One existing solution, known as user-binding, requires a
person to carry an ID-card and/or remember a personal
identification number (PIN) to access the content, similar to the
way bank ATM machines work. The consumer has accepted this solution
in order to access money in the bank, a situation where security is
an advantage to the consumer too. However, it is doubtful that
consumers will accept this requirement to access content, for
example, play audio on a car stereo. In addition, when a group of
people are sharing content, such as music, the process of each
person having to scan a card before listening to their music is
obtrusive. Finally, this solution requires data that links the ID
to the user, so PINs and/or ID-cards can be produced. This data
means the user's privacy has been compromised.
[0004] Another existing solution restricts playing of the content
to one device, known as player-binding. This solution means your
friend's music will not play in your car stereo, neither will your
movie play at his house. This solution is not only inconvenient to
the consumer, but also reduces the sale of content since many
people buy content after playing or viewing it with their
friends.
[0005] A final solution links the content to the storage unit,
known as media-binding. The storage unit includes but is not
limited to a magnetic hard drive, optical disk or electronic
memory. This solution becomes cumbersome when the content should be
allowed to move between different storage unit types. For example,
a user, Joe, may want to play his audio from his computer's hard
drive over his home stereo, or have the audio in his car or on a
jog as portable electronic memory. However, with this media-binding
solution, this audio can only be played in one place, and to move
it from Joe's stereo to his car, he has to remember to where it was
"checked out", otherwise, piracy cannot be controlled. Importantly,
he can't just listen to it from each place as desirable to the
consumer.
SUMMARY OF THE INVENTION
[0006] The object of the invented process and apparatus ease the
fashion in which consumers legitimately access protected content
while controlling piracy. The basic concept is that the content
contains an ID that locks it to a particular user or broadcast and
the rendering device automatically determines whether the content
can be accessed based upon the current and previously rendered IDs
and rules. This invention should result in increased sales of
content for the content providers.
[0007] The invented process involves the rendering device keeping
track of the IDs contained in both the current and previously
accessed content. This allows the rendering device to control
access to new content based upon the new content's ID, the rules
provided with the content (by the content providers) and/or within
the device, and the IDs from previously rendered content by the
device.
[0008] The ID may be linked to the user or the broadcast. User IDs
work well for content that is sold for a user's continued use,
whereas broadcast IDs work well for content recorded by the user
from a broadcast.
[0009] An example implementation of the invented process is as
follows. For user-linked content, the rendering device includes
constraints that limit the number of content tracks with different
user IDs that can be accessed in a certain amount of time, possibly
influenced by the number of times content with each user ID has
already been accessed. For broadcast content, broadcast IDs and the
optionally included rules can be used to limit rendering or copying
of each broadcast. In other words, with broadcast IDs, the limits
are based upon date or number of times that ID is played, not on
the total number of broadcast IDs.
[0010] More specifically, a portable MP3 player can keep track of
each song's user ID, and if the previously played songs contain
more than N different user IDs, the player decides if it can
replace an old user ID with the new one due to the old user ID's
date and number of times songs with that ID have been played.
Similarly, if a broadcast ID is contained in memory, the MP3 player
notes that the user has played the audio X times and Y times is
allowed by the broadcast, or the date is past the broadcast's
allowable usage date.
[0011] To this end, it is easy for the consumer to use the device,
as he/she is not required to posses an ID card. In addition, there
is no need for a global database linking the user to the ID; thus,
the user's privacy is not compromised. For example, if a user
looses his/her ID, it can be obtained from previous content.
However, the user or broadcast ID can be kept secret and other
privacy methods can be used with this invention. Most importantly,
access to the media is limited, as the content providers wish, but
the user is not inconvenienced.
[0012] The apparatus to implement this process includes a logic
processor and memory, where it is desirable if the memory maintains
its state when the device is without power. Most devices will
already contain logic processors for rendering the content, and
this process may be implemented on those processors and share time
cycles with the other responsibilities of that processor.
Importantly, the cost of the hardware to implement this process is
minimal since the process is so simple, as desired by the device
manufacturers.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIG. 1 is an overview of the process of automatic ID
management.
[0014] FIG. 2 is the pseudo-code for implementing an exemplar
automatic ID management process.
[0015] FIG. 3 is the apparatus to implement automatic ID
management.
[0016] FIG. 4 is a portable MP3 audio player containing the
apparatus.
DETAILED DESCRIPTION
[0017] Lets begin with some definitions. The rendering device is
the device that can play, view, record or perform a similar action
upon the data. The rendering device can provide any type of
perceived data, including but not limited to images, audio and
video. If the rendering device has a portable section, such as with
a MP3 player, the loader, which puts the content onto the rendering
device, is considered as part of the rendering device. The ID may
be a user or broadcast ID. For example, many MP3 players can also
record broadcasts, and these broadcasts will, in the future,
contain embedded broadcast IDs, possibly as watermarks or header
data with digital broadcasts. Content refers to the desired audio,
video, image, or other relevant perceived data. Content providers
include but are not limited to record labels, movie studios, and
independent artists. The ID may be embedded within the content such
as bits in the header file or a watermark, or the ID can be linked
to the encryption and decryption of the content. Finally, this
automatic ID management may be used in conjunction with other
methods, such as media-binding.
[0018] FIG. 1 displays an overview of the automatic ID management
process. In the process, the rendering device 100 keeps track of
the IDs contained within the content it has previously accessed
(box 110). The rules 120 may be provided in the device hardware
and/or contained with the content. The rules 120 decide whether or
not the device can access the new content based upon its ID (box
130).
[0019] If the rendering device has a portable section, such as with
a MP3 player, the loader, defined above as part of the rendering
device, can be used to lower the amount of memory required within
the portable section, thus lowering its costs. This means that with
a portable rendering device, the portable section may contain all
of the memory and processing hardware (described in detail below)
required to perform this automatic ID handling, or the hardware may
be split between the loader and portable section. For example, when
a computer uses a software loader to put MP3 files onto a portable
MP3 player, the loader may store all the information about IDs on
the computer and all the rendering device needs to do is count the
number of times each song is played and maintain date information
for its current list of content.
[0020] FIG. 2 displays the pseudo-code to implement an example of
the process. In this example, the rules 120 include constraints
245, which are contained within the content as specified by the
content provider, as well as default rules contained with the
rendering device hardware. The constraints 245 are retrieved from
the content 200 (box 240). The constraints 245 may limit the number
of content tracks with different IDs that a device can access
during a set time-period. The constraints 245 may also change the
time-period an ID is stored dependent upon the number of times
content with a specific ID was accessed. The constraints 245 may be
embedded within the content or attached as a header information or
a linked file.
[0021] For ease-of-use, it is better to not change these
constraints per song because it may confuse the user. Ideally, the
constraints should be agreed upon and set in the rendering device.
However, including the rules in the content is a viable option for
this invention.
[0022] Before describing the details of this exemplar process, it
is important to understand the apparatus that implements the
automatic ID management process (FIG. 3). The hardware includes a
logic processor 300 and a memory 310. The logic processor 300 may
be defined as the equivalent of a digital signal processor (DSP),
general-purpose central processing unit (CPU), or a specialized
CPU, including media processors. A likely DSP chip is one of the
Texas Instruments TMS320 product line. A CPU could include one of
Intel's Pentium line or Motorola/IBM's PowerPC product line. The
design of code for controlling logic processor 300 is simple for
someone familiar with the state of the art given the above
pseudo-code and description.
[0023] In addition, a person familiar with the state of the art
could implement the logic processor 300 using analog and digital
circuitry, either separate or in an application specific integrated
circuit (ASIC). The analog and digital circuitry could include any
combination of the following devices: digital-to-analog converters
(D/A), comparators, sample-and-hold circuits, delay elements,
analog-to-digital converters (A/D), and programmable logic
controllers (PLC).
[0024] The memory 310 stores the information required by rules 120,
such as IDs, last play date, and the number of times that content
with each ID has been accessed. Memory 310 may consist of standard
computer random access memory (RAM). It is also desirable if memory
310 maintains this information even without power in the rendering
device, perhaps but not limited to using ROM with backup and
chargeable battery power, or memory that is stable without power,
such as EPROM. As discussed above, memory 310 may consist of two
separate modules when using a portable section and loader.
[0025] Now, back to a detailed description of the example process.
It begins with the device 100 receiving new content 200. From the
content 200, an ID 210 is retrieved. The ID 210 is checked to see
if it is a user or broadcast ID (box 215).
[0026] For user IDs, the following happens. If the ID 210 already
exists in the memory 310 of device 100 (box 220), the play count
and last access date are updated (box 222) and the content 200 is
rendered (box 230). If the ID 210 does not exist in memory 310 (box
220), the rules 120 are checked. If another ID can exist in memory
310 (box 250), ID 210 and the current date are added to the memory
310 (box 260) and the content is rendered (box 230). If another ID
cannot be added, the rules 120 are checked to see if any existing
IDs can be replaced because they are too old (box 270). If any IDs
can be replaced, the old ID is replaced with ID 210 (box 280) and
the content is rendered (box 230). If no IDs can be replaced, the
user may be warned and access to content 200 is denied or limited
(box 290). The user may also be presented with a link to buy the
content (box 290).
[0027] More specifically, the rules may allow a device to store 10
IDs, and IDs can be replaced if they have not been accessed for a
week.
[0028] In addition, the number of times an ID has been rendered
could be used to determine whether or not to replace the old ID
with a new one (box 270). This count value could influence the time
period an ID is held is memory 310; thus allowing ID 210 to replace
a stored ID (boxes 270 and 280). For example, if content associated
with the stored ID has not been accessed in a week, it can be
replaced. Conversely, if content associated with the stored ID has
been played at least 7 times, it should be held for at least a
month since its last access.
[0029] There are many other simple rules that can be designed to
meet the specific needs of the content provider. Some may involve
using difference equations to decide whether or not an ID can be
replaced. For example, the count for an ID can be reduced by one
each day and incremented by one for each rendering of content
containing the ID, and the ID can be replaced (box 270) if the
count is zero or less, or the date of last access is over a
week.
[0030] For broadcast IDs, the following happens. The ID 210 is
examined to see if it already exists in memory 310 (box 255). If
not, the ID 210 and current date are added to the rendering devices
memory 310 (box 265), and the content is rendered (box 230). If the
ID 210 does exist in memory, the play count, record date and/or
last access date are checked to see if the content can be rendered
(box 275). The broadcast may allow only two renders, or one week of
rendering, or rendering until a specific date. If the broadcast is
allowed to be rendered, the count and last access date are updated
(box 285) and the content is accessed (box 230). If the broadcast
is not allowed to be rendered, the user is notified, the access is
limited and a link to buy the broadcast or similar content may be
provided, if applicable (box 295).
[0031] In addition, the device should probably have some way to
reset all of the information, such as IDs, date and count. The
reset function may require a password code that is pseudo-random,
thus requiring the user to contact support to reset the device. For
example, the password may depend upon the day and year and obtained
from an automation system. The reset button may also delete all the
current content as well as ID information. This allows people to
use one portable player with many friends at a party, but the loss
of content will discourage piracy since it will be cumbersome.
[0032] FIG. 4 shows a portable MP3 player 400 that contains the
described apparatus implementing the described pseudo-code. In this
case, the logic processor 300 could be a separate processor, or
share access with the processor that decompresses the audio. The
device also contains the necessary memory 310 to store the required
information, such as ID, data and count, possibly even when the
player 400 is without power. The device may share this memory with
a software loader.
[0033] Finally, in any rendering device, the logic processor 300
could be a separate processor or share time with the processor
handling content for the device, such as compressing or
decompressing digital content.
[0034] In summary, the main advantage of this invention is that it
will be easier for consumers to access protected content than with
prior-art ID methods and apparatus. In addition, it provides the
content protection desired by content providers, and minimal
increase in cost for rendering devices as desired by consumer
electronic manufacturers.
[0035] The foregoing descriptions of the preferred embodiments of
the invention have been presented to teach those skilled in the art
how to best utilize the invention. Many modifications and
variations are possible in light of the above teaching, such as
other simple rules to meet specific content provider goals or
combinations of portable and loader sections. To this end, the
following claims define the scope and spirit of the invention.
* * * * *