загрузка различных версий медиафайлов в зависимости от типа соединения, используемого при загрузке

Формула изобретения

1. Способ загрузки различных версий одного и того же медиафайла в зависимости от типа соединения, используемого при загрузке, включающий предоставление клиенту в первой транзакции первой версии цифрового медиафайла путем ее загрузки по первому каналу связи, при этом указанная первая версия цифрового медиафайла сжата первым кодеком, выбранным на основе ожидаемой пропускной способности первого канала связи для связи с аппаратной платформой для воспроизведения первой версии цифрового медиафайла; предоставление клиенту во второй транзакции второй версии этого же цифрового медиафайла путем ее загрузки по второму каналу связи, при этом указанная вторая версия цифрового медиафайла сжата вторым кодеком, выбранным на основе ожидаемой пропускной способности второго канала связи для связи с аппаратной платформой для воспроизведения второй версии цифрового медиафайла, которая отличается от ожидаемой пропускной способности первого канала связи; причем во время первой транзакции при загрузке первой версии цифрового медиафайла клиенту предоставляют право на загрузку второй версии цифрового медиафайла.

2. Способ по п.1, в котором первая версия имеет оптимизированное качество звучания в первом диапазоне степени сжатия, а вторая версия имеет оптимизированное качество звучания во втором диапазоне степени сжатия, который отличается от первого.

3. Способ по п.2, в котором в качестве первого кодека используют кодек ААС+.

4. Способ по п.1, в котором первую или вторую версию цифрового медиафайла предоставляют клиенту посредством мобильного телефонного радиоинтерфейса.

5. Способ по п.1, в котором указанный поставщик получает от клиента данные о типе по меньшей мере одного из первого и второго каналов связи до выбора по меньшей мере одного из первого и второго кодеков.

6. Способ по п.1, в котором право на вторую версию цифрового медиафайла подтверждается поставщику посредством цифрового билета.

7. Способ по п.6, в котором цифровой билет предоставляют клиенту во время первой транзакции и поставщику второй версии цифрового медиафайла во время второй транзакции.

8. Способ по п.1, в котором и первая, и вторая транзакции происходят между клиентом и одним и тем же поставщиком медиафайлов.

9. Способ по п.1, в котором первая транзакция имеет место между клиентом и первым поставщиком медиафайлов, а вторая транзакция имеет место между клиентом и вторым, отличным от первого, поставщиком медиафайлов, причем указанный второй поставщик медиафайлов обязан по контракту с первым поставщиком медиафайлов предоставить вторую версию цифрового медиафайла по запросу клиента.

10. Способ по п.1, в котором первая транзакция включает оплату, производимую клиентом, а вторая транзакция не включает в себя отдельную оплату, производимую клиентом.

11. Способ по п.1, в котором и первая, и вторая версии цифрового медиафайла включают песню, которая требует по меньшей мере две минуты для ее проигрывания на нормальной скорости.

12. Способ работы веб-сайта, включающий прием от клиента по сети на сервер поставщика цифровых медиафайлов подтверждения оплаты и типа сетевого соединения, используемого аппаратной платформой для воспроизведения цифрового медиафайла; передачу клиенту первой версии цифрового медиафайла, сжатого первым кодеком, выбранным на основании типа сетевого соединения в зависимости от пропускной способности канала связи, и загрузку цифрового медиафайла на аппаратную платформу для воспроизведения этой версии цифрового медиафайла; предоставление клиенту права на загрузку второй версии этого же медиафайла, который сжат вторым кодеком, при загрузке первой версии цифрового медиафайла.

13. Способ по п.12, в котором право на загрузку включает право на загрузку без дополнительного подтверждения оплаты клиентом.

14. Способ по п.12, включающий заключение соглашения с оператором отдельного веб-сайта, согласно которому указанный второй оператор веб-сайта обещает обеспечивать указанное право на загрузку путем предоставления указанного медиафайла, сжатого вторым кодеком.

15. Способ по п.14, включающий перевод части оплаты, подтвержденной указанным подтверждением оплаты, указанному оператору отдельного веб-сайта.

16. Способ по п.12, в котором указанный прием, указанная передача и указанное предоставление права на загрузку составляют первую транзакцию, при этом способ также включает выполнение последующей второй транзакции, которая включает подтверждение указанного права на загрузку; прием по сети следующего типа сетевого соединения, используемого клиентом; и передачу по сети цифрового медиафайла, сжатого вторым кодеком, который выбран на основании указанного следующего типа сетевого соединения; где указанная вторая транзакция не включает подтверждения клиентом оплаты медиафайла, сжатого вторым кодеком.

17. Способ по п.12, в котором тип сетевого соединения включает мобильное телефонное беспроводное соединение.

18. Способ по п.12, в котором цифровой медиафайл первой транзакции включает анонс фильма, а цифровой медиафайл второй транзакции включает фильм, из которого непосредственно произведен указанный анонс.

19. Система распространения медиафайлов по сети для клиента, включающая по меньшей мере один сервер поставщика цифровых медиафайлов, предназначенных для выбора, в ответ на запрос клиентом выбранного медиафайла по первому сетевому соединению и подтверждение оплаты за загрузку, первой версии выбранного цифрового медиафайла, сжатой первым кодеком, на основании соответствия кодека типу указанного первого сетевого соединения в зависимости от пропускной способности первого сетевого соединения между сервером и аппаратной платформой для воспроизведения первой версии выбранного цифрового медиафайла, для загрузки указанной первой версии по первому сетевому соединению на указанную аппаратную платформу для воспроизведения указанной первой версии выбранного цифрового медиафайла и электронного обязательства для обеспечения загрузки второй версии выбранного цифрового медиафайла без дополнительного подтверждения оплаты выбранного цифрового медиафайла, при этом указанный по меньшей мере один сервер в ответ на предоставление электронного обязательства загружает вторую версию выбранного цифрового медиафайла по второму сетевому соединению на другую аппаратную платформу для воспроизведения второй версии выбранного цифрового медиафайла.

20. Система по п.19, в которой электронное обязательство удостоверяется цифровым билетом, загружаемым вместе с указанной первой версией выбранного цифрового медиафайла.

21. Система по п.19, в котором вторая версия выбранного цифрового медиафайла сжата вторым кодеком, выбранным на основании соответствия второго кодека типу второго сетевого соединения в зависимости от пропускной способности второго сетевого соединения,

22. Система по п.19, в которой первая и вторая версии цифрового медиафайла по существу идентичны, за исключением сжатия разными кодеками.

23. Система по п.19, в которой первая версия цифрового медиафайла по существу идентична только подмножеству второй версии.

24. Система по п.23, в которой первая версия представляет собой анонс фильма, который проигрывается с нормальной скоростью менее чем приблизительно за тридцать секунд, а вторая версия представляет собой целый фильм, который проигрывается с нормальной скоростью более чем приблизительно за девяносто минут.

25. Система распространения медиафайлов по сети для клиента, включающая средство для выбора, в ответ на прием запроса на цифровой медиафайл и подтверждение оплаты по первому каналу связи первого типа, первой версии запрошенного цифрового медиафайла, сжатого первым кодеком; при этом указанный первый кодек соответствует первому типу пропускной способности канала связи между средством загрузки запрошенного цифрового медиафайла и аппаратной платформой для воспроизведения первой версии цифрового медиафайла; и средство для загрузки первой версии запрошенного цифрового медиафайла, сжатого первым кодеком, по первому каналу связи между средством загрузки и аппаратной платформой для воспроизведения первой версии цифрового медиафайла, сжатого первым кодеком, и средство для записи на носитель, читаемый компьютером, электронного обязательства, предназначенного для загрузки второй версии запрошенного цифрового медиафайла, без дополнительного подтверждения оплаты, на соответствующую платформу для воспроизведения второй версии запрошенного цифрового медиафайла.

26. Система по п.25, в которой указанный запрос является первым запросом, а система также включает средство, реагирующее на прием второго запроса на цифровой медиафайл по второму каналу связи второго типа, для проверки подлинности электронного обязательства и выбора запрошенного цуифрового медиафайла, сжатого вторым кодеком, соответствующим второму типу канала связи; и средство для автоматической загрузки по второму каналу связи второй копии запрошенного цифрового медиафайла, сжатого вторым кодеком.

27. Система по п.26, в которой каждое из указанных средств включает читаемые компьютером инструкции, помещенные на читаемом компьютером носителе.

Описание изобретения к патенту

ОБЛАСТЬ ТЕХНИКИ

Данное изобретение относится к загрузке медиафайлов по сетевым соединениям, таким как радиоинтерфейс и проводное соединение с Интернетом, при этом первая загрузка предоставляет файл одного типа или версии и авторизует пользователя для последующей загрузки файла другого типа или другой версии того же самого реального файла. Также настоящее изобретение относится к защите прав на более чем одну копию цифрового медиафайла в рамках одной сетевой транзакции, тогда как различные копии медиафайла предоставляются в рамках более чем одной сетевой транзакции.

УРОВЕНЬ ТЕХНИКИ

Широко принято хранение и распространение музыки в различных форматах цифровых аудиофайлов. Хотя розничный покупатель может владеть легально приобретенным физическим воплощением цифрового музыкального файла, таким как оптический компакт-диск или другое компьютерное средство хранения, которое содержит должным образом загруженную копию музыки, авторское право сохраняет за владельцем право на изготовление и распространение дополнительных копий файла. Владельцы авторских прав на музыку только недавно навели порядок в делах, касающихся неправомочного копирования и распространения по сети, и лицензировали поставщиков музыкального содержания на копирование и распространение по Интернету цифровых версий песен, на которые они обладают авторскими правами.

В связи с существенно большим размером цифровых медиафайлов, которые несут в себе видеосодержание, по сравнению с файлами, которые содержат только аудиоинформацию, только недавно было достигнуто сочетание степени сжатия файла и расширения пропускной способности, необходимое для того, чтобы электронным способом передавать видео за меньшее время, чем требуется для запуска или «проигрывания» видеофайла на нормальной скорости. С преодолением этого технологического барьера некоторые деловые аналитики ожидают, что за прецедентом, созданным музыкальной индустрией, в конечном итоге последует и киноиндустрия. Для краткости указанные аудио- и видеофайлы называются медиафайлами, и они включают музыку, фильмы, видеоклипы (такие как отрывки из фильма и короткие рекламные анонсы) и тому подобное. Копия такого медиафайла, полученная путем загрузки из сети (без сопутствующей передачи носителя данных), называется виртуальной копией медиафайла. Хотя последующее обсуждение касается в первую очередь музыкальных файлов, идеи применимы к любому медиафайлу.

Как правило, виртуальная музыка загружается из Интернета на персональный компьютер. Розничные покупатели часто пересылают музыку, хранимую на их ПК, на портативное цифровое музыкальное устройство, например, такое как iPod®. Портативные цифровые музыкальные устройства являются относительно новым потребительским продуктом, и потребители в целом удовлетворены доступным объемом памяти (на текущий момент обычно 10-40 гигабайт). Тогда как загрузка музыки стала обычным делом, много пользователей ПК оставались связаны с Интернетом или локальной сетью посредством модема и коммутируемого соединения по обычной телефонной линии. Вскоре возникла необходимость сжатия музыкальных файлов так, чтобы передача по сети не занимала чрезмерно большую часть канала передачи данных. Также это позволило портативным музыкальным проигрывателям вмещать больше музыки, что внесло значительный вклад в их быструю адаптацию на рынке.

Цифровые музыкальные файлы кодируются и сжимаются с использованием алгоритма (или таблицы преобразования), который называется кодек (кодер/декодер). Поскольку коммерческая передача сжатой цифровой музыки становится повсеместным явлением, значение кодеков, используемых для ее сжатия, также увеличилось. Несколько различных компаний представили их собственные кодеки, чтобы захватить часть тех доходов, которые могут быть получены прямым лицензированием кодека или косвенно путем предоставления такого значительного количества файлов, требующих этот кодек, чтобы определить выбор оборудования пользователем. Например, МР3, AAC (Advanced Audio Coding (Улучшенное Кодирование Звука), иногда называемое Mpeg-4 Audio) и ААС+ являются хорошо известными кодеками, широко употребляемыми на текущий момент. Microsoft® недавно представил WMA кодек, который конкурирует с МРЗ, используя приблизительно половину объема памяти для обеспечения того, что некоторые пользователи отмечают как равное или лучшее качество звучания. Тогда как МР3 и AAC оптимизированы для проигрывания при уровне сжатия выше 64 кбит/с, кодек ААС+ оптимизирован для проигрывания при уровне сжатия ниже 64 кбит/с. В результате МР3 и AAC производят большие музыкальные файлы, тогда как при прочих равных факторах ААС+ производит меньшие музыкальные файлы. Хотя ААС+ оптимизирован для более низких уровней сжатия, он (по качеству звучания) уступает кодекам, которые производят файлы большего размера.

На фиг.1 показана диаграмма, отражающая отношение качества звука или точности воспроизведения (вертикальная ось) при проигрывании на различных уровнях сжатия (горизонтальная ось) для различных кодеков. Нижняя часть заштрихованной области представляет худший случай работы для каждого кодека, которая для AAC LC и AAC LTP находится в пределах гораздо более старого МР3 формата. Каждый из кодека МР3, AAC LC и AAC LTP дает улучшение точности звучания с увеличением уровня сжатия, тогда как максимальная точность звучания для файла ААС+ достигается приблизительно при сжатии 64 кбит/с.

Известно, что многие портативные цифровые музыкальные проигрыватели имеют возможность проигрывать файлы, используя более чем один кодек, но этому препятствует программное обеспечение управления цифровыми правами (DRM), которое обеспечивает защиту прав на находящиеся в собственности кодеки, упомянутые выше. Короче, файл с расширением МР3, продиктованным форматом, в котором он был загружен, будет проигран портативным цифровым музыкальным проигрывателем только с использованием МР3 кодека. Тогда как музыкальный проигрыватель может иметь возможность пересжать или как-нибудь иначе произвести конвертацию между МР3 и, например, ААС+, это невозможно без определенного нарушения DRM (что может быть запрещено документом Digital Millenium Copyright Act). Однако изобретатель не считает, что портативная цифровая музыка должна быть ограничена назначением определенному устройству, как того требуют ограничения DRM на сегодняшний день.

Общепринято загружать из сети сокращенные музыкальные файлы, такие как мелодии звонков, которые предназначены для мобильных станций. Предполагается, что некто загружает эти мелодии прямо в его мобильную станцию, если эта мобильная станция включает в себя браузер, который имеет доступ к Интернету через мобильный телефонный радиоинтерфейс. Ограниченная пропускная способность этого радиоинтерфейса в сочетании с ограниченным объемом памяти и энергоснабжения мобильной станции делают непрактичным предоставление больших музыкальных файлов для загрузки (например, двух- или трехминутной песни) посредством мобильного телефонного радиоинтерфейса с использованием кодеков, предназначенных для скоростей передачи данных кабельного модема и цифровых абонентских линий. Простое использование кодека, подогнанного под окружение мобильного терминала (меньшие объемы, меньшая передача данных через радиоинтерфейс) не удовлетворяет требованиям большинства потребителей по следующей причине. Ожидается, что потребитель согласится только с тем, что песня, проигрываемая на мобильном терминале, может иметь худшее качество по сравнению со специализированным портативным цифровым музыкальным проигрывателем (например, iPod®), по меньшей мере до тех пор, пока определенные технические препятствия не будут преодолены. Однако те же самые потребители вероятно не склонны принимать это ухудшенное качество звучания песни, когда та же самая песня воспроизводится на устройствах, которые на сегодняшний день предлагают гораздо более высокое качество звучания, таких как портативные МР3 проигрыватели.

Таким образом, требуется позволить пользователям владеть цифровым музыкальным файлом, который оптимизирован для различных аппаратных платформ, на которых может проигрываться музыка.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Данное изобретение предоставляет, с одной стороны, способ работы в сети, такой как Интернет. Этот способ делится на две транзакции, каждая из которых определяется посещением веб-сайта. При первой транзакции потребителю предоставляется первая версия цифрового медиафайла. Первая версия сжата первым кодеком. При второй транзакции потребителю предоставляется вторая версия цифрового медиафайла. Вторая версия отличима от первой, так как она сжата вторым кодеком, тогда как первая сжата первым кодеком. Однако первая и вторая версии содержат в своей основе один и тот же медиафайл, например оцифрованную песню. По восприятию пользователя, первая и вторая версии могут отличаться по качеству, но по меньшей мере часть их содержания идентична. Далее, в соответствии со способом, во время первой транзакции клиенту предоставляется право на получение второй версии цифрового медиафайла. Это право может быть предоставлено в виде цифрового билета или чего-либо подобного, и вторая версия может предоставляться тем же самым или другим поставщиком, что и первая. Преимущество заключается в том, что клиенту требуется перечислить оплату только один раз, во время первой транзакции, чтобы получить права на копии и первой, и второй версий. Поскольку первая и вторая версии оптимизированы в отношении типа сетевого соединения, используемого клиентом (и, таким образом, аппаратной платформы, использующей это соединение), во время первой и второй транзакций, соответственно, то клиент по завершении имеет две различные версии одного и того же в своей основе медиафайла, каждая из которых оптимизирована для аппаратной платформы, на которой клиент проигрывает медиафайл.

Другой аспект данного изобретения описывает способ управления веб-сайтом. Этот способ включает получение от клиента по сети подтверждения оплаты (например, разрешение на списание денег с кредитной карты) и типа сетевого соединения, используемого клиентом. Тип сетевого соединения может определяться вручную пользователем или выбираться оператором веб-сайта на основании цифрового сигнала, который идентифицирует используемое клиентом аппаратное обеспечение (или по отсутствию такого сигнала). Далее, в соответствии со способом, происходит передача клиенту медиафайла, сжатого первым кодеком. Тогда как клиент может выбрать конкретный базовый медиафайл, первый кодек выбирается на основании типа сетевого соединения. Также клиенту предоставляется разрешение на загрузку медиафайла, который может быть сжат вторым кодеком. При различных вариантах применения этого способа, клиент может использовать это разрешение на этом же самом или на другом веб-сайте, чтобы получить другую копию медиафайла. Если соединение, используемое для получения другой копии медиафайла, существенно отличается от описанного ранее соединения (особенно по пропускной способности), то второй кодек отличается от первого кодека, и, таким образом, у клиента оказываются две различные версии одного в своей основе медиафайла.

Еще один аспект данного изобретения состоит в системе распространения по сети музыкальных файлов клиентам. Система включает в себя первый сервер, который отвечает на прием по первому сетевому соединению информации о выбранном музыкальном файле и оплате. Например, клиент может выбрать файл с песней и тип соединения на веб-сайте, расположенном на сервере, и отправить свой выбор, нажав кнопку «послать». Далее сервер автоматически выбирает первую копию выбранного музыкального файла на основе первого типа сетевого соединения, например типа соединения, выбранного клиентом. Первая копия выбранного музыкального файла сжимается первым кодеком. Далее первый сервер автоматически загружает первую копию выбранного музыкального файла по первому сетевому соединению. Читаемые компьютером инструкции фиксируют электронное обещание загрузки второй копии выбранного музыкального файла без дополнительной оплаты. Как и в любом контракте, обещание - это просто обязательство, поэтому любая электронная запись, которая включает в себя обязательство по предоставлению второй копии музыкального файла, удовлетворяет этой части изобретения. Электронное обязательство может быть загружено клиенту вместе с первой копией (и сохранено на электронном носителе данных клиента) в виде цифрового билета. Или же электронное обязательство может быть сохранено на цифровом носителе данных, связанном с сервером, для доступа клиента или другого сервера посредством отправки пароля или какой-либо другой подобной опции защиты. Предпочтительно, второй сервер реагирует на запрос клиентом второй копии выбранного музыкального файла по второму сетевому соединению и прием цифрового обязательства. Далее второй сервер выбирает вторую копию выбранного музыкального файла на основании второго типа сетевого соединения. Вторая копия является выбранным музыкальным файлом, сжатым вторым кодеком. Второй сервер может совпадать с первым, если клиент посещает первый сервер отдельно два раза, или же первый и второй сервер могут быть различными объектами, если клиент загружает первую копию с одного веб-сайта и вторую копию с другого веб-сайта, связанного с первым соглашением о взаимном соблюдении обещаний на загрузку.

Эти и другие аспекты данного изобретения более детально описаны ниже.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Данное описание изобретения иллюстрируется описанными ниже чертежами. Однако следует понимать, что чертежи предназначены исключительно для целей иллюстрации, но не для определения границ изобретения.

Фиг.1 является графиком зависимостей качества звука от степени сжатия для различных кодеков, используемых в настоящее время.

На фиг.2 показано предпочтительное окружение, в котором может применяться настоящее изобретение.

На фиг.3 описаны шаги способа в соответствии с одной реализацией данного изобретения в отношении музыкального файла.

На фиг.4 описаны шаги способа в соответствии с другой реализацией данного изобретения в отношении видеофайла.

ПОДРОБНОЕ ОПИСАНИЕ

Хотя заявленное изобретение описано ниже в основном в отношении цифровых музыкальных файлов, специалист в этой области поймет, что принципы заявленного изобретения применимы к другим типам медиафайлов, например таким, как видео и аудио/видео медиафайлы.

Как показано на фиг.1, файлы, сжимаемые кодеком ААС+, оптимизированы для проигрывания при скорости приблизительно 64 кбит/с, а файлы, сжимаемые кодеком AAC LC, оптимизированы для проигрывания с потоком выше 96 кбит/с. Медиафайлы, сжатые ААС+, меньше тех же файлов, сжатых AAC LC, но хуже по качеству звучания. Фиг.1 отображает качество звука музыкальных файлов, но те же самые принципы сохраняются для качества изображения видеофайлов.

Фиг.2 изображает систему (20) или окружение, в котором данное изобретение может функционировать. Сеть (22) (например, Интернет) включает в себя сетевой сервер или поставщика медиафайлов (24, 26) (например, http://www.appte.com/itunes/ (действительно на 11 февраля 2004)). Поставщик (24, 26) поддерживает базу данных цифровых медиафайлов для их загрузки по сети (22) третьей стороне, медиафайлы могут быть кодированы с использованием одного или более кодеков. Каждый цифровой медиафайл, кодированный отличным от других кодеком, представляет собой отличную от других версию цифрового медиафайла. Пусть цифровой файл, представляющий собой конкретную песню, называется первой версией, когда он кодирован с использованием кодека ААС+ и называется второй версией, когда он кодирован кодеком AAC LTP. Один поставщик медиафайлов (24 или 26) может сделать доступными по сети (22) и первую, и вторую версии цифрового медиафайла (конкретной песни), или первый поставщик (24) может сделать доступной первую версию, а второй поставщик (26) может сделать доступной вторую версию.

Персональный компьютер ПК (28) связан с сетью (22) соединением с высокой пропускной способностью (30), например таким, как коаксиальный кабель и кабельный модем или цифровая абонентская линия. Мобильная станция МС (32) связана с сетью (22) соединением с низкой пропускной способностью (34), например таким, как мобильный телефонный радиоинтерфейс с радиобашней (36). Радиобашня (36), предпочтительно, напрямую связана с сетью (22). ПК (28) и мобильная станция (32) являются различными аппаратными платформами, которые получают доступ в сеть посредством различных типов соединений (каналов связи). Если клиент или пользователь имеет доступ к сети (22) и посредством ПК-соединения с высокой пропускной способностью, и посредством МС-соединения с низкой пропускной способностью, то данное изобретение предоставляет две версии цифрового медиафайла.

Две версии медиафайла отличаются различными кодеками, использованными для сжатия лежащего в их основе (базового) медиафайла. Хотя отдельные клиенты могут решить загрузить обе версии на одну и ту же аппаратную платформу без выхода за рамки данного изобретения в широком смысле, преимущества изобретения наилучшим образом реализуются, когда различные версии загружаются на различные платформы (28, 32) посредством различных соединений (30, 34). Например, поставщик (24, 26) может позволить клиенту загрузить первую версию медиафайла, сжатую ААС+ кодеком, когда запрос сделан посредством соединения по мобильному телефонному радиоинтерфейсу (34) во время первой транзакции. Затем, во время последующей второй транзакции, поставщик (24, 26) позволяет клиенту загрузить вторую версию медиафайла, сжатую кодеком AAC LTP, если клиент запрашивает файл при помощи ПК (28), используя соединение с высокой пропускной способностью (30). Первая версия выбирается с целью уменьшения времени загрузки по причине ограничений на пропускную способность соединения с низкой пропускной способностью (34). Вторая версия выбирается с целью увеличения точности воспроизведения (качества звука в музыкальных файлах), так как ограничения на пропускную способность не являются решающим фактором для соединений (30) с высокой пропускной способностью. В основе вышесказанного лежит предположение, что вторая версия медиафайла будет проигрываться на ПК или будет загружаться с ПК на портативный цифровой музыкальный проигрыватель. В качестве альтернативы, вторая версия может загружаться непосредственно на портативный цифровой музыкальный проигрыватель через беспроводную локальную сеть WLAN (как только беспроводные портативные цифровые музыкальные проигрыватели станут доступны).

Мобильные телефонные сети ограничены в скоростях передачи данных лежащей в их основе сетевой архитектурой (сеть может поддерживать разнообразные архитектуры). GPRS сети теоретически могут передавать данные на скоростях до 115 кбит/с, хотя на практике максимум ограничивается приблизительно 80 кбит/с, а надежная потоковая передача данных в большинстве случаев ограничена приблизительно 18-22 кбит/с. Сети EDGE и UMTS теоретически могут передавать данные на скоростях до 384 кбит/с, но в большинстве случаев надежная потоковая передача данных ограничивается скоростью 50 кбит/с. Мобильные станции (32) также могут ограничивать скорость передачи данных, и не все кодеки поддерживаются всеми мобильными станциями. Как правило, обычные мобильные телефоны (32) ограничены скоростью передачи 34-80 кбит/с, PocketPC® и RealOne® проигрыватели имеют максимум около 200 кбит/с. Хотя эти высокие скорости передачи данных и могут иметь практическое значение при загрузке по беспроводной сети WLAN, но при загрузке по мобильному телефонному соединению (34) все вышеупомянутое показывает, что скорости передачи данных в общем случае ограничиваются скорее мобильной телефонной сетью (приблизительно в пределах 20-50 кбит/с), нежели мобильной станцией (32). Таким образом, для загрузки по мобильному телефонному соединению (34) оптимальным среди кодеков, рассмотренных на фиг.1, является ААС+.

Один из аспектов изобретения состоит в том, что клиент получает права и на первую, и на вторую версии цифрового медиафайла во время первой транзакции, в которой клиент загружает только первую версию. Во время первой транзакции клиент получает доступ к поставщику медиафайлов (24, 26) по сети (22); запрашивает конкретную песню (цифровой медиафайл); производит оплату поставщику медиафайлов (24, 26); и загружает песню (одну версию медиафайла) на аппаратную платформу (28, 32). После загрузки связанного с первой транзакцией файла, клиент покидает сайт поставщика медиафайлов и спустя какое-то время инициирует вторую транзакцию. Клиент обратно получает доступ к поставщику медиафайлов (24, 26), но на этот раз, предпочтительно, с другой аппаратной платформы (28, 32). Клиент запрашивает ту же самую песню, как и в первой транзакции, и загружает песню (другую версию того же самого медиафайла) на другую аппаратную платформу (28, 32) без необходимости осуществления оплаты во время второй транзакции.

Использование одного платежа для двух транзакций поощряет клиента выбирать для загрузки две версии, по меньшей мере, по двум причинам. Во-первых, клиент имеет возможность купить песню в любое время в любом месте, будучи ограниченным только наличием мобильного соединения (34). Мобильные соединения (34) имеются практически везде, поэтому покупки музыки из сети (22) довольно существенны. Это дает клиенту возможность совершать импульсивные покупки, например, услышав первый раз песню на концерте или по радио в машине. Во-вторых, клиент скорее осуществит первую транзакцию, если две версии файла связаны, так как эта связь устраняет опасения в том, что клиент скоро будет разочарован только файлом с низким качеством музыки. Это касается случая, когда первая загрузка происходит с помощью мобильной станции (32). Дополнительно, связывание двух версий одной оплатой уменьшает полные потери продаж в случаях, когда клиент не покупает песню у поставщика медиафайлов (24, 26), и частичные потери продаж в случаях, когда клиент покупает одну, но не обе версии песни по причине высокой сложности проведения оплаты (ввод имени, адреса, номера кредитной карты и т.д.) для каждой версии файла отдельно.

Предпочтительно, чтобы конкретная версия медиафайла, предоставляемого клиенту во время одной или обеих транзакций, выбиралась на основании типа соединения (30, 34) между клиентом и поставщиком (24, 26). Этот выбор может осуществляться различными способами. Поставщик (24, 26) может предоставлять выпадающее меню, в котором клиент выбирает тип соединения (например, мобильный телефон, соединение по коммутируемой телефонной линии/WLAN, широкополосная связь); или же прямой выбор между версиями файла (например, быстрая загрузка, высокое качество). Альтернативно, поставщик (24, 26) может автоматически определить тип аппаратного обеспечения, используемого клиентом, и выбрать конкретную версию файла на основании предположения о наиболее вероятном типе соединения (30, 34), используемого аппаратной платформой (28, 32), совершающей запрос. Например, каждая современная мобильная станция (32) имеет уникальный цифровой код, который встроен по меньшей мере в некоторые ее передачи. Этот уникальный идентификатор используется мобильной телефонной сетью в целях сигнализации и биллинга, но также может передаваться в Интернет для использования операторами веб-сайтов и поставщиками медиафайлов. Конкретно, цифровой код, который идентифицирует запрашивающую аппаратную платформу (28, 32) (по меньшей мере - по типу, такому как ПК (28), мобильная станция (32) и т.д.), может быть встроен в запрос песни клиентом. Поставщик (24, 26) получает доступ к этому встроенному цифровому коду, определяет, что запрашивающая аппаратная платформа является мобильной станцией (32) (например) и выбирает ААС+ версию файла на основании предположения, что загрузка на мобильную станцию (32) будет осуществляться по мобильному телефонному соединению (34). Если запрос не включает в себя код, который идентифицирует запрашивающее оборудование как мобильную станцию (32), поставщик имеет основания предположить, что доступно соединение с высокой пропускной способностью, и выбрать версию файла, основываясь на этом предположении (например, AAC LTP).

Во время первой транзакции, в которой первый поставщик (24) предоставляет клиенту первую версию медиафайла, клиент также получает право на копию второй версии. Конкретная вторая версия (например, AAC LP, AAC LTP) может еще быть не определена на момент первой транзакции, так как это может зависеть от типа соединения (30, 34), используемого при второй транзакции. Независимо от этого, клиент получает право на копию какой-либо второй версии медиафайла во время первой транзакции. Поставщик медиафайлов (24, 26) может предоставить клиенту какие-то доказательства его прав, например такие, как цифровой билет или код доступа или пароль, который предоставляется во время первой транзакции. Желательно, чтобы это право доступа определяло медиафайл и первую версию. Это устраняет для клиента необходимость заново вводить имя выбранной песни во время второй транзакции и предотвращает получение клиентом двух различных медиафайлов (различных песен, а не просто различно кодированных версий одной песни или медиафайла) в двух описанных транзакциях.

Если права доступа подтверждаются кодом доступа или паролем, то единственное, что требуется клиенту, это ввести этот код или пароль на веб-странице поставщика при запросе второй версии медиафайла. Предполагается, что клиенты могут найти чрезмерно обременительными все более и более длинные пароли в случае, когда эти пароли или кода доступа вводятся вручную. Поэтому предпочтителен цифровой билет, который можно передавать электронным способом с одной аппаратной платформы на другую. Этот цифровой билет действует как идентификатор/пароль пользователя, но вводится автоматически, а не вручную клиентом, цифра за цифрой. Например, поставщик медиафайлов (24, 26) может загрузить во время первой транзакции на мобильную станцию (32) клиента цифровой билет вместе с первой версией медиафайла. Позже этот клиент получает доступ к поставщику медиафайлов (24, 26), используя ПК (28). При помощи Bluetooth® соединения, проводного соединения или иного соединения между мобильной станцией (32) и ПК (28) (например такого, какое на сегодняшний день используется для синхронизации адресных книг и расписаний) цифровой билет переносится на ПК (28). Во время второй транзакции цифровой билет посылается посредством соединения (30) с ПК (28) поставщику медиафайлов (24, 26), таким образом подтверждая права на вторую версию медиафайла. Цифровой билет может не определять конкретную версию (AAC LTP, AAC LC и т.д.), которую следует предоставить, так как это может определяться на основании соединения, используемого во второй транзакции. Цифровой билет, в том смысле, в котором он здесь используется, включает в себя любой секретный код, связанный с первой транзакцией данного изобретения, который автоматически загружается клиенту при первой транзакции. Как упомянуто выше, этот самый цифровой билет может быть позже предъявлен клиентом, как доказательство оплаты.

Дополнительная сложность возникает в случае, если первая и вторая версии медиафайла исходят не от одного поставщика медиафайлов. Настоящее изобретение включает случай, когда различные поставщики медиафайлов (24, 26) предоставляют различные версии медиафайла одному клиенту. Это является преимуществом для клиента, так как он может предпочесть одного поставщика (24) для загрузки посредством мобильного телефонного радиоинтерфейса (34) и другого поставщика (26) для загрузки посредством соединения с высокой пропускной способностью. Предпочтения клиента могут основываться на скорости загрузки, легкости использования веб-сайта и т.д. Также данный аспект изобретения позволяет небольшим поставщикам (24, 26), которые могут не иметь всех версий каждого цифрового файла, участвовать в коммерческой деятельности, поддерживаемой настоящим изобретением. Цифровой билет или пароль, описанные выше, могут быть представлены тому же самому поставщику медиафайлов (24), который предоставил первую версию, или второму поставщику (26) для подтверждения прав на вторую версию. Так как оплата совершается только во время первой транзакции, и поэтому только первому поставщику (24), должен существовать юридический договор, по которому второму поставщику (26) гарантируется оплата за признание права доступа (например, цифрового билета или пароля), предоставленного клиенту первым поставщиком (24). Эта гарантия может существовать в форме договорных отношений между первым (24) и вторым (26) поставщиками, или какой-нибудь общепринятой схемы лицензирования, по которой участники получают долю от общих продаж или сборов на основании относительного деления рынка, относительного числа первых и/или вторых версий, загруженных клиентам, или какого-либо иного механизма рыночного распределения. Эта схема лицензирования может быть представлена не в форме традиционного контракта, а может вытекать из предписанных схем лицензирования или широко применяемых ставок роялти, обычных для охраняемых авторским правом работ. В случае применения лицензии может лицензироваться копирование базовой работы (например, вторая версия цифрового медиафайла является копией лежащей в ее основе песни) или копирование производной работы (например, копирование первой версии, модифицированной во вторую версию).

Фиг.3 отображает схему последовательности шагов способа в случае, когда два различных поставщика медиафайлов поставляют различные версии музыкального файла клиенту. В блоке 301 первый и второй поставщики музыкальных файлов входят в соглашение, по которому второй поставщик музыки будет признавать цифровые билеты, выданные первым, а первый будет переводить оплату второму по представлении цифрового билета. Предпочтительно, чтобы поставщики признавали цифровые билеты друг друга и соглашались с условиями контракта, который связывает клиентов, загружающих музыку с их сайтов. Этот контракт с клиентом обычно называется контракт или лицензия «щелчком мыши» и оформляется клиентом путем щелчка по картинке, подписанной «Я согласен» и т.п. Контракт «щелчком мыши», относящийся к загрузке музыки, может включать обещание клиентом оплаты, ограничения ответственности поставщика музыки, серию ограничений для клиента, относящихся к передаче и копированию загруженной музыки, и различные юридические формальности, такие как выбор правовой нормы, место рассмотрения дела и арбитраж.

Позже (блок 302) клиент использует мобильную станцию с возможностью доступа в Интернет для доступа к веб-сайту первого Интернет-поставщика и выбирает файл («песня xyz»), который он желает загрузить. Далее клиент отмечает в выпадающем меню, что он использует мобильное телефонное соединение для доступа к веб-сайту, вводит информацию об оплате (кредитная карта, paypal^тм и т.д.) и вступает в соглашение «контракт щелчком мыши» с первым музыкальным поставщиком. В ответ первый музыкальный поставщик выбирает кодек ААС+ (блок 303), так как это кодек для оптимизации загрузок по мобильному телефонному соединению. Файл «песня xyz», кодированный кодеком ААС+, является первой версией файла, и первый музыкальный поставщик позволяет клиенту загрузить эту первую версию. Первый музыкальный поставщик вместе с первой версией файла также предоставляет клиенту для загрузки цифровой билет.

В блоке 304 клиент загружает первую версию файла «песня xyz», что может быть инициировано первым музыкальным поставщиком или самим клиентом, посредством нажатия на иконку «загрузить» или схожую с ней на веб-сайте первого музыкального поставщика. Цифровой билет загружается вместе с первой версией файла. В блоке 305 клиент покидает веб-сайт первого музыкального поставщика, обозначая тем самым конец первой транзакции, которая включала блоки 302-304.

Некоторое время спустя, например, на следующий день, когда клиент находится дома, он использует свой настольный персональный компьютер для доступа к веб-сайту второго музыкального поставщика (блок 306). Используя Bluetooth® соединение между мобильной станцией и ПК, клиент отправляет цифровой билет, полученный на шаге 304, второму музыкальному поставщику и выбирает в выпадающем меню, что он использует широкополосное соединение для доступа к веб-сайту. Хотя это не проиллюстрировано на фиг.3, предпочтительно, чтобы второй музыкальный поставщик проверил, что отправленный цифровой билет является действительным, например, сравнив его со списком действительных цифровых билетов, опубликованным первым музыкальным поставщиком, или же запросив у первого музыкального поставщика подтверждения, что данный цифровой билет еще не предъявлялся. В случае если использован шаг проверки подлинности цифрового билета, следующие шаги (исключая блок 309) описаны для случая действительного цифрового билета. В блоке 307 второй музыкальный поставщик читает цифровой билет и определяет конкретную песню xyz или лежащий в ее основе исходный файл. Второй музыкальный поставщик выбирает кодек AAC LTP, так как это кодек для оптимизации загрузок по широкополосному соединению. Файл «песня xyz», который кодирован кодеком AAC LTP, является второй версией файла, и второй музыкальный поставщик позволяет клиенту загрузить эту вторую версию. Если соглашение в блоке 301 включало в себя определение контракта с клиентом «щелчком мыши», то второй музыкальный поставщик не обязан требовать от клиента повторного заключения другого контракта, так как первый контракт в блоке 302 содержит защиту, требуемую вторым музыкальным поставщиком, даже если второй поставщик явно не упомянут в контракте «щелчком мыши» в блоке 302. Альтернативно, второй музыкальный поставщик может требовать от клиента заключения отдельного контракта «щелчком мыши».

Далее, клиент загружает вторую версию файла «песня xyz» (блок 308), что может быть инициировано как вторым музыкальным поставщиком, так и самим клиентом (как описывалось выше). Хотя это не отмечено на фиг.3, предпочтительно, чтобы второй музыкальный поставщик оповестил первого музыкального поставщика о том, что определенный цифровой билет обработан, чтобы первый музыкальный поставщик убрал его из базы данных действительных цифровых билетов или внес в список билетов, которые были представлены и обработаны. В блоке 309 клиент покидает веб-сайт второго музыкального поставщика, обозначая конец второй транзакции, которая включала в себя блоки 306-308.

Второй музыкальный поставщик отсылает цифровой билет первому музыкальному поставщику для оплаты в соответствии с соглашением в блоке 301. Это предъявление может совпадать или не совпадать с проверкой действительности цифрового билета, описанной выше. Второй музыкальный поставщик может предъявить цифровой билет первому музыкальному поставщику во время второй транзакции, когда клиент получает вторую версию файла (между блоками 306 и 308), или позже.

Настоящее изобретение наиболее целесообразно применять по отношению к оцифрованным файлам популярной музыки, как в представленном выше описании, таким как песни, длительность которых обычно ограничивается приблизительно тремя минутами и почти всегда превосходит две минуты при проигрывании на нормальной предусмотренной скорости. Также изобретение может применяться для видеоклипов, которые клиент может желать предварительно просмотреть на его мобильной станции (32) и просмотреть с более высоким разрешением на ПК.

В случае применения к цифровым файлам, содержащим видеокомпоненту (как только видео, так и сочетание видео и аудио), базовое содержание первой или второй версии файла может представлять собой только часть базового содержания файла другой версии. Например, первая версия может быть десяти или тридцатисекундным анонсом, который обычно показывают в кинотеатрах для рекламы фильма, который скоро будет выпущен в прокат. Эта первая версия может быть сжата первым кодеком и загружена на мобильную станцию клиента. Соответствующая вторая версия может быть целым фильмом длительностью девяносто и более минут, который клиент выбирает для загрузки на проигрыватель TiVo® или для просмотра непосредственно на своей кабельной телевизионной абонентской приставке с сервера поставщика кабельного телевидения. Такая реализация проиллюстрирована на фиг.4, где клиент получает обе версии от одного поставщика содержания. Фиг.4 может быть адаптирована для двух поставщиков, каждый их которых предоставляет одну версию файла, подобно тому, как показано и описано в процессе на фиг.3.

На фиг.4 клиент получает доступ к веб-сайту поставщика медиафайлов с мобильной станции в блоке 401. В этом примере клиент выбирает базовое содержание «фильм abc», также как в фиг.3 клиент выбирает базовое содержание музыкального файла. Клиент выбирает «мобильное телефонное соединение в качестве соединения, при помощи которого он желает произвести загрузку в первой транзакции. Так как две версии файла на фиг.4 отличаются не только качеством, но и содержанием, то предпочтителен дополнительный шаг с подтверждением того, что клиент желает получить только анонс фильма, такой как пятнадцати- или тридцатисекундный клип. Оплата производится, и контракт «щелчком мыши» заключается точно так же, как выше на фиг.3.

Будучи уверенным в оплате и защите по контракту, в блоке 402 поставщик медиафайлов выбирает первую версию файла, которая представляет выбранный фильм и которая в данном случае называется «фильм abc-анонс», чтобы показать, что это только часть целого фильма, лежащего в основе анонса. Эта первая версия сжимается первым кодеком, который выбирается для оптимизации загрузки по мобильному телефонному соединению. Поставщик медиафайлов связывает цифровой билет с первой версией файла.

Клиент загружает первую версию файла вместе с сопутствующим цифровым билетом в блоке 403 и покидает веб-сайт поставщика медиафайлов в блоке 404, заканчивая тем самым первую транзакцию. Позже в блоке 405 клиент получает доступ к веб-сайту поставщика медиафайлов, чтобы инициировать вторую транзакцию, на этот раз с веб-ТВ браузера, ПК или еще каким-либо образом, подключаясь к сети с использованием соединения другого типа. Клиент вводит свой цифровой билет, выбирает «широкополосное» или «кабельное» в качестве типа соединения и подтверждает, что он теперь желает получить целый фильм. После проверки цифрового билета, предъявленного в этой второй транзакции, в блоке 406 поставщик медиафайлов выбирает базовый фильм на основании информации, содержащейся в цифровом билете, выбирает вторую версию фильма и предоставляет клиенту доступ к этой второй версии. В этом примере вторая версия - это оцифрованная версия целого фильма длительностью девяносто и более минут, названная «фильм abc-целый», и она сжата вторым кодеком, который предпочтительно допускает более высокое разрешение, чем первый кодек.

В блоке 407 клиент загружает вторую версию файла и может сохранить ее, например, на жестком диске ПК, на съемном оптическом диске, загруженном в ПК, или на проигрывателе TiVo. Затем, в блоке 408, клиент покидает веб-сайт поставщика медиафайлов, заканчивая вторую транзакцию.

Некоторые поставщики услуг кабельного телевидения на сегодняшний день хранят целые фильмы в автономных дисковых массивах, связанных с их сетевыми серверами. Поставщик медиафайлов может иметь соглашение с поставщиком кабельного телевидения, по которому, когда клиент получает доступ к веб-сайту поставщика медиафайлов и вводит определенные данные (предпочтительна комбинация ручного и автоматического ввода, которая идентифицирует поставщика кабельного телевидения и клиента первой транзакции), он автоматически перенаправляется на веб-сайт поставщика кабельного телевидения. Клиенту не обязательно загружать и сохранять вторую версию файла, которая может быть целым фильмом, но вместо этого он может смотреть его непосредственно с серверов поставщика услуг кабельного телевидения. Хотя клиент не владеет копией второй версии, DRM может разрешать ему доступ ко второй версии на ограниченный период времени и/или ограниченное количество просмотров. На сегодняшний день владельцы прав на музыку и видео иногда не допускают, чтобы розничные покупатели получали право собственности на загруженную цифровую копию работы, охраняемую авторским правом. Вместо этого они лицензируют конечное число повторений, что автоматически гарантируется инкапсулированным DRM-кодом, который обеспечивает автоматическую порчу или стирание файла после того, как лицензия теряет силу. Такое DRM-лицензирование вместо владения загруженной копией не входит в противоречие с методологией данного изобретения.

Тогда как в примере на фиг.3 использован один и тот же лежащий в основе базовый файл, сжатый различными кодеками, реализация на фиг.4 использует базовые файлы, которые по существу различны. То есть две версии файла в примере на фиг.4 отличаются как по существу, так и по качеству, тогда как две версии файла на фиг.3 отличаются только качеством по причине сжатия различными кодеками. Это приводит к добавлению (предпочтительных) шагов в блоках 401 и 405, на которых клиент подтверждает, какую версию он желает получить. В данном контексте различные по существу версии файла отличаются содержанием, воспринимаемым разумным субъектом, когда медиафайл проигрывается как задумано. Версии файла, различия которых при проигрывании пользователю ограничиваются только объективно измеримыми различиями по качеству, не являются различными по существу, в том смысле, в котором этот термин используется в данном приложении, даже если ни одна строка цифрового кода у этих версий не совпадает. Важный аспект данного изобретения заключается в том, что при нормальном восприятии клиентом или пользователем (медиафайл проигрывается и воспринимается на слух и/или визуально) первая версия и вторая версия идентичны по существу, по меньшей мере частично. Предпочтительно, содержание одной из версий является подмножеством содержания другой версии. Вариант на фиг.3 может использовать версии файла, которые по существу полностью идентичны. Вариант на фиг.4 использует версии файла, которые по существу идентичны только частично.

Незначительные изменения в остальном по существу идентичных базовых частей файла не делают две версии файла отличными друг от друга по существу. Например, добавление логотипа поставщика медиафайлов к анонсу фильма не делает этот анонс с логотипом по существу отличным от целого фильма, который не содержит такой логотип. Такие небольшие изменения анонса составляют производное произведение от целого фильма в рамках авторского права, но производные произведения могут отличаться более значительно, чем такими небольшими изменениями.

Хотя было проиллюстрировано и описано то, что на настоящий момент считается предпочтительной реализацией заявленного изобретения, понятно, что специалисты в данной области вероятно могут сделать а ней многочисленные изменения и модификации. Прилагаемая формула изобретения предполагает охват всех этих изменений и модификаций в рамках заявленного изобретения.