Процедуры загрузки для периферийных устройств - RU2331928C2

Чертежи

Показать все 14 чертежа(ей)

Описание

ДАННЫЕ РОДСТВЕННОЙ ЗАЯВКИ

В соответствии с разделом 120 Кодекса законов США по настоящей заявке испрашивается приоритет поданной 16 сентября 2002 г. заявки №10/246367 на патент США под названием "USB DEVICE PROTOCOL FOR A GAMING MACHINE" ("ПРОТОКОЛ USB-УСТРОЙСТВА ДЛЯ ИГРОВОЙ МАШИНЫ"), которая является частичным продолжением поданной 6 августа 2002 г. заявки №10/214255 на патент США под названием "STANDARD PERIPHERAL COMMUNICATION" ("СТАНДАРТНЫЕ СРЕДСТВА СВЯЗИ С ПЕРИФЕРИЕЙ"), которая является продолжением поданной 9 августа 2000 г.заявки №09/635987 на патент США под названием "STANDARD PERIPHERAL COMMUNICATION" ("СТАНДАРТНЫЕ СРЕДСТВА СВЯЗИ С ПЕРИФЕРИЕЙ"), выделенной из поданной 6 октября 1999 г.заявки №09/414659 на патент США под названием "STANDARD PERIPHERAL COMMUNICATION" ("СТАНДАРТНЫЕ СРЕДСТВА СВЯЗИ С ПЕРИФЕРИЕЙ"), которая является в настоящее время патентом США №6251014, каждая из которых включена в данное изобретение путем ссылки.

ПРЕДПОСЫЛКИ К СОЗДАНИЮ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

В индустрии персональных компьютеров занимаются проблемами, относящимися к совместимости устройств, и в последние годы в игровой индустрии появилась потребность в адаптации технологий, используемых в индустрии персональных компьютеров, к игровой индустрии. На первый взгляд можно было думать, что решение проблемы адаптации технологий ПК к игровой индустрии не вызовет сложностей, так как и персональные компьютеры и игровые машины используют микропроцессоры, которые управляют множеством устройств. Однако по таким причинам, как 1) требования по регламенту, "зашитые" в игровую машину, 2) жесткая среда использования игровых машин, 3) требования по безопасности и 4) требования по отказоустойчивости, адаптация технологий ПК к игровой машине может оказаться весьма трудной. Кроме того, технические приемы и способы решения такой проблемы в индустрии ПК, как совместимость устройств и возможность подключения, не отвечают требованиям в игровой среде. Например, дефект или слабое место, допускаемое в ПК, типа дыр в системе защиты в программном обеспечении/аппаратных средствах или частых сбоев, недопустимы в игровой машине, потому что эти дефекты могут приводить к прямой потере денежных средств из игровой машины, такой как кража наличных денег или потеря выручки, когда игровая машина не работает надлежащим образом.

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

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

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

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

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

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

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

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

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

КРАТКОЕ ИЗЛОЖЕНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

Одним объектом настоящего изобретения является игровая машина. Игровая машина может быть в общем охарактеризована как содержащая: 1) ведущий игровой контроллер, адаптированный для i) генерации азартной игры, проводимой на игровой машине путем исполнения множества игровых программный модулей и ii) обмена информацией с одним или более комплектами игровой USB-периферии (USB -универсальная последовательная шина) с использованием USB-совместимой связи; 2) один или более комплектов игровой USB-периферии, соединенных с игровой машиной с возможностью обмена информацией с ведущим игровым контроллером, причем каждый из комплектов игровой USB-периферии содержит: одно или более DFU-совместимых (DFU - обновление аппаратно-программного обеспечения устройств) периферийных USB-устройств; 3) игровую операционную систему на ведущем игровом контроллере, спроектированную для загрузки игровых программных модулей в оперативную память (RAM) для исполнения из запоминающего устройства и для разгрузки игровых программных модулей из RAM; и 4) один или более хост-процессов, загружаемых игровой операционной системой, спроектированных для i) приема идентификатора аппаратно-программного обеспечения из DFU-совместимого периферийного USB-устройства. И) определения аппаратно-программного обеспечения для загрузки в DFU-совместимое периферийное USB-устройство с использованием идентификатора аппаратно-программного обеспечения и iii) загрузки определенного аппаратно-программного обеспечения в DFU-совместимое USB-устройство, причем идентификатор аппаратно-программного обеспечения допускает загрузку различного аппаратно-программного обеспечения для двух DFU-совместимых периферийных USB-устройств с идентичной идентификационной информацией о продукте.

В конкретных примерах осуществления идентификатор аппаратно-программного обеспечения может передаваться в один или более хост-процессов в наборе дескрипторов интерфейса для режима DFU. Кроме того, идентификатор аппаратно-программного обеспечения может передаваться в поле ilnterface набора дескрипторов интерфейса для режима DFU. Поле ilnterface может определять индекс к дескриптору строки. Для задания формата и информации в дескрипторе строки может использоваться протокол идентификации устройств.

В еще одних других примерах осуществления один или более хост-процессов могут являться менеджером классов USB-устройств или драйвером DFU. Один или более хост-процессов могут быть дополнительно спроектированы для 1) выгрузки аппаратно-программного обеспечения из DFU-совместимого USB-устройства, 2) нумерации DFU-совместимого периферийного USB-устройства, 3) поиска базы данных аппаратно-программного обеспечения с использованием информации из идентификатора аппаратно-программного обеспечения, 4) изменения состояния DFU-совместимых периферийных USB-устройств при переходе из режима времени выполнения в режим DFU и обратно, 5) для инициирования запроса на загрузку аппаратно-программного обеспечения с удаленного сервера и 6) загрузки аппаратно-программного обеспечения в DFU-совместимое периферийное USB-устройство при каждом включении питания DFU-совместимого USB-устройства. Игровая машина может быть выполнена с возможностью определения аппаратно-программного обеспечения для загрузки в DFU-совместимое периферийное USB-устройство без использования идентификации фирмы-поставщика или идентификации продукта в наборе дескрипторов, передаваемом в один или более хост-процессов DFU-совместимым периферийным USB-устройством.

В других примерах осуществления по меньшей мере одно DFU-совместимое периферийное USB-устройство может быть спроектировано для самоинициализации 1) без части своего набора дескрипторов времени выполнения или 2) без части аппаратно-программного обеспечения, требуемого для обслуживания DFU-совместимого периферийного USB-устройства. Часть аппаратно-программного обеспечения, требуемого для обслуживания DFU-совместимого периферийного USB-устройства, может включать в себя набор дескрипторов времени выполнения. DFU-совместимое периферийное USB-устройство может являться членом класса стандартных USB-устройств или класса устройств конкретной фирмы-поставщика.

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

В еще одном другом примере осуществления один или более хост-процессов могут быть дополнительно спроектированы для определения условия запуска загрузки аппаратно-программного обеспечения в DFU-совместимое периферийное USB-устройство. Запуск загрузки аппаратно-программного обеспечения может осуществляться при приеме обновления аппаратно-программного обеспечения в DFU-совместимом периферийном USB-устройстве. Прием обновления аппаратно-программного обеспечения может осуществляться с удаленного сервера, участвующего в обмене информацией с игровой машиной. Игровая машина может быть выполнена с возможностью приема сигнала запуска для загрузки аппаратно-программного обеспечения из удаленного игрового устройства и от оператора с использованием интерфейса пользователя, генерируемого в игровой машине. Кроме того, один или более хост-процессов могут быть дополнительно спроектированы для определения условия инициирования загрузки по полученному сигналу запуска, причем инициирование загрузки может являться функцией 1) текущего рабочего состояния игровой машины, 2) времени дня, 3) хронологии использования игровой машины и 4) деталей аппаратно-программного обеспечения, подлежащего загрузке.

В конкретных примерах осуществления игровая машина может быть выполнена с возможностью приема загружаемого аппаратно-программного обеспечения с удаленного сервера. Удаленный сервер может представлять собой игровую машину. DFU-совместимое периферийное USB-устройство может хранить аппаратно-программное обеспечение, загружаемое из игровой машины, в энергозависимой памяти, энергонезависимой памяти или их комбинации. Игровая машина может включать в свой состав запоминающее устройство для хранения санкционированного аппаратно-программного обеспечения для DFU-совместимого периферийного USB-устройства. Аппаратно-программное обеспечение может варьироваться в соответствии с юрисдикцией, на территории которой игровая машина локализована. Санкция на использование аппаратно-программного обеспечения в игровой машине может выдаваться игровой юрисдикцией, фирмой-изготовителем игровой машины, сторонней фирмой-поставщиком и/или ассоциацией по вопросам стандартизации.

В конкретных примерах осуществления игровая операционная система может быть дополнительно спроектирована для 1) для загрузки USB-драйверов с возможностью обмена информацией с аппаратно-программным обеспечением в DFU-совместимом периферийном USB-устройстве, 2) аутентификации идентичности DFU-совместимого периферийного U SB-устройства, 3) аутентификации аппаратно-программного обеспечения, исполняемого DFU-совместимым периферийным USB-устройством, 4) определения идентичности DFU-совместимого периферийного USB-устройства и подтверждения санкции на обслуживание DFU-совместимого периферийного USB-устройства в игровой машине и 5) определения условия инициирования запроса одного или более комплектов игровой USB-периферии на часть аппаратно-программного обеспечения для работы и загрузки запрашиваемого для работы санкционированного аппаратно-программного обеспечения.

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

В конкретных примерах осуществления игровая машина может дополнительно содержать 1) USB-стек, загружаемый игровой операционной системой, спроектированный для обеспечения коммуникационного USB-подключения для каждого из множества комплектов игровой USB-периферии, 2) запоминающее устройство для хранения санкционированного аппаратно-программного обеспечения для DFU-совместимого периферийного USB-устройства, 3) запоминающее устройство для хранения множества игровых программных модулей, 4) USB-совместимый хост-контроллер и/или одно или более периферийных He-USB-устройств. Санкция на использование игровых программных модулей и аппаратно-программного обеспечения в игровой машине выдается игровой юрисдикцией, фирмой-изготовителем игровой машины, сторонней фирмой-поставщиком и/или ассоциацией по вопросам стандартизации.

В других примерах осуществления каждый комплект игровой USB-периферии может содержать: а) USB-совместимое коммуникационное подключение, b) одно или более периферийных устройств, специфических для каждого комплекта игровой USB-периферии, причем каждое периферийное устройство поддерживает одну или более USB-настроек и с) контроллер USB-периферии, спроектированный или сконфигурированный i) для обслуживания одного или более периферийных устройств и ii) для обмена информацией с ведущим игровым контроллером и периферийными устройствами с использованием USB-совместимой связи. Кроме того, контроллер USB-периферии может включать в свой состав энергонезависимую память, предназначенную для хранения а) параметров конфигурации, специфических для отдельного комплекта игровой USB-периферии и/или b) хронологической информации о состояниях комплекта игровой USB периферии. Контроллер USB-периферии может содержать один или более USB-совместимых интерфейсов, причем каждый USB-совместимый интерфейс отображается в отдельной USB-настройке в одном из периферийных устройств.

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

Азартная игра, генерируемая на игровой машине, может быть выбрана из группы, состоящей из традиционных слот-игр, видеослот-игр, игр в покер, игр в патинко, игр в покер на нескольких руках, игр в покер Пай Гау, игр в Блэк Джек, игр в Кено, игр в Бинго, игр в рулетку, игр в кости, игр в шашки, игр за столами и карточных игр.

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

Эти и другие признаки настоящего изобретения будет представлены более подробно в следующем ниже подробном описании изобретения, иллюстрируемом прилагаемыми фигурами.

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

Фиг.1А - чертеж игровой машины, имеющей приставку и другие устройства, в перспективе.

Фиг.1В - блок-схема архитектуры программного обеспечения игровой машины и ее взаимодействия с интерфейсом игровой машины для генерации азартной игры на игровой машине.

Фиг.1C - блок-схема архитектуры программного обеспечения игровой машины, предоставляющей игровое программное обеспечение для генерации азартной игры на игровой машине.

Фиг.2 - блок-схема классов и настроек устройств, обслуживаемых менеджером классов устройств, в соответствии с настоящим изобретением.

Фиг.3 - блок-схема, демонстрирующая связь между прикладными процессами и USB-настройками через драйверы, обслуживаемые менеджером классов USB-устройств.

Фиг.4 - блок-схема, демонстрирующая связь между прикладными процессами и USB-настройками через сторонний драйвер, обслуживаемый менеджером классов USB-устройств.

Фиг.5 - блок-схема игровой машины с ведущим игровым контроллером и множеством игровых устройств.

Фиг.6 - блок-схема процесса инициализации в менеджере классов USB-устройств.

Фиг.7 - блок-схема архитектуры USB-связи, которая может быть использована для обеспечения USB-связи в настоящем изобретении.

Фиг.8 - блок-схема ведущего игрового контроллера, участвующего в обмене информацией с игровым периферийным USB-устройством.

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

Фиг.10 - блок-схема менеджера классов USB-устройств и периферийного устройства при обмене информацией в режиме DFU.

Фиг.11 - блок-схема менеджера классов USB-устройств, загружающего аппаратно-программное обеспечение во множество периферийных устройств.

Фиг.12 - диаграмма взаимодействия между хостом и периферийным устройством во время загрузки аппаратно-программного обеспечения USB в игровую машину.

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

ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ПРИМЕРОВ ОСУЩЕСТВЛЕНИЯ

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

На фиг.1А-С, 2-13 представлена архитектура программного обеспечения USB-связи в соответствии с настоящим изобретением. В частности, на фиг.1А изображена игровая машина с игровыми устройствами для генерации азартной игры и управления этой игрой прежде всего на физическом уровне. Фиг.1В иллюстрирует высокоуровневое описание архитектуры игрового программного обеспечения и ее взаимодействия с интерфейсом игровой машины. На фиг.1C представлены детали архитектуры программного обеспечения игровой машины, включая примеры осуществления архитектуры USB-связи в соответствии с настоящим изобретением. Фиг.2-8 иллюстрируют дополнительные детали архитектуры USB-связи и ее реализации в игровой машине и в игровой системе. Фиг.9-12 - детали процесса загрузки аппаратно-программного обеспечения. На фиг.13 представлена игровая система в соответствии с настоящим изобретением.

На фиг.1А представлен чертеж видеоигровой машины 2, соответствующей настоящему изобретению, в перспективе. Машина 2 содержит основной корпус 4, который, как правило, окружает внутреннюю часть машины (не показанную) и который доступен взгляду пользователей. Со своей передней стороны основной корпус 4 имеет главную дверцу 8, открывающуюся для обеспечения доступа внутрь машины. На поверхность главной дверцы выведены переключатели или кнопки 32 ввода для игрока, монетоприемник 28 и банкнотоприемник 30, лоток 38 для монет и защитное стекло 40. Автомат для выдачи монет, не показанный, может выдавать монеты в лоток для монет. Через главную дверцу можно видеть монитор 34 видеодисплея и информационную панель 36. Монитор 34 дисплея, как правило, представляет собой катодно-лучевую трубку, плоскопанельный ЖК дисплей с высоким разрешением или другой обычный видеомонитор с электронным управлением. Информационная панель 36 может представлять собой стеклянную панель с задней подсветкой и выполненными методом трафаретной печати надписями для отображения общей игровой информации, в том числе, например, количества играющих монет. Предлагаемая в данном изобретении игровая машина может обеспечить ведение всевозможных игр, в том числе традиционных слот-игр, видеослот-игр, игр в покер, игр в патинко, игр в покер на нескольких руках, игр в покер Пай Гау, игр в Блэк Джек, игр в Кено, игр в Бинго, игр в рулетку, игр в кости, игр в шашки, игр за столами и карточных игр.

Банкнотоприемник 30, монетоприемник 28, переключатели 32 ввода для игрока, монитор 34 видеодисплея и информационная панель являются устройствами, используемыми для ведения азартной игры на игровой машине 2. Управление этими устройствами осуществляется схемами (см. фиг.5), размещенными внутри основного корпуса 4 машины 2. Эти схемы управления в корпусе именуются в настоящем изобретении "ведущим игровым контроллером". При работе этих устройств может генерироваться критическая информация, хранимая в энергонезависимом запоминающем устройстве 234 (см. фиг.5), локализованном внутри игровой машины 2. Например, когда наличные деньги или кредитный денежный знак вносятся в игровую машину с помощью банкнотоприемника 30 или монетоприемника 28, сумма наличных денег или кредита, внесенного в игровую машину 2, может храниться в энергонезависимом запоминающем устройстве 234. В другом примере, когда важная игровая информация, например конечное положение слот-барабанов в видеослот-игре, отображается на мониторе 34 видеодисплея, хронологическая игровая информация, необходимая, для восстановления визуального отображения слот-барабанов, может храниться в энергонезависимом запоминающем устройстве. Тип информации, хранимой в энергонезависимой памяти, может определяться в соответствии с требованиями операторов игровой машины и нормами, определяющими технические требования для игровых машин в различных игровых юрисдикциях.

Игровая машина 2 имеет в своем составе приставку 6, которая установлена на верхней поверхности основного корпуса 4. Внутри приставки 6 находится ряд устройств, которые могут быть использованы для придания дополнительных настроек игре, проводимой на игровой машине 2, в том числе динамики 10, 12, 14, билетопечатающее устройство 18, которое может печатать билеты 20 со штриховым кодом, малая клавишная панель 22 для ввода данных трекинга игрока, флуоресцентный дисплей 16 для отображения информации по трекингу игрока и считыватель 24 карточек для ввода карточки с магнитной полосой, содержащей данные трекинга игрока. Кроме того, в приставке 6 могут быть размещены отличные от показанных на фиг.1А или дополнительные устройства. Например, приставка может содержать бонусное колесо или панель с задней подсветкой и надписями, выполненными методом трафаретной печати, которые могут быть использованы для придания игре, проводимой на игровой машине, бонусных настроек.

Многие из игровых устройств в игровой машине 2 могут быть непосредственно подключены к ведущему игровому контроллеру 224 (см. фиг.5) с возможностью обмена информацией через различные внутренние жгуты проводов в корпусе 4 и приставке 6 или могут быть подключены к ведущему игровому контроллеру через промежуточные игровые устройства и узлы коммуникаций с возможностью обмена информацией с ведущим игровым контроллером. Во время азартной игры ведущий игровой контроллер 224, размещенный внутри основного корпуса 4 машины 2, может управлять этими устройствами.

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

Понятно, что игровая машина 2 является всего лишь одним примером из множества различных конструкций игровых машин, в которых настоящее изобретение может быть внедрено. Например, не все подходящие игровые машины имеют приставки или настройки трекинга игрока. Кроме того, некоторые игровые машины имеют только один игровой дисплей - механический или видео, в то время как другие спроектированы для барных стоек и имеют дисплеи с экраном, обращенным вверх. В другом примере игра может генерироваться на хост-компьютере и может отображаться на удаленном терминале или удаленном игровом устройстве. Удаленное игровое устройство может быть подключено к хост-компьютеру посредством сети какого-либо типа, такой как локальная сеть, большая сеть, интрасеть или Internet. Удаленное игровое устройство может быть портативным игровым устройство типа телефона сотовой связи, персонального цифрового секретаря, беспроводного игрового плейера и др. Изображения, визуализированные из трехмерных игровых сред, могут отображаться на портативных игровых устройствах, которые используются для проведения азартной игры. Кроме того, игровая машина или сервер могут содержать игровую логику для управления удаленным игровым устройством с целью визуализации изображения из виртуальной камеры в трехмерных игровых средах, хранимых на удаленном игровом устройстве, и отображать визуализированное изображение на дисплее, локализованном на удаленном игровом устройстве. Поэтому специалистам в данной области техники должно быть очевидно, что настоящее изобретение, описываемое ниже, может быть развернуто на большинстве любых игровых машин, которые существуют в настоящее время или будут разработаны в будущем.

Как показано в примере на фигуре 1 А, когда пользователь желает провести игру на игровой машине 2, он или она вводит наличные деньги через монетоприемник 28 или банкнотоприемник 30. Игрок может также вставить игровой жетон, используемый как денежные кредитные знаки, или активизировать денежные кредитные знаки, хранимые на безналичном инструменте, типа смарт-карточки, карточки с магнитной полосой или напечатанного билета, посредством устройство ввода на игровой машине. В примере банкнотоприемник может принимать напечатанные билеты-ваучеры, которые могут приниматься банкнотоприемником 30 как денежные кредитные знаки для ведения игры. Безналичные инструменты могут также хранить поощрительные кредиты, которые могут быть использованы для ведения игры на игровой машине. Во время игры игрок обычно просматривает игровую информацию и наблюдает за ходом игры с помощью видеодисплея 34.

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

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

Архитектура USB-совместимой связи, соответствующая настоящему изобретению, может быть встроена в модуль трекинга игрока и другие игровые устройства, которые могут быть подключены к игровой машине, но не находиться под непосредственным управлением со стороны ведущего игрового контроллера в составе игровой машине. Например, модуль трекинга игрока может включать в свой состав логическое устройство, работающее независимо от ведущего игрового контроллера и непосредственно управляющее рядом периферийных устройств типа считывателя карточек, источников света, экрана видеодисплея и кнопочной панели. Части архитектуры USB-связи, соответствующей настоящему изобретению, могут использоваться логическим устройством в модуле трекинга игрока для обслуживания периферийных устройств, управляемых логическим устройством. Детали модулей трекинга игрока, которые могут быть использованы в настоящем изобретении, описаны в совместно рассматриваемой заявке №10/246373 США под названием "PLAYER TRACKING COMMUNICATION MECHANISMS IN A GAMING MACHINE" ("КОММУНИКАЦИОННЫЕ МЕХАНИЗМЫ ТРЕКИНГА ИГРОКА В ИГРОВОЙ МАШИНЕ"), поданной 16 сентября 2002 г., которая включена в данное изобретение полностью и для всех целей.

Во время определенных игровых событий игровая машина 2 может воспроизводить визуальные и звуковые эффекты, оказывающие на игрока несомненное влияние. Эти эффекты придают игре дополнительный эмоциональный накал, вызывающий у игрока желание продолжить игру. Компоненты представления, соответствующие настоящему изобретению, может быть использованы для задания световых узоров или аудиокомпонентов или для активизации других игровых устройств типа бонусных колес или механических барабанов определенным образом в качестве части представления исхода игры. Звуковые эффекты могут представлять собой различные звуки, воспроизводимые динамиками 10, 12, 14. В качестве визуальных эффектов могут быть использованы проблесковые или трассирующие огни или другие узоры, воспроизводимые источниками света на игровой машине 2 или с помощью источников света, расположенных за защитным стеклом 40. По окончании игры игрок может получить монеты или игровые жетоны из лотка 38 для монет или билет 20 из принтера 18, который может быть использован для дальнейших игр или для выкупа приза. Кроме того, игрок может получить из принтера 18 билет 20 для еды, товаров или игр.

В общем случае процесс проведения игры на игровой машине может содержать этапы 1) открытия кредитов на игровой машине для проведения игры, 2) приема ставки в азартной игре, 3) запуска азартной игры, 4) определения исхода игры, 5) генерации представления азартной игры на интерфейсе игровой машины игроку (интерфейс содержит дисплеи, динамики, источники света, бонусные устройства и т.д.), на которое могут оказывать влияние результаты выбора игрока, сделанные ранее (например, сумма ставок) или во время азартной игры, и 6) представления любого поощрительного вознаграждения, связанного с исходом игры, игроку.

Со ссылками на фиг.1В и 1C описывается архитектура программного обеспечения игровой машины при генерации различных игровых состояний на интерфейсе игровой машины. Архитектура программного обеспечения игровой машины создает инфраструктуру для генерации состояний представления на игровой машине, которые соответствуют различным игровым состояниям. Состояния представления генерируются в логике 100 игрового программного обеспечения, где интерфейс игровой машины может быть логически абстрагирован и затем подвергнут трансляции в выполняемую операцию различных игровых устройств, содержащих интерфейс игровой машины. Интерфейс игровой машины может содержать игровые устройства и комплекты игровой периферии, смонтированные в игровой машине или подключенные к игровой машине, типа дисплеев, источников света, звуковых устройств, банкнотоприемников, автоматов для выдачи монет, устройств ввода и устройств вывода, которые предоставляют интерфейс для пользователя игровой машины и позволяют игровой машине работать соответствующим образом. Некоторые примеры этих устройств и их функционирование были описаны при рассмотрении фиг.1А. В настоящем изобретении предлагается архитектура USB-совместимой связи, включающей в себя как аппаратные средства, так и программное обеспечение, которое позволяет реализовать логическую абстракцию интерфейса игровой машины (программное обеспечение) на интерфейсе игровой машины (аппаратные средства).

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

Показаны три модуля игрового программного обеспечения - игровая операционная система 102, модуль 106 логики представления и модуль 104 логики игрового потока, используемые для представления азартной игры 125 в игровой машине. Дополнительные детали операционной системы игровой машины и аппаратно-программного USB-интерфейса описываются при рассмотрении фиг.1C. Игровая операционная система 102, модуль 106 логики представления и модуль 104 логики игрового потока могут быть отделены один от другого и могут обмениваться информацией один с другим посредством ряда интерфейсов прикладных программ (API) 108.

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

Игровая операционная система 102 может загружать различную комбинацию модулей 104 логики игрового потока и модулей 106 логики представления, чтобы проводить различные азартные игры. Например, для проведения двух различных азартных игр игровая операционная система 102 может загрузить первый модуль логики игрового потока и первый модуль логики представления, чтобы обеспечить возможность проведения первой игры, а затем может загрузить второй модуль логики представления и использовать его с первым модулем логики игрового потока, чтобы обеспечить возможность проведения второй игры. В другом примере для проведения двух различных азартных игр игровая операционная система 102 может загрузить первый модуль логики игрового потока и первый модуль логики представления, чтобы обеспечить возможность проведения первой игры, а затем может загрузить второй модуль логики игрового потока и второй модуль логики представления, чтобы обеспечить возможность проведения второй игры. Элементы интерфейсов API 108 и игрового программного обеспечения 100, в том числе игровая операционная система 102, логика 104 игрового потока и логика 106 представления, описаны в совместно рассматриваемой заявке №10/040239 (IGT P078/P-671) США под названием "Game Development Architecture that Decouples the Game Logic from the Graphics Logic" ("Архитектура для разработки игр с разделением логики игры и графической логики"), поданной LeMay (Лимэй) с соавт.3 января 2002 г., которая включена в данное изобретение полностью и для всех целей.

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

Модуль 104 логики игрового потока содержит логику и машину состояний для запуска игры 125. Логика игрового потока может включать в себя: 1) логику для генерации игрового потока, содержащего последовательность игровых состояний, 2) логику для установки параметров конфигурации в игровой машине, 3) логику для хранения критической информации в энергонезависимом запоминающем устройстве в составе игровой машины и 4) логику для обмена информацией с другими модулями игрового программного обеспечения через один или более интерфейсов API. В частности, после инициирования игры на игровой машине логика игрового потока может определить исход игры и может генерировать ряд игровых состояний, используемых в представлении исхода игры игроку на игровой машине.

Обычно в игровой машине предусмотрены аппаратные средства и способы ликвидации эксплуатационных сбоев типа отказов цепи питания, отказов устройств и конфликтных ситуаций. Таким образом, логика программного обеспечения игровой машины и логика 104 игрового потока могут быть спроектированы для генерации последовательности игровых состояний, в которых критические игровые данные, генерируемые во время каждого игрового состояния, сохраняются в энергонезависимом запоминающем устройстве. Игровая машина не переходит к следующему игровому состоянию в последовательности игровых состояний, используемых для представления игры 125, пока не подтвердится, что критические игровые данные для текущего игрового состояния были сохранены в энергонезависимом запоминающем устройстве. Игровая операционная система 102 может проверять сохранение критических игровых данных, генерируемых во время каждого игрового состояния, в энергонезависимой памяти. В примере, когда модуль 104 логики игрового потока генерирует исход азартной игры в игровом состоянии, таком как 110, модуль 104 логики игрового потока не переходит к следующему логическому игровому состоянию в игровом потоке, такому как 114, пока игровая информация, относящаяся к исходу игры, не будет сохранена в энергонезависимом запоминающем устройстве. Так как в модулях игрового программного обеспечения в качестве части игрового потока генерируется последовательность игровых состояний, игровую машину часто называют машиной состояний.

На фиг.1В показана временная шкала 120 игры для азартной игры 125. Инициировать проведение игры 125 на игровой машине может игровое событие, такое как ввод игроком кредитов в игровую машину. Другое игровое событие типа заключения по представлению поощрительного вознаграждения может закончить игру 122. Между началом 121 игры и концом 122 игры, как указано выше, логика игрового потока может генерировать последовательность игровых состояний, таких как 110, 114 и 118, которые используются для проведения азартной игры 125. Среди нескольких примеров игровых состояний можно назвать: 1) определение исхода игры, 2) ориентацию логики 106 представления на представление исхода игры игроку, 3) определение исхода бонусной игры, 4) ориентация логики 106 представления на представление бонусной игры игроку, 5) ориентация логики представления на представление поощрительного вознаграждения за игру игроку и др.

Модуль 106 логики представления может обеспечивать игроку все отображение и обратную связь для данной азартной игры 125. Таким образом, для каждого игрового состояния логика 106 представления может генерировать соответствующее состояние представления (например, состояния 111, 115 и 119 представления, соответствующие игровым состояниям 110, 114 и 118), которое обеспечивает вывод данных игроку и позволяет ему осуществлять ввод определенных данных. В каждом состоянии представления управление комбинацией игровых устройств в игровой машине может осуществляться особым образом, как описывается в логике 106 состояний представления. Например, когда игровое состояние 110 является состоянием исхода с поощрительным вознаграждения, состояние 111 может включать в себя: 1) анимации на одном или более экранах дисплеев в игровой машине, 2) узоры из источников света в различных осветительных устройствах, локализованных в игровой машине, 3) сигналы звукового сопровождения, воспроизводимые звуковыми устройствами, локализованными в игровой машине, и т.д. Во время состояния представления могут быть использованы и другие игровые устройства в игровой машине типа бонусных колес и механических барабанов.

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

Логика 106 представления может генерировать множество подсостояний представления в качестве части каждого состояния представления. Например, состояние представления, определенное логикой состояния представления в первой азартной игре, может включать в себя подсостояние представления для первой анимации, подсостояние представления для второй анимации и третье подсостояние представления для вывода на игровом устройстве, которое генерирует осязательные ощущения. Во второй азартной игре состояние представления, генерируемое логикой состояния представления, может быть тем же самым, что и в первой азартной игре. Однако подсостояния представления для второй азартной игры могут быть другими. Например, подсостояния представления для второй азартной игры могут включать в себя подсостояние представления для анимации и второе подсостояние представления для вывода на игровом устройстве, которое создает запахи.

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

Игровые устройства, используемые в каждом состоянии представления и подсостоянии представления, содержат машинный интерфейс, который позволяет игроку принимать игровую информацию из игровой машины и вводить информацию в игровую машину. При изменении состояний представления машинный интерфейс типа 112, 116 и 120 может меняться и может обеспечивать возможность различных событий ввода/вывода типа 113, 117, 121. Например, когда игрок вносит кредиты в игровую машину, ряд кнопок сенсорного экрана может быть активизирован для машинного интерфейса 112, позволяющего игроку делать ставки и инициировать игру. Таким образом, ввод/вывод 113 может включать в себя: 1) игрок касается кнопки сенсорного экрана, чтобы сделать ставку для игры 325; 2) игрок касается кнопки сенсорного экрана, чтобы сделать ставку и инициировать игру в одно и то же время; 3) игрок просматривает кредиты, доступные для ставки и др. После того, как игрок сделал ставку и инициировал игру с помощью машинного интерфейса 112, в игровом состоянии 114 ему может быть представлено представление исхода игры с помощью машинного интерфейса 116. Ввод/вывод 117 на машинном интерфейсе 116 может включать в себя воспроизведение различных анимаций, звуков и световых узоров. Однако устройства ввода данных для игрока типа кнопок сенсорного экрана для машинного интерфейса 116 могут оставаться заблокированными.

Компоненты представления данного состояния представления могут включать в свой состав графические компонентами, звуковые компонентами, ароматические компоненты, компоненты тактильной обратной связи и компоненты игрового устройства, которые подлежать активизации на машинном интерфейсе 112. Например, состояние 111 представления может включать в себя следующие компоненты представления: 1) анимации кнопка ввода, 2) анимации барабанов, 3) воспроизведение звукового сопровождения А в течение 2 секунд и последующее воспроизведение звукового сопровождения В в течение 1 секунды, 4) высвечивания светового узора в течение двух секунд на осветительном устройстве А, 5) вращения бонусного колеса и др. Логика 116 представления может быть использована для задания реализации одного или более компонентов представления, используемых на машинном интерфейсе для данного состояния представления типа состояния 111 представления, описанного выше. Кроме того, логика представления может быть параметризованной, чтобы до некоторой степени обеспечить возможность легкого изменения вывода модуля представления.

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

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

В прошлом игровое программное обеспечение для игровых машин разрабатывалось без такого разделения. Игровое программное обеспечение разрабатывалось с игровыми настройками, ассоциированными с конкретным аппаратным устройством, "зашитым" в логику представления. Кроме того, логика 106 представления не отделялась от логики 104 игры. Поэтому, например, в случае замены бонусного колеса одного типа с первой совокупностью настроек в игровой машине на бонусное колесо второго типа с бонусными настройками второго типа возникала необходимость изменения логики представления, ассоциированной с обслуживанием бонусного колеса второго типа.

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

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

Для обеспечения возможности отделения игровой логики 104 и логики 106 представления от конкретных аппаратных средств, реализованных в игровой машине, необходима архитектура связи, которая позволит игровой машине "узнавать" о новых игровых устройствах, инсталлируемых в игровой машине, без априорного "знания" о настройках вновь инсталлируемого устройства. В одном примере осуществления настоящего изобретения реализована USB-совместимая архитектура связи. В частности, USB-совместимая архитектура связи, соответствующая настоящему изобретению, включает в себя менеджер классов USB-устройств, который обеспечивает USB-совместимую связь между игровым программным обеспечением 100 и комплектами игровой USB-периферии, согласующуюся с принципом разделения, описанным в предшествующих абзацах.

На фиг.1C представлены программные USB-компоненты, используемые в архитектуре USB-связи, типа менеджера 75 классов USB-устройств, интерфейсов USB-совместимых устройств и USB-стека 265, относящиеся к различным другим процессам, исполняемым игровой операционной системой 102, и к аппаратным устройствам типа USB-монетоприемника 293, USB-считывателя 298 карточек, банкнотоприемника 296 и малой клавишной панели 294, которые являются частью интерфейса игровой машины. Для реализации этого изобретения могут быть использованы различные архитектуры аппаратных средств и программного обеспечения, и настоящее изобретение не ограничено архитектурой, показанный на фиг.1C. Основные части программного обеспечения 100 игровой машины - коммуникационные протоколы 210, игровая операционная система 102, интерфейсы 255 устройств, драйверы 259 устройств игра 60. Игровая операционная система 102 включает в себя ряд процессов типа 75, 202, 203, 220, 222, 228 и 229 и систему распределения событий с 1) менеджером 230 событий и 2) распределением 225 событий. Процессы в игровой операционной системе 102 загружаются при включении игровой машины в предопределенной последовательности. Сначала описываются стандартные функции коммуникационных протоколов 210, игровой операционной системы 102, интерфейсов 255 устройств и драйверов 259 устройств. Затем приводится описание примеров взаимодействий между этими компонентами.

Игровая операционная система 102 может быть использована для загрузки и разгрузки игровых программных модулей типа коммуникационного менеджера 220, менеджера 75 классов USB-устройств, менеджера 222 банка, менеджера 230 событий, менеджера 203 по играм, обнаружения 228 бросков напряжения и менеджер 202 контекста, из запоминающего устройства большой емкости в составе игровой машины в RAM для исполнения в качестве процессов в игровой машине. Игровая операционная система 102 может также поддерживать структуру каталога, проводить мониторинг статуса процессов и намечать процессы для исполнения. Во время проведения игры на игровой машине игровая операционная система 102 может загружать и выгружать процессы из RAM динамическим образом.

Система распределения событий используется для обеспечения и направления взаимодействия между процессами (IPC) между различными процессами в игровой операционной системе 102. "Процесс" - это отдельный программный модуль исполнения, который защищен операционной системой и исполняется микропроцессором в ведущем игровом контроллере 224 (см. фиг.5). Когда процесс является защищенным, другие программные процессы или программные модули, исполняемые ведущим игровым контроллером, не могут иметь доступ к памяти защищенного процесса. Поэтому процессы обмениваются информацией через взаимодействия IPC.

В игровой операционной системе 102 процессы могут предоставлять различные услуги другим процессам и другим логическим объектам. Другой процесс, который стремится использовать услугу, предоставляемую процессом, может быть отнесен к клиентам этого процесса. Например, менеджер 229 NV-RAM (энергонезависимой RAM) управляет доступом к энергонезависимой памяти в игровой машине. Во время исполнения программного обеспечения 100 игровой машины менеджер 229 энергонезависимой памяти может получать запросы на доступ посредством менеджера 230 событий из других процессов, включая менеджер 75 классов USB-устройств, менеджер 222 банка, менеджер 203 по играм и одни или более интерфейсов 255 устройств, для хранения или поиска данных в физическом пространстве энергонезависимой памяти. Другие программные модули, которые запрашивают считывание, запись или запрос блоков памяти в энергонезависимой памяти, относятся к клиентам процесса менеджера NV-RAM.

Менеджер 230 событий является, как правило, разделяемым ресурсом, который используется всеми программными приложениями в игровой операционной системе 102. Менеджер 230 событий выполнен с возможностью оценки игровых событий, чтобы определить, содержит ли событие критические данные или модификации критических данных, которые защищены от бросков напряжения в игровой машине, т.е. является ли игровое событие "критическим игровым событием". События могут генерироваться в результате функционирования игровых устройств в игровой машине, процессами в игровой операционной системе 102 и другими ресурсами. Например, монета, введенная в USB-монетоприемник 293, может генерировать событие "монета введена". После приема игрового события менеджером 230 событий игровое событие пересылается в распределение 225 событий в игровой операционной системе 102. Распределение 225 событий обеспечивает широковещательную рассылку игрового события в программные модули адресата, которые могут функционировать на игровом событии. Например, на событии "монета введена" могут функционировать различные процессы в игровой операционной системе 102 типа менеджера 222 банка и менеджера 229 NV-RAM.

События, на которые игровая машина может отвечать и ответы на события, в том числе известные и неизвестные события, закодированы в программном обеспечении игровой машины 100. Среди других примеров игровых событий, прием которых может быть осуществлен из одного из физических устройств 292, можно назвать 1) открытие и закрытие основной дверцы/откидной дверцы/дверцы кассы, 2) сообщение о вставленной банкноте с указанием достоинства банкноты 3) конфликтная ситуация с накопителем, 4) застревание банкноты, 5) конфликтная ситуация с барабаном, 6) конфликтные ситуации с вводом и выводом монет, 7) прекращение подачи питания, 8) ввод карточки, 9) удаление карточки, 10) ввод рекламной карточки, 11) удаление рекламной карточки, 12) джекпот и 13) оставленная карточка. Однако настоящее изобретение не ограничено этими игровыми событиями, приведенными исключительно в иллюстративных целях.

Игровые события распределяются по одному или более адресатам (например, по процессам) посредством системы доставки с очередями с помощью программного процесса 225 распределения событий. Однако так как игровые события могут быть распределены по более чем одному адресату, игровые события отличаются от команды устройства или сигнала устройства, которые обычно являются прямым обменом информацией типа вызова функции внутри программы или взаимодействием между процессами.

Программное обеспечение 228 обнаружения бросков напряжения проводит мониторинг игровой машины по колебаниям мощности. Когда программное обеспечение 228 обнаружения бросков напряжения 228 обнаруживает, что сбой электропитания какого-либо типа может быть неизбежным, то в менеджер 230 событий может пересылаться событие с указанием на сбой электропитания. Это событие отправляется в программное обеспечение 225 распределения событий, которое осуществляет широковещательную рассылку сообщения во все программные модули и устройства в составе игровой машины, на которые сбой электропитания может оказать воздействие.

Менеджер контекста 202 осуществляет арбитраж запросов из различных компонентов отображения внутри игровой операционной системы и определяет, какому объекту предоставлен доступ к экрану, на основе приоритетных установок. В любое данное время множество объектов могут пытаться получить управление экранным отображением. Например, игра может "требовать" доступа к экрану, чтобы показать отображение счетчиков в ответ на поворот ключа перезагрузки джекпота оператором. Это создает потребность в одном объекте для определения, "кому" и при каких условиях предоставляется управление экраном, т.е. в менеджере 202 контекста.

Менеджер 220 банка действует на денежные транзакции, выполняемые на игровой машине, типа "монета введена" и "монета выведена". Менеджер 203 по играм действует как интерфейс для обработки игровых событий и игровой информации, пересылаемой в игру 60 и принимаемой из игры 60, который может включать в себя игровую логику 104 потока и логику 106 представления, описание которых приведено при рассмотрении фиг.1В. Коммуникационный менеджер 220 может обслуживать коммуникационные события, пересылаемые в удаленные игровые устройства типа устройств трекинга игрока, серверов трекинга игроков и большого сервера прогрессивных игр или принимаемые из этих удаленных игровых устройств. Удаленные игровые устройства в этом примере относятся к игровым устройствам, не управляемым ведущим игровым контроллером в составе игровой машины. Например, модуль трекинга игрока, который может быть физически смонтирован в игровой машине, считается удаленным по отношению к ведущему игровому контроллеру, если управление модулем трекинга игрока осуществляется не ведущим игровым контроллером, что часто имеет место (как правило, модули трекинга игрока включают в свой состав свое собственное логическое устройство, которое управляет устройством.)

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

Интерфейсы 255 устройств, включая малую клавишную панель 235, банкнотоприемник 240, USB-считыватель 245 карточек и USB-монетоприемник 250, являются логическими абстракциями, которые предоставляют интерфейс между драйверами 259 устройств и игровой операционной системой 102. Интерфейсы устройств обычно являются абстракциями более высокого уровня, общими для многих различных типов устройств. Интерфейсы 255 устройств могут принимать команды из менеджера 203 по играм и других программных модулей, запрашивающих операцию для одного из физических устройств. Программные модули относятся к процессам, когда они являются исполняемыми. Команды могут быть способами, реализуемыми программными модулями, в качестве части API, поддерживаемого программным модулем.

Интерфейсы 255 устройств используются в игровой операционной системе 102 так, чтобы изменения в программном обеспечении драйверов устройств не затрагивали игровой операционной системы 102 и описаний интерфейсов устройств. Например, игровые события и команды, которые каждое физическое устройство 292 пересылает и принимает, могут быть стандартизированы так, чтобы все физические устройства 292 пересылали и принимали одни и те же команды и одни и те же игровые события. Игровая машина может игнорировать события и команды, не поддерживаемые интерфейсами 255 устройств. Поэтому при замене физического устройства 292 может потребоваться новый драйвер 259 устройства для обмена информацией с физическим устройством. Однако интерфейсы 255 устройств и системная операционная система 102 игровой машины остаются неизменными. Как описывается выше, изоляция программных модулей, таким образом, может обеспечить ускорение разработки игр и процесса санкционирования программного обеспечения, что может позволить снизить затраты на разработку программного обеспечения.

Драйверы устройств обеспечивают трансляцию между абстракцией интерфейса устройства и аппаратной реализацией устройства. Драйверы устройств могут меняться в зависимости от фирмы-изготовителя конкретного физического устройства. Например, считыватель 298 карточек от первой фирмы-изготовителя может использовать Netplex 260 в качестве драйвера устройства, в то время как считыватель 298 карточек от второй фирмы-изготовителя может использовать последовательный протокол 270. Как правило, только одно физическое устройство данного типа инсталлировано в игровой машине в конкретное время (например, один считыватель карточек). Однако драйверы устройств для различных считывателей карточек или других физических устройств одного и того же типа, которые меняются при переходе от одной фирмы-изготовителя к другой, могут храниться в памяти в игровой машине. Когда физическое устройство заменяется, из ячейки памяти в игровой машине загружается соответствующий драйвер устройства для этого устройства, обеспечивающий возможность постоянного обмена информацией между игровой машиной и устройством.

Драйверы 259 устройств могут обмениваться информацией непосредственно с физическими устройствами, включая USB-монетоприемник 293, малую клавишную панель 294, банкнотоприемник 296, USB-считыватель 298 карточек или любые другие физические устройства, которые могут быть подключены к игровой машине. Драйверы 259 устройств могут использовать коммуникационный протокол какого-либо типа, который обеспечивает возможность обмена информацией с конкретным физическим устройством. Драйверы устройств, которые являются совместимыми с определенными интерфейсами устройств, используемыми игровой машиной, могут быть записаны для каждого типа физического устройства, которое может быть потенциально подключено к игровой машине. Среди примеров коммуникационных протоколов, используемых для реализации драйверов 259 устройств, можно назвать Netplex 260, USB 265, последовательный 270, Ethernet 275, Firewire 285, I/O debouncer 290, карту прямого доступа к памяти, последовательный, PCI 280 или параллельный. Netplex - фирменный стандарт корпорации IGT, в то время как другие - открытые стандарты.

USB является стандартной последовательной коммуникационной методологией, используемой в индустрии персональных компьютеров. Стандарты коммуникационных протоколов USB поддерживаются USB-IF, Portland, Oregon, http://www.usb.org. Настоящее изобретение может быть совместимым с различными версиями стандарта USB, такими как USB version l.x и USB version 2.x, а также с будущими версиями USB. Далее, программные модули, используемые в архитектуре USB-связи для обеспечения USB-совместимой связи между USB-совместимым устройством и игровой операционной системой 102, которые удовлетворяют уникальным требованиям игровой машины типа требований по безопасности и требований по регламенту, описываются в следующих абзацах.

Менеджер 75 классов USB-устройств обслуживает все классы USB-устройств, используемых в игровой машине. Класс USB-устройств - специфический термин, используемый в архитектуре USB-связи. Более подробное его описание приводится при рассмотрении фиг.7-8.

Обычно менеджер классов USB-устройств осуществляет инициализацию, обслуживание и управление интерфейсом 254 USB-устройств. Интерфейс 254 USB-устройств может содержать один или более специфических интерфейсов устройства, доступных на игровой машине. Например, на фиг.1C интерфейс 254 USB-устройств содержит интерфейс 250 USB-монетоприемника и интерфейс 245 USB-считывателя карточек. USB-монетоприемник 250 и USB-считыватель карточек 245 - логические абстракции этих устройств, используемые процессами в игровой операционной системе 102 при обмене информацией с этими устройствами.

Поскольку интерфейс устройства является логической абстракцией функции физического устройства, интерфейс устройства не обязательно обеспечивает взаимно однозначного соответствия с используемым игровым USB-устройством или используемой игровой USB-периферией (USB в качестве прилагательного указывает на USB-совместимость). Например, игровая USB-периферия может содержать периферийное устройство в виде источников света и периферийное устройство в виде колеса. В одном примере осуществления интерфейс устройств для игровой USB-периферии с источниками света и колесами может быть абстрагирован как два отдельных интерфейса устройства - один для настройки колеса и один для настройки источников света, даже при том, что колеса и источники света локализованы в одной и той же самое игровой USB-периферии. В другом примере осуществления может быть использован один интерфейс устройства для игровой USB-периферии с источниками света и колесами. В драйверах Netplex обычно используется этот принцип. Таким образом, один интерфейс устройства поддерживает настройку колес и настройку источников света. В другом примере осуществления периферийное устройство в виде источников света в составе игровой USB-периферии может иметь ряд настроек, которые абстрагированы как отдельные интерфейсы устройства. Поэтому три интерфейса устройства, в том числе источника 1 света, источника 2 света и колеса, могут быть абстрагированы для игровой USB-периферии, причем первый интерфейс устройства поддерживает настройку источника 1 света, второй интерфейс устройства поддерживают настройку источника 2 света, а третий интерфейс устройства поддерживает настройку колеса. Для каждого интерфейса устройства используется соответствующий драйвер устройства, обеспечивающий возможность обмена информацией через интерфейс USB-устройства с его одной или более USB-настройками. Более подробное описание отображения интерфейсов USB-устройств в настройках приводится при рассмотрении фиг.8 и в совместно рассматриваемый заявке №10/246367 США, включенной в данное изобретение ранее.

При включении питания менеджер 75 классов USB-устройств загружается в RAM для исполнения игровой операционной системой 102. После загрузки менеджер классов USB-устройств может осуществить поиск структуры каталога, обслуживаемой игровой операционной системой 102, чтобы определить, какие игровые USB-устройства поддерживаются игровой машиной. Структура каталога может варьироваться в зависимости от того, какое программное обеспечение 100 игровой машины типа игры хранится в игровой машине. После определения списка интерфейсов игровых USB-устройств, поддерживаемых игровой машиной, менеджер классов USB-устройств может загрузить драйверы, которые обеспечивают возможность обмена информацией между процессами в игровой операционной системе 102 и каждой настройкой, поддерживаемой интерфейсом. Более подробное описание деталей отображения интерфейсов и настроек приводится при рассмотрении фиг.8.

В прошлом интерфейс устройства в программном обеспечении игровой машины был статическим, так как был реализован аппаратно на микросхеме типа ППЗУ. Поэтому изменение в интерфейсе устройства типа добавления новой игровой периферии в игровую машину требовало тестирования нового кода, программирования нового ППЗУ и инсталляции новой периферии и нового устройства в игровую машину. Преимущество настоящего изобретения состоит в том, что архитектура программного обеспечения предусматривает изменяемый интерфейс устройства, обслуживаемый процессом 75 менеджера USB-устройств. Например, при использовании настоящего изобретения игровая машина может поддерживать различные игры с различными интерфейсами устройств. Процесс 75 менеджера классов USB-устройств может установить интерфейс 254 USB-устройства для каждой игры путем поиска игрового программного обеспечения, ассоциированного с каждой игрой.

Поиск, проводимый менеджером 75 классов USB-устройств, может быть ограничен определенными путями к файлам в структуре каталога, в которых может храниться информация об игровых устройствах, или менеджер может осуществлять поиск во всей структуре каталога. В одном примере осуществления пути поиска файлов могут быть "зашиты" в программное обеспечение для менеджера 75 классов USB-устройств. В другом примере осуществления игровая операционная система 102 может определять привилегии доступа к каталогу для каждого процесса. Таким образом, поиск, проводимый менеджером 75 классов USB-устройств, может быть ограничен в соответствии с частями структуры каталога, к которым этот менеджер может иметь доступ.

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

В одном примере осуществления менеджер 75 классов USB-устройств может быть запущен из защищенной ячейки памяти типа ППЗУ, доступного только по чтению. Игровая операционная система 102 может проверить аутентичность кода для менеджера 75 классов USB-устройств путем выполнения верификационной проверки, такой как выполнение CRC-хеширования кода и сравнение с известным значением для кода. Запуск менеджера 75 классов USB-устройств из защищенной ячейки памяти и/или аутентификация кода может быть реализован по соображениям безопасности.

В качестве другой меры безопасности игровая машина может хранить список санкционированных интерфейсов USB-устройств. После определения менеджером 75 классов USB-устройств интерфейсов игровых USB-устройств, поддерживаемых в игровой машине, но до загрузки драйверов для каждого интерфейса игрового USB-устройства, менеджер классов USB-устройств может сравнить каждый интерфейс игрового USB-устройства по своему списку со списком санкционированных интерфейсов игровых USB-устройств. Когда менеджер 75 классов игровых USB-устройств определяет, что интерфейс игрового USB-устройства является санкционированным, менеджер 75 классов игровых USB-устройств загружает USB-драйвер, что обеспечивает возможность использования драйвера в процессах игровой операционной системы 102 для обмена информацией с одной или более настройками, поддерживаемыми загруженным интерфейсом USB-устройства и/или управления одной или более настройками, поддерживаемыми загруженным интерфейсом USB-устройства. Когда игровое USB-устройство обнаруживает несанкционированный интерфейс устройства в своем списке, игровое USB-устройство может генерировать игровое событие "обнаружен несанкционированный интерфейс устройства" и переслать его в менеджер 230 событий. В ответ на событие могут отреагировать один или более процессов в игровой операционной системе 102. Например, в одном примере осуществления игровая машина может быть переведена в нерабочее конфликтное состояние и дежурный администратор может быть уведомлен об этом.

Процесс 75 менеджера классов USB-устройств определяет интерфейсы специфических устройств в интерфейсе 254 USB-устройств (например, USB-считывателя 245 карточек и USB-монетоприемника). Кроме того, менеджер 75 классов USB-устройств проверяет, какие игровые USB-устройства или комплекты игровой USB-периферии могут быть подключены к игровой машине посредством интерфейса 254 USB-устройств. Стандартная USB-архитектура позволяет осуществлять подключение любого устройства, реализующего USB, к USB-совместимой компьютерной системе. Однако игровой машины имеют более высокие требования по безопасности, чем обычные компьютерные системы. Поэтому, менеджер 75 классов USB-устройств может ограничить возможность подключения USB-устройств.

В примере, если несанкционированное USB-устройство пытается подключиться к игровой машине посредством интерфейса 254 USB-устройств, менеджер классов USB-устройств не может загрузить драйвер для несанкционированного устройства и может генерировать игровое событие, указывающее на предпринятую попытку подключения незаконного устройства к игровой машине, которое пересылается в менеджер 230 событий. Другие процессы в игровой машине могут отреагировать на событие. Например, игровая машина может перейти в "конфликтное" состояние в ответ на попытку подключить незаконное устройство и генерировать/переслать сообщение об опасной обстановке в системе защиты.

В одном примере осуществления, USB-устройства могут подключаться к игровой машине посредством USB-стека 266. USB-стек 266 может обеспечивать возможность устанавливать подключение любого USB-устройства к стеку. Однако по соображениям безопасности менеджер 75 классов USB-устройств 75 не может обеспечивать возможность обмена информацией с игровой операционной системой 102 всем USB-устройствам, подключенным к USB-стеку 266. Когда устройство подключается к USB-стеку 266, например во время процесса начальной нумерации или в любое время в процессе работы игровой машины, USB-стек 266 может отправить событие в менеджер 230 событий (см. пунктирную стрелку от USB-стека 266 к менеджеру 230 событий). Событие может быть направлено в менеджер 75 классов USB-устройств. Событие может включать в себя информацию (например, серийные номера, зарегистрированную идентификационную информацию и т.д.) по идентичности устройства, которое пыталось подключиться к USB-стеку 266. В другом примере осуществления USB-стек 266 может обходить менеджер 230 событий и пересылать информацию непосредственно в менеджер 75 USB-устройств.

Используя идентификационную информацию, предоставленную игровой USB-периферией, менеджер 75 классов USB-устройств может пытаться аутентифицировать идентичность игровой USB-периферии. В одном примере осуществления, чтобы аутентифицировать устройство, менеджер 75 классов USB-устройств может инициировать запрос на CRC аппаратно-программного обеспечения в игровой USB-периферии. Запрос на CRC может включать в себя начальный адрес и конечный адрес, который соответствует любому сегменту аппаратно-программного обеспечения. Начальный адрес и конечный адрес могут быть генерированы случайно. Запрашиваемая информация о CRC из игровой периферии может быть подвергнута сравнению с информацией о CRC, генерируемой менеджером классов USB-устройств, в аутентифицированной копии аппаратно-программного обеспечения, хранимого в игровой машине для назначенного адресного интервала. Когда значения CRC, генерированные игровой USB-периферией и менеджером классов USB-устройств совпадают, периферийное устройство, использующее аппаратно-программное обеспечение, может считаться аутентичным. Проводимая менеджером классов USB-устройств проверка аутентификации может быть использована для предотвращения спуфинга менеджера классов USB-устройств со стороны периферийного устройства.

Когда менеджер 75 классов USB-устройств 75 определяет, что устройство, подключенное к USB-стеку 266, является санкционированным устройством, менеджер классов USB-устройств может загрузить драйвер типа разделяемого объекта, совместимого с устройством (см. фиг.3), и обеспечить возможность продолжения обмена информацией. Когда устройство, подключенное к стеку 266, является несанкционированным устройством, менеджер 75 классов USB-устройств может генерировать событие, указывающее на предпринятую попытку подключения несанкционированного устройства к игровой машине, и отправить это событие в менеджер 230 событий. В ответ на событие игровая машина может быть переведена в безопасное состояние и дежурный администратор может быть уведомлен об этом.

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

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

Процессы, описанные выше, защищают игровую машину от двух возможных векторов угрозы во время процессов инициализации и нумерации: 1) от установленных на игровой машине программ, описывающих интерфейсы несанкционированные устройств, и 2) от несанкционированных устройств, пытающихся обмениваться информацией с игровой машиной через USB-стек. При другой мере безопасности менеджер 75 классов USB-устройств может выполнять опрос периферии. Периферия может быть спроектирована для приема опросных сообщений из хоста в пределах интервала таймаута. В случае отсутствия опросных сообщений из хоста в пределах интервала таймаута периферия может перейти в безопасное состояние, при котором не допускается предъявления никакой денежной претензии в отношении машины или игровой периферии. При еще одной другой мере безопасности менеджер классов USB-устройств может также поддерживать верификацию аппаратно-программного обеспечения периферии с помощью CRC, чтобы гарантировать постоянное выполнение периферией надлежащего аппаратно-программного обеспечения. При дополнительной мере безопасности в сообщениях между хостом и периферией может быть использована криптография. Это может быть использовано в конфиденциальных транзакциях между периферией и хостом. При применении криптографии менеджер 75 классов USB-устройств может назначать ключи шифрования для периферийных устройств. Кроме того, менеджер 75 классов USB-устройств может аутентифицировать идентичность отправителя сообщения (например, игровое периферийное устройство) с использованием технических приемов криптографии. Более подробное описание деталей криптографических способов, которые могут быть использованы в настоящем изобретении, приводится при рассмотрении фиг.5 и в совместно рассматриваемой заявке №09/993163 США под названием "Cashless Transaction Clearinghouse" ("Центр обмена информацией о безналичных транзакциях"), поданной 16 ноября 2001 г. и включенной в данное изобретение полностью и для всех целей.

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

Такие устройства будут содержать аппаратно-программное обеспечение, достаточное только для обеспечения возможности нумерации и надлежащей идентификации. Во время процесса нумерации менеджер 75 классов USB-устройств может определить, каким комплектам игровой периферии требуется аппаратно-программное обеспечение и загружает аппаратно-программное обеспечение в комплекты игровой периферии. Дополнительные детали этого способа описываются при рассмотрении фиг.5, 6 и 9-12 и в совместно рассматриваемой заявке №10/460822 (№IGT1 Р099 по реестру поверенных) США под названием "USB SOFTWARE ARCHITECTURE IN A GAMING MACHINE" ("АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ USB В ИГРОВОЙ МАШИНЕ"), поданной 11 июня 2003 г. Лэм (Lam) с соавт. и включенной в данное изобретение полностью и для всех целей.

После нумерации устройств может быть начат обмен информацией между процессами и физическими устройствами с использованием архитектуры USB-СВЯЗИ, соответствующей настоящему изобретению. Например, менеджер 222 банка может осуществить пересылку команды в USB-считыватель 245 карточек с запросом на считывание информации с карточки, вставленной в считыватель 298 карточек. Пунктирная стрелка от менеджера 222 банка к USB-считывателю 245 карточек в USB-интерфейсах 254 устройств указывает команду, пересылаемую из менеджера 222 банка в USB-интерфейсы 254 устройств. Интерфейс устройства для USB-считывателя 245 карточек может пересылать сообщение в драйвер устройства для считывателя 298 карточек. Этот коммуникационный канал описывается более подробно при рассмотрении фиг.3 и 4. Драйвер устройства для физического USB-считывателя 298 карточек передает в USB-считыватель 298 карточек команду и/или сообщение, обеспечивающие возможность считывания информации с карточки с магнитной полосой или смарт-карточки, вставленной в считыватель карточек, в USB-считывателе 298 карточек.

Информация, считываемая с карточки, вставленной в считыватель карточек, может быть отправлена в менеджер 230 событий посредством соответствующего USB-драйвера 266 устройства и интерфейса 245 USB-считывателя карточек. Игровая машина может применять транзакцию на основе системы программного обеспечения. Поэтому модификации критических данных, определяемые в критическом игровом событии, могут быть добавлены к списку критических игровых транзакций, определяющих состояние в игровой машине, менеджером 230 событий, причем список критических игровых транзакций может быть послан в NV-RAM через менеджер 229 NV-RAM. Например, операции считывания информации с карточки, вставленной в игровую машину, и данные, считанные с карточки, могут генерировать ряд транзакций над критическими данными.

Когда карточка с магнитной полосой в считывателе 298 карточек является дебетной карточкой и кредиты добавляются в игровую машину посредством карточки, среди нескольких критических транзакций могут быть 1) запрос к энергонезависимой памяти на текущий кредит, доступный на игровой машине, 2) считывание информации о кредитоспособности с дебетной карточки, 3) пополнение суммы кредитов в игровой машине, 4) запись на дебетную карточку посредством USB-считывателя 245 карточек и USB-драйверов 265 устройств, чтобы вычесть сумму, добавленную в игровую машину, с дебетной карточки и 5) копирование новой информации о кредитоспособности в энергонезависимой памяти.

Как правило, прием игрового события типа события из одного из физических устройств 292 может осуществляться интерфейсами 255 устройств путем опроса или прямого обмена информацией. Сплошные черные и пунктирные стрелки указывают маршруты сообщений о событиях между различными программными модулями. При проведении опроса интерфейсы 255 устройств регулярно посылают в физические устройства 292 сообщения с запросом о наступлении или ненаступлении события посредством драйверов 259 устройств. Как правило, драйверы 259 устройств не выполняют никакой обработки событий высокого уровня. Например, при проведении опроса интерфейс USB-считывателя 245 карточек может регулярно посылать сообщение в физический USB-считыватель 298 карточек для выяснения, была ли карточка вставлена в считыватель карточек или нет. При наступлении события в интерфейсы 255 устройств с помощью прямой связи посредством драйверов 259 устройств пересылается прерывание или сигнал, указывающий на наступление игрового события. Например, когда карточка вставлена в USB-считыватель карточек, USB-считыватель 298 карточек может осуществить пересылку сообщения "карточка вставлена", указывающего, что карточка вставлена, в интерфейс устройства для USB-считывателя 245 карточек, причем сообщение может быть отправлено в менеджер 230 событий. Сообщение "карточка вставлена" является игровым событием.

Как правило, игровое событие - инкапсулированный информационный пакет какого-либо типа, отправляемый интерфейсом устройства. Игровое событие имеет "источник" и один или более "адресатов". В примере источником игрового события "карточка вставлена " может быть USB-считыватель 298 карточек. Адресатами для игрового события "карточка вставлена" могут быть менеджер банка 222 и коммуникационный менеджер 220. Коммуникационный менеджер может обмениваться информацией, считываемой с карточки, с одним или более устройствами, локализованными вне игровой машины. Когда карточка с магнитной полосой используется для внесения кредитов в игровую машину, менеджер банка 222 может посредством интерфейса 255 считывателя карточек предложить USB-считывателю 298 карточек выполнить дополнительные операции. Каждое игровое событие может содержать стандартный заголовок с дополнительной информацией, прикрепленной к заголовку. Дополнительная информация обычно используется тем или иным образом в адресате для события.

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

Рассматриваемые в данном изобретении различные программные элементы (например, драйверы устройств, интерфейсы устройств, коммуникационный протоколы и т.д.) могут быть реализованы как программные объекты или другие исполнимые блоки кода или сценария. В одном примере осуществления элементы реализованы как объекты C++. Менеджер 230 событий, распределение 225 событий, менеджер 203 по играм и другие программные модули игровой операционной системы могут быть также реализованы как объекты C++. Каждый компилируется как отдельные процессы и обменивается информацией через события и/или взаимодействие между процессами (IPC). Форматы событий и форматы IPC могут быть определены как часть API.

На фиг.2 представлена блок-схема нескольких примеров классов и настроек устройств с возможным обслуживанием менеджером классов USB-устройств в соответствии с настоящим изобретением. USB-устройство может быть подразделено на ряд логических компонентов типа устройства, конфигурации, интерфейса и оконечной точки. Спецификации классов устройств определяют, как USB-устройство использует эти компоненты для доставки имеющихся функциональных возможностей в хост-систему. Спецификации классов устройств могут варьироваться от класса к классу. В некоторых случаях спецификации классов устройств являются стандартами, которые поддерживаются организацией группы USB-пользователей и были подвергнуты анализу и процессу санкционирования со стороны группы USB-пользователей. Например, USB-класс 401 HID (устройств интерфейса с пользователем), класс 405 принтеров и класс 407 звуковых устройств являются классами стандартных USB-устройств, которые могут поддерживаться менеджером классов USB-устройств. В других случаях спецификации классов устройств могут быть могут быть ориентированы на класс устройств конкретной фирмы-поставщика и разработаны фирмой-поставщиком для удовлетворения специфических требований фирмы-поставщика. Например, класс 405 устройств фирмы-поставщика IGT представляет собой класс устройств конкретной фирмы-поставщика, который может поддерживаться менеджером 75 классов USB-устройств, соответствующим настоящему изобретению. Детали класса устройств фирмы-поставщика IGT описываются в совместно рассматриваемой заявке №10/460866 (№IGT1 Р100 по реестру поверенных) США под названием "Protocols and Standards for USB Peripheral Communications" ("Протоколы и стандарты для коммуникаций с USB-периферией"), поданной 11 июня 2003 г. Куариши (Quraishi) с соавт. и включенной в данное изобретение полностью и для всех целей. Настоящее изобретение не ограничено теми немногими стандартами и теми немногими классами устройств конкретных фирм-поставщиков, представленными на фиг.2, менеджером 75 классов USB-устройств могут поддерживаться и другие классы типа 409.

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

Класс фирмы-поставщика IGT записан так, чтобы поддерживать специфические требования игровой индустрии типа требований по безопасности, которые не могут быть удовлетворены другими классами устройств. Он отличается от других классов устройств типа HID тем, что обеспечивает способы реализации засекреченной связи типа шифрования, которые не обеспечиваются в классе HID. Следует помнить, что стандартные USB-классы типа HID записаны с целью максимального облегчения подключения в среде ПК, чтобы обеспечить возможность легкого подключения к системе ПК как можно большему числу устройств. В игровой индустрии интересы безопасности входят в противоречие с задачей максимизации возможности подключения. Например, если к игровой системе подключается устройство мошенника и это приводит к регистрации несуществующих кредитов в игровой машине или происходит изменение передаваемой информации и это приводит к регистрации несуществующих кредитов, то может произойти прямое хищение денег. В индустрии ПК этот тип нарушения безопасности, как правило, не играет большой роли. В этом отношении игровая машина в большей степени приближается к банковской индустрии и, в частности, требования по ее безопасности сродни требованиям по безопасности банковских автоматов. Таким образом, в индустрии ПК классы стандартных USB-устройств писались без учета проблем безопасности, важных для игровой индустрии.

Логика для каждой игровой USB-периферии может быть абстрагирована в совокупность USB-настроек. USB-настройка может быть независимым кодом, который управляет одним устройством ввода/вывода или несколькими по существу идентичными устройствами ввода/вывода типа колес или бонусных барабанов. Настоящее изобретение может поддерживать одну или более настроек в каждом классе. Например, менеджер 75 классов USB-устройств показан поддерживающим настройку 411 операций по перемещению монет в устройствах IGT, настройку 413 принтера IGT и настройку 415 механических барабанов IGT в классе 405 устройств фирмы-поставщика IGT. Настоящее изобретение не ограничено настройками, показанными на фиг.2, и менеджер 75 классов USB-устройств может поддерживать другие настройки 417.

Число настроек, поддерживаемых классом фирмы-поставщика IGT, как правило не является статическим. По мере изготовления новых комплектов игровой USB-периферии или модифицирования функций существующей игровой USB-периферии в класс фирмы поставщика IGT, поддерживаемый менеджером 75 классов USB-устройств, могут включаться дополнительные настройки. Класс спроектирован так, что при включении новых настроек в класс, основная архитектура класса остается неизмененной. Все, что требуется - это добавление нового драйвера, который поддерживает настройку или идентификацию существующего драйвера, который поддерживает настройку.

На фиг.3 представлена блок-схема, блок-схема, демонстрирующая связь между прикладными процессами и USB-настройками через драйверы, обслуживаемые менеджером классов USB-устройств. Как описывается при рассмотрении фиг.1C, процесс менеджера 75 классов USB-устройств определяет, какие USB-драйверы загружать и выполнять. USB-драйверы, запускающие конкретную USB-настройку, могут также именоваться в настоящем изобретении драйвером USB-настройки. USB-драйверы типа 420, 422 и 424 могут обмениваться информацией непосредственно с комплектами USB-периферии типа 425, подключенными к игровой машине. Другими словами, они обмениваются информацией с комплектами периферии с использованием USB-протокола. Драйверы также взаимодействуют с игровой системой. Игровая система является клиентом USB-драйвера. Со ссылками на фиг.3 описывается один пример осуществления взаимоотношений между хостом и периферией.

В этом примере менеджер 75 классов USB-устройств может загрузить три DLL (динамически подключаемые библиотеки) или совместно используемых объекта 420, 422 и 424. Совместно используемый объект представляет собой объект в игровой операционной системе, которая обеспечивает одну или более конкретные функции. Программа может иметь доступ к функциям совместно используемого объекта путем создания или статической или динамической связи с совместно используемым объектом. В этом примере менеджер классов USB-устройств создал динамические связи с совместно используемым объектам.

Как правило, совместно используемый USB-объект может иметь специфическую функцию, которая соответствует определенной настройке периферии типа 428, 430 и 432. Примером настройки является компонент бонусной периферии в виде колеса. Другой пример - компонент бонусной периферии в виде источников. Концепция настройки периферии описывается в совместно рассматриваемой заявке №10/246367 на патент США под названием "Protocols and Standards for USB Peripheral Communication" ("Протоколы и стандарты для коммуникаций с USB-периферией", включенной в данное изобретение ранее. Описание деталей настроек периферии приводится также при рассмотрении фиг.7 и 8.

В этом примере, который предлагается исключительно в иллюстративных целях, нить 420 драйвера обменивается информацией с использованием USB с настройкой 428 игровой USB-периферией 425, нить 422 драйвера обменивается информацией с использованием USB с настройкой 430 игровой USB-периферией 425, а нить 424 драйвера обменивается информацией с использованием USB с настройкой 432 игровой USB-периферии 425. Нити драйверов являются экземплярами реализации USB-драйверов игровой операционной системы. Клиенты к каждой нити драйвера могут варьироваться со временем, поскольку игровая машина использует и генерирует различные состояния на интерфейсе игровой машины. В текущем примере нить 420 драйвера имеет два клиента, нить 422 драйвера имеет одного клиента, а нить 424 драйвера - ни одного клиента. Как описывается со ссылками на фиг.1C, менеджер 75 классов USB-устройств может проводить мониторинг клиентов каждой нити драйвера. Когда нить драйвера не имеет никаких клиентов, нить драйвера может быть выгружена из памяти. Посредством своих алгоритмов мониторинга менеджер 75 классов USB-устройств может запускать загрузку и разгрузку драйверов из памяти.

В одном примере осуществления клиентские процессы могут обмениваться информацией с совместно используемыми объектами через взаимодействия между процессами (IPC). Прикладной процесс 426 и прикладной процесс 428 обмениваются информацией с нитью 420 драйвера соответственно через взаимодействия IPC 432 и 434. Прикладной процесс 430 обменивается информацией через IPC 436 с нитью драйвера 422. Настоящее изобретение не ограничено взаимодействиями IPC и между двумя процессами или логическими объектами, исполняемыми игровой машиной, могут использоваться другие механизмы связи, поддерживаемые операционной системой.

Игровая USB-периферия в этом примере может рассматриваться как сложная USB-периферия. Сложной называют периферию, которая имеет множество USB-интерфейсов. Другими словами, периферия разделена на несколько компонентов. Каждый компонент или настройка существуют в своем собственном USB-интерфейсе. За дополнительной информацией об USB-интерфейсах следует обращаться к спецификациям универсальной последовательной шины, которые можно найти на сайте www.usb.org. Кроме того, детали USB-настроек и интерфейсов также описываются при рассмотрении фиг.7 и 8. Этот пример демонстрирует игровую USB-периферию с множеством интерфейсов и настроек, подключенную к USB-хосту в игровой машине. Изобретение может также поддерживать множество комплектов игровой USB-периферии с множеством интерфейсов, подключенных к одному и тому же USB-хосту в игровой машине.

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

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

Менеджер классов USB-устройств может генерировать нить для каждого совместно используемого объекта, который он загружает. Каждая нить имеет канал, обеспечивающий возможность приема команд или запросов из клиентов в системе. Запросы могут быть в форме взаимодействия между процессами (IPC). Каждой нити может быть также обеспечена возможность отправки событий в систему. В зависимости от функции совместно используемого объекта нить может также обеспечивать клиенту возможность регистрации идентификатора подключения к драйверу, чтобы при выполнении заданного условия клиенту посылался бы обратный импульс. Наконец, нить может устанавливать подключение к USB-стеку 266, обеспечивающему возможность непосредственного обмена информацией между нитью и настройкой периферии. Атрибуты нити вместе взятые позволяют нити функционировать как USB-драйвер. Обычно менеджер 75 классов USB-устройств может обслуживать множество нитей, причем назначенные нити функционируют как USB-драйвер, где число нитей может варьироваться с течением времени.

На фиг.4 представлена блок-схема, демонстрирующая связь между прикладными процессами и USB-настройками через процесс 440 драйвера устройств, обслуживаемый менеджером 75 классов USB-устройств. На фигуре показана другая схема взаимооотношений между хостом и игровой USB-периферией. Описание некоторых функций игровой USB-периферии 425, интерфейса USB с настройкой 428, прикладного клиентского процесса 426 и менеджера 75 классов USB-устройств было приведено ранее со ссылками на фиг.3. Одно отличие случая, иллюстрируемого фиг.4, от случая, иллюстрируемого фиг.3, заключается во введении процесса 440 драйвера устройств, обеспечивающего сопряжение нити 420 совместно используемого объекта с игровой USB-периферией 425.

В этом примере осуществления драйвер 420 совместно используемого объекта, загружаемый менеджером 75 классов USB-устройств, может обмениваться информацией с процессом 440 драйвера, но не непосредственно с игровой USB-периферией 425. Менеджер 75 классов USB-устройств 75 запускает процесс 440 драйвера устройства. Как было указано ранее, менеджер 75 классов USB-устройств определяет, какие процессы USB-связи выполняются в системе. Выполняться могут только санкционированные процессы.

Процесс 440 драйвера может обмениваться информацией с игровой USB-периферией с использованием как спецификации классов стандартных USB-устройств, так и спецификации классов устройств конкретной фирмы-поставщика. Процесс 440 драйвера может быть записан или не записан сторонней компанией. Процесс 440 драйвера может обмениваться информацией с множеством подобных комплектов игровой USB-периферии. Детали спецификации классов устройств, реализованной процессом 400 драйвера устройств, могут быть не объявлены в драйвере 420 совместно используемого объекта, выполняемом в процессе 75 менеджера классов USB-устройств. Вместо этого процесс 440 драйвера может объявить другой интерфейс, который драйвер 420 совместно используемого объекта понимает и использует. Примером такого интерфейса может быть интерфейс файловой системы POSIX.

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

На фиг.5 представлена блок-схема игровой машины 2 в соответствии с настоящим изобретением. Ведущий игровой контроллер 224 управляет работой различных игровых устройств и представлением игры на игровой машине 2. Ведущий игровой контроллер 224 может обмениваться информацией с другими удаленными игровыми устройствами типа удаленных серверов посредством главной коммуникационной платы 213 и сетевого подключения 214. Ведущий игровой контроллер 224 может также обмениваться информацией с другими игровыми устройствами посредством канала беспроводной связи (не показанный). Канал беспроводной связи может использовать стандарт беспроводной связи типа IEEE 802.11a, IEEE 802.11b, IEEE 802. Их (например, другие стандарты IEEE 802.11 типа 802.11с или 802.11e), hyperlan/2, Bluetooth, WiFi, HomeRF и др.

Используя игровое программное обеспечение и графические библиотеки, хранимые в игровой машине 2, ведущий игровой контроллер 224 генерируют представление игры, которое может быть представлено на дисплее 34, дисплее 42 или их комбинации. Дополнительные дисплеи типа механических слот-барабанов, которые являются USB-совместимыми, могут быть также использованы в настоящем изобретении. Представление игры - это обычно последовательность кадров, обновляемых с заданной частотой регенерации типа 75 Гц (75 кадров/сек). Например, для видеослот-игры представление может включать в себя последовательность кадров слот-барабанов с рядом символов в различных положениях. При представлении последовательности кадров слот-барабаны кажутся игроку, ведущему игру на игровой машине, вращающимися. Заключительные кадры представления игры в последовательности кадров представления игры являются конечным положением барабанов. По конечному положению барабанов на видеодисплее 34 игрок может визуально определить исход игры.

Игровое программное обеспечение для генерации азартной игры может храниться в запоминающем устройстве большой емкости типа разбитого на разделы жесткого диска 226, CD, DVD и т.д. Санкционированное игровое программное обеспечение может загружаться в RAM 56 ведущим игровым контроллером 224 для исполнения одним или более процессорами. Разбитый на разделы жесткий диск 226 может включать в себя раздел 223 для санкционированного игрового программного обеспечения и раздел для санкционированного аппаратно-программного обеспечения 453. Санкционированное игровое программное обеспечение и санкционированное аппаратно-программное обеспечение могут быть санкционированы одной или более организациями типа одной или более игровых юрисдикции, фирмы-изготовителя игровой машины, стороннего разработчика, ассоциации по вопросам стандартизации, консорциума по разработке игрового программного обеспечения и их комбинации. Игровое программное обеспечение и аппаратно-программное обеспечение могут подвергаться регулярному обновлению такими способами, как загрузки в игровую машину с удаленного устройства типа удаленного сервера или удаленной игровой машины или замена запоминающего устройства в игровой машине типа CD или DVD на новое запоминающее устройство, содержащим обновленное программное обеспечение или аппаратно-программное обеспечение.

В одном примере осуществления все аппаратно-программное обеспечение или программное обеспечение, используемое для работы одного или более комплектов игровой периферии типа банкнотоприемника 269, монетоприемника и контроллера периферии, может храниться на жестком диске 226. Комплекты игровой периферии могут включать в себя программное обеспечение/аппаратно-программное обеспечение для установления основной связи с ведущим игровым контроллером. Например, банкнотоприемник 296, монетоприемник 293, принтер 18, бонусное USB-устройство 456 - каждый включает в себя контроллер USB-периферии соответственно 450, 451, 452 и 455. USB-совместимые контроллеры периферии могут устанавливать USB-связь с ведущим игровым контроллером 224 путем подключения к USB-стеку, рассмотренному при описании фиг.1C. Однако USB-совместимые контроллеры периферии не могут хранить аппаратно-программное обеспечение или игровое программное обеспечение, необходимое для обслуживания периферийных устройств в комплектах игровой периферии. Подробное описание USB-совместимых контроллеров периферии приводится в совместно рассматриваемой заявке №10/246367 США, включенной в данное изобретение ранее.

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

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

После определения, какое аппаратно-программное обеспечение требуется для данной игровой периферии или периферийного устройства, санкционированное аппаратно-программное обеспечение может быть загружено ведущим игровым контроллером 224 из запоминающее устройства в составе игровой машины типа жесткого диска 226. В ответ на прием загруженного аппаратно-программного обеспечения игровая периферия может выполнить ряд самопроверок, чтобы определить, надлежащее ли программное обеспечение было загружено и работает ли периферийное устройство надлежащим образом. Когда игровое периферийное устройство работает надлежащим образом, оно может осуществить пересылку сообщения о статусе в ведущий игровой контроллер с указанием своего эксплуатационного статуса типа сообщения "готово к выполнению" или сообщения об ошибке.

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

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

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

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

Загрузки аппаратно-программного обеспечения в комплекты игровой периферии могут происходить в разное время. Например, загрузки аппаратно-программного обеспечения могут происходить 1) в ответ на включение питания игровой машины или периферийного устройства, 2) в ответ на нумерацию новой игровой периферии в игровой машине, 3) в ответ на загрузку новой игры в игровую машину, 4) в ответ на обновление программного обеспечения, 5) в ответ на произвольные сигналы запуска типа вырабатываемых в произвольный период времени для принятия мер по обеспечению безопасности и 6) их комбинации. Загрузки аппаратно-программного обеспечения могут осуществляться для множества периферийных устройств, например при включении питания, или для отдельных устройств, например во время нумерации нового периферийного устройства.

После инициализации передача информации между комплектами игровой периферии типа 293, 396 и 18 и ведущим игровым контроллером 224 может осуществляться в зашифрованном виде. Шифрованию может подвергаться вся или часть передаваемой информации. Например, данные из монетоприемника 293 с указанием кредита, отправляемые в игровую машину, могут подвергаться шифрованию для предотвращения взлома. Шифрование может выполняться с использованием комбинации аппаратных средств и программного обеспечения. Например, в одном примере осуществления микросхемы шифрования могут быть использованы определенными устройствами типа банкнотоприемника 296 и монетоприемника 239 и ведущего игровой контроллера 224, чтобы обеспечить защищенную связь. В другом примере осуществления применительно к передаваемым данным могут быть использованы программные алгоритмы шифрования. Таким образом, и комплекты игровой периферии, и ведущий игровой контроллер 224 могут использовать программное обеспечение, которое обеспечивает шифрование и дешифрование передаваемых данных.

После инициализации всех комплектов игровой периферии, содержащих интерфейс игровой машины, может быть осуществлена генерация представления игры. В одном примере осуществления может быть генерировано представление видеоигры, содержащее последовательность видеокадров. Каждый кадр в последовательности кадров в представлении игры временно хранится в видеопамяти 236, локализованной в ведущем игровом контроллере 224 или, в другом варианте изобретения, в видеоконтроллере 237, который может также рассматриваться как часть ведущего игрового контроллера 224. Игровая машина 2 может также включает в себя видеокарту (не показанную) с отдельной памятью и процессором для выполнения графических функций в игровой машине типа двумерных визуализации трехмерных объектов, определяемых в трехмерной игровой среде, хранимой в игровой машине.

Как правило, видеопамять 236 включает в себя один или более буферов кадра, которые хранят данные кадра, пересылаемые видеоконтроллером 237 в дисплей 34 или дисплей 42. Видеоконтроллер осуществляет прямую адресацию буфера кадра в видеопамяти. Видеопамять и видеоконтроллер может быть включены в состав видеокарты, которая подключается к плате процессора, содержащей ведущий игровой контроллер 224. Буфер кадров может состоять из RAM, VRAM, SRAM, SDRAM и т.д.

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

Предварительно записанные кадры, хранимые в игровой машине, могут быть отображены с использованием "потокового" видео. В потоковом видео осуществляется поточная передача последовательности предварительно записанных кадров, хранимых в игровой машине, через буфер кадров видеоконтроллера 237 в один или более дисплеев. Например, может быть осуществлена поточная передача кадра, соответствующего фильму, хранимому в игровом разделе 223 жесткого диска 226, на CD-ROM или в каком-либо другом запоминающем устройстве, в дисплеи 34 и 42 как часть представления игры. Таким образом, представление игры может включать в себя кадры, графически визуализированные в реальном масштабе времени с использованием графических библиотеки, хранимых в игровой машине, а также и предварительно визуализированные кадры, хранимые в игровой машине 2.

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

Во время представления игры ведущий игровой контроллер 224 может выбирать и захватывать определенные кадры, чтобы создать хронологию игры. Эти решения принимаются в соответствии с кодом конкретной игры, исполняемым контроллером 224. Захваченные кадры могут быть включены в кадры хронологии игры. Как правило, захватывается один или более кадров, критических для представления игры. Например, в представлении видеослот-игры захватывается кадр представления игры, отображающий конечное положение барабанов. В видеоигре Блэк Джек ведущий игровой контроллер 224 может выбирать и захватывать в качестве заданных кадр, соответствующий начальным картам игрока и раздающего карты, кадрам, соответствующим промежуточным картам на руках игрока и раздающего карты, и кадр, соответствующий заключительным картам на руках игрока и раздающего карты.

Различные игровые программные модули, используемые для проведения азартных игр различных типов, могут храниться на жестком диске 226. Каждая игра может храниться в своем собственном каталоге, чтобы облегчить инсталляцию новых игр (и удаление старых) в эксплуатационных условиях. Чтобы инсталлировать новую игру, может быть использована утилита для создания каталога и копирования необходимых файлов на жесткий диск 226. Для удаления игры может быть использована утилита, удаляющая каталог, который содержит игру и ее файлы. В каждом игровом каталоге может быть много подкаталогов для систематизации информации. Часть игровой информации в игровых каталогах представляет собой: 1) игровой процесс и ассоциированные с ним игровые программные модули, 2) графические/звуковые файлы/фраза(ы), 3) файл таблицы выигрышей и 4) файл конфигурации. Подобная структура каталога может быть также создана в NV-памяти 234. Кроме того, каждая игра может иметь свой собственный каталог в файловой структуре энергонезависимой памяти, чтобы обеспечить при необходимости возможность инсталляции и удаления каждой игры из энергонезависимой памяти.

При начальной загрузке менеджер по играм (см. фиг.1C) или другой процесс в игровой операционной системе может выполнять итерации через игровые каталоги на жестком диске 226 и обнаруживать имеющиеся игры. Менеджер по играм может получить всю необходимую информацию о них, чтобы решить, какие игры можно проводить и как обеспечить пользователю возможность выбора одной игры (множества игр). Менеджер по играм может подтвердить, что имеется взаимно однозначное соответствие между каталогами в NV-памяти 234 и каталогами на жестком диске 226. Детали структур каталога на NV-памяти и жестком диске 226 и процесса верификации описаны в совместно рассматриваемой заявке №09/925098 США под названием "Process Verification" ("Процесс верификации"), поданной Cockerille с соавт.8 августа 2001 г. и включенной в данное изобретение полностью и для всех целей.

На фиг.6 представлена блок-схема процесса 460 инициализации с использованием менеджера классов USB-устройств. На этапе 462 менеджер классов USB-устройств считывает файл реестра и запускает процессы драйверов, которые были санкционированы. Эти процессы представляют собой драйверы нижнего уровня, которые должны быть запущены перед выполнением других драйверов. Примером такого драйвера является сторонний драйвер, рассмотренный со ссылками на фиг 4.

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

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

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

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

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

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

На этапе 468 после обнаружения одного или более комплектов игровой периферии менеджер классов USB-устройств может найти периферию, для которой требуется загрузка аппаратно-программного обеспечения. В одном примере осуществления, рассмотренном более подробно при описании фиг.5, игровая USB-периферия может функционировать только как загружаемое устройство и может требовать загрузки аппаратно-программного обеспечения прежде, чем оно сможет функционировать как специфическая игровая периферия, например банкнотоприемник. Эта настройка может обеспечить дополнительную безопасность, так как игровая машина имеет санкционированное рабочее аппаратно-программное обеспечение для периферии, в то время как периферия не имеет. Игровая машина может централизованно управлять санкционированным аппаратно-программным обеспечением в защищенном режиме. Цель этого принципа состоит в том, чтобы гарантировать, что во время работы машины периферия выполняет санкционированное аппаратно-программное обеспечение.

На этапе 468 менеджер классов USB-устройств может инициировать процедуру загрузки через драйвер совместно используемого объекта. Как только процесс загрузки аппаратно-программного обеспечения заканчивается для всех комплектов периферии, которым требуется загрузка, на этапе 470 менеджер классов USB-устройств может выйти из своего состояния инициализации и может перейти в состояние, совместимое с операциями нормального времени выполнения.

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

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

Менеджер классов USB-устройств может также обеспечивать верификацию аппаратно-программного обеспечения периферии с помощью CRC или по-другому - с помощью функции хеширования. Например, менеджер классов USB-устройств может инициировать запрос в игровую периферию на генерацию CRC всего ее аппаратно-программного обеспечения или произвольного раздела ее аппаратно-программного обеспечения. Этот CRC может быть подвергнут сравнению с CRC санкционированного аппаратно-программного обеспечения, хранимого в игровой машине (например, см. жесткий диск 226 на фиг.5). Этот способ может быть использован для того, чтобы гарантировать постоянное выполнение периферией надлежащего аппаратно-программного обеспечения. Алгоритмы функции хеширования могут быть также использованы для подписи сообщений, пересылаемых между устройствами. Содержимое сообщения может быть подвергнуто верификации с использованием алгоритмов функции хеширования.

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

На фиг.7 представлена блок-схема архитектуры 800 USB-связи, которая может быть использована для обеспечения USB-связи в настоящем изобретении. USB-устройство 803 может быть подразделено на ряд компонентов типа устройства, конфигурации, интерфейса и оконечной точки. Спецификации классов устройств определяют, как устройство использует эти компоненты для доставки имеющихся функциональных возможностей в хост-систему. Спецификации классов устройств могут варьироваться от класса к классу. В некоторых случаях спецификации классов устройств являются стандартами, которые поддерживаются организацией группы USB-пользователей и были подвергнуты анализу и процессу санкционирования со стороны группы USB-пользователей. Например, USB-класс HID (устройств интерфейса с пользователем) является классом стандартных USB-устройств. В других случаях спецификации классов устройств могут быть ориентированы на класс устройств конкретной фирмы-поставщика и разработаны фирмой-поставщиком для удовлетворения специфических требований фирмы-поставщика. Важно обратить внимание на то, что USB создает инфраструктуру для генерации спецификации класса устройств, но что фактическая реализация спецификации класса устройств может явиться уникальным примером осуществления, который генерируется разработчиком или разработчиками спецификации класса.

В некоторых случаях хост-система использует информацию о конкретном устройстве в дескрипторе устройства или интерфейса, чтобы ассоциировать устройство с драйвером типа протокола идентификации устройства. Стандартные дескрипторы устройства и интерфейса содержат поля, которые относятся к классификации: класс, подкласс и протокол. Эти поля могут быть использованы хост-системой, чтобы ассоциировать устройство или интерфейс с драйвером в зависимости от того, как они заданы спецификацией класса. Примеры осуществления протокола идентификации USB-совместимых устройств описываются в совместно рассматриваемой заявке №10/460866 (№IGT1 Р100 по реестру поверенных) США под названием "Protocols and Standards for USB Peripheral Communications" ("Протоколы и стандарты для коммуникаций с USB-периферией"), поданной 11 июня 2003 г. Quraishi с соавт. и включенной в данное изобретение ранее. Другой пример осуществления протокола идентификации USB-совместимых устройств описан в совместно рассматриваемой заявке №10/246367 США под названием "USB Device Protocol for Gaming Machine" ("Протокол USB-устройств для игровой машины", включенной в данное изобретение ранее.

Взаимоотношения между USB-устройством 803 и хост-системой 801 могут быть описаны согласно ряду уровней. На самом низком уровне хост-контроллер 814 физически обменивается информацией с контроллером 816 устройства в USB-устройстве 803 через USB 818. Как правило, хост 801 требует хост-контроллера 814, а каждое USB-устройство 800 требует контроллера 816 устройства.

На среднем уровне системное программное обеспечение 810 USB может использовать абстракцию устройств, определяемую в Universal Serial Bus Specification, для взаимодействия с интерфейсом USB-устройства в USB-устройстве. Интерфейс USB-устройства является аппаратным средством (типа аппаратно-программного обеспечения) или программным обеспечением, которое отвечает на стандартные запросы и возвращает стандартные дескрипторы. Стандартные дескрипторы позволяют хост-системе 801 "узнавать" о возможностях USB-устройства 803. Universal Serial Bus Specification создает инфраструктуру 808 устройства типа описаний стандартных дескрипторов и стандартных запросов. Эта связь выполняется через USB-стек, рассмотренный при описании фиг.1C.

На самом высоком уровне драйвер 804 устройства использует абстракцию интерфейсов, чтобы взаимодействовать с функцией, предоставляемой физическим устройством. Драйвер 804 устройства может управлять устройствами с определенными функциональными характеристиками в общем. Функциональные характеристики могут быть одним интерфейсом USB-устройства или это может быть группа интерфейсов. В случае группы интерфейсов USB-устройство может реализовывать спецификацию класса устройств. Если интерфейс принадлежит к конкретному классу, спецификация класса может определять эту абстракцию. Спецификации классов добавляют другой уровень требований, непосредственно связанных с тем, как программное обеспечение взаимодействует с возможностью, выполняемой устройством или интерфейсом, который является компонентом класса. Настоящее изобретение может использовать спецификацию класса игровой USB-периферии, которая является классом устройств конкретной фирмы-поставщика, что может быть использовано для обеспечения USB-связи в игровой машине. Класс конкретной фирмы-поставщика может быть определен для удовлетворения специфических требований USB-связи в игровой машине типа требований по безопасности, которые не обеспечиваются другими классами стандартных USB-устройств.

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

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

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

Как показано на фиг.7, в контексте USB-архитектуры 800 термин "устройство" может иметь различное значение в зависимости от контекста, в котором он используется. Устройство в USB-архитектуре может быть логическим или физическим объектом, выполняющим одну или более функций. Фактически описываемый объект зависит от контекста ссылки. На самом низком уровне устройство может быть одним аппаратным компонентом типа запоминающего устройства. На более высоком уровне устройство может быть совокупностью аппаратных компонентов, которые выполняют конкретную функцию типа интерфейсного устройства USB. На еще более высоком уровне термин "устройство" может относиться к функции 806, выполняемой объектом, подключенным к USB, типа устройства отображения. Устройства могут быть физическими, электрическими, адресуемыми или логическими. Как правило, при использовании в качестве неспецифической ссылки устройство является или концентратором или функцией 806. Концентратор - это USB-устройство, обеспечивающее точки подключения к USB.

Типичный маршрут USB-связи может начинаться с процесса, исполняемого в хост-системе, которая может желать управлять функцией физического устройства. Драйвер 804 устройства может послать сообщение в программное обеспечение USB 810. Программное обеспечение USB может обработать сообщение и переслать его в хост-контроллер 814. Хост-контроллер 814 может передать сообщение через последовательную шину 818 в аппаратное средство 816. Интерфейс USB может обработать сообщение, полученное из аппаратного средства, и направить его в целевой интерфейс, который может направить информацию в физическое устройство, выполняющее требуемую операцию.

USB изменяет традиционные взаимоотношения между драйвером и устройством. Взамен обеспечения прямого аппаратного доступа драйвера к устройству USB ограничивает связь между драйвером и устройством четырьмя основными типами передачи (т.е. передачей массивов данных, передачей управления, передачей с прерываниями и изохронной передачей), реализуемой как программный интерфейс, предоставляемый хост-средой. Следовательно, устройство должно отвечать в соответствии с ожиданиями уровней системного программного обеспечения или драйвер не сможет обмениваться информацией со своим устройством. По этой причине USB-совместимые классы типа класса HID 401, класса 403 принтеров, класса 405 устройств фирмы-поставщика IGT и класса 407 звуковых устройств (см. фиг.2) основаны по меньшей мере на том, как устройство или интерфейс подключено к USB, а не только на атрибутах или услугах, предоставляемых устройством.

В примере класс может описывать, как игровая USB-периферия подключена к хост-системе - как один однонаправленный канал вывода или как два однонаправленных канала, один канал вывода и один канал ввода в для возврата детального статуса. Класс игровой периферии может также основываться на формате данных, пересылаемых между хостом и устройством. Несмотря на возможность использования потоков необработанных (или неопределенных) данных, класс может также идентифицировать форматы данных более специфически. Например, канал вывода (и необязательный канал ввода) может выбрать инкапсуляцию данных игровой периферии, как определено в другом промышленном стандарте типа протокола SAS (системы бухгалтерского учета для слот-машин), используемого IGT (Reno, NV). Класс игровой периферии может создавать механизм возврата этой информации с использованием команды, специфическую для класса.

На фиг.8 представлена блок-схема ведущего игрового контроллера 224, участвующего в обмене информацией с игровой USB-периферией 830. Ведущий игровой контроллер 224 можно рассматривать в качестве хоста 801 с аппаратными и программными функциональными возможностями, как было указано при описании фиг.7. Игровая USB-периферия 830 может считаться имеющей аппаратные и программные функциональные возможности USB-устройства, как было указано при описании фиг.7.

Ведущий игровой контроллер 224 может использовать USB-связь 850 для обмена информацией с рядом периферийных устройств типа источников света, принтеров, счетчиков монет, банкнотоприемников, считывателей билетов, считывателей карточек, малых клавишных панелей, кнопочных панелей, экранов дисплеев, динамиков, информационных панелей, двигателей, запоминающих устройств большой емкости и соленоидов. Некоторые из этих устройств были описаны при рассмотрении фиг.1А и 5. USB-связь 850 может включать в себя аппаратные средства и программное обеспечение, в том числе программное обеспечение USB 816, хост-контроллер 814, последовательную шину 818, интерфейсы 812 USB, контроллер 832 USB-периферии и концентратор USB (не показанный). Контроллер 831 USB-периферии может обеспечивать функциональные возможности контроллера 816 устройства (см. фиг.7) для игровой USB-периферии 830. Контроллер 831 USB-периферии может быть примером осуществления контроллеров периферии, рассмотренных при описании фиг.5 и в совместно рассматриваемой заявке №10/246367 США, включенной в данное изобретение ранее.

USB-связь 850 может позволить игровому программному обеспечению 820 типа операционной системы 102 игровой машины использовать игровые драйверы 259 типа игровых драйверов настроек и игровых драйверов классов для управления настройками типа 833, 834 и 836 в периферийных устройствах 838 и 840. Логика для каждой игровой USB-периферии 830 может быть разделена на совокупность USB-настроек типа 833, 834 и 836. USB-настройка может быть независимым кодом, который управляет одним устройством ввода/вывода или несколькими по существу идентичными устройствами ввода/вывода типа барабанов или бонусных колес. Санкция на использование независимого кода может быть выдана одной или более организациями типа сотрудников органа, регулирующего игровой бизнес, в одной или более игровых юрисдикциях или организации, ответственной за безопасность игровой машины (например, основной фирмы-изготовителя игровой машины или интересующего игрового устройства). Например, устройство 838 может представлять собой бонусные колеса для игровой машины, а устройство 840 - один или более барабанов для механической слот-машины. Настройка 834 может управлять источниками света для бонусного колеса 840, а настройка 836 может управлять движением бонусного колеса, например началом вращения, раскручиванием, торможением и остановом. Настройка 833 может управлять подобными функциями для одного или более барабанов 840, т.е. началом вращения, раскручиванием, торможением и остановом для каждого барабана.

В игровой USB-периферии 830 каждое устройство типа 838 и 840 может иметь одну или более настроек. Настоящее изобретение не ограничено устройствами с двумя настройками типа 838, и устройство может иметь множество настроек. Каждая USB-настройка может в типичном случае иметь единую цель, которая может быть определена в классе игровой периферии, соответствующей настоящему изобретению. Например, игровая USB-периферия 830 с двумя устройствами типа кнопок для ввода данных и источников света для вывода может иметь две настройки - настройку кнопок и настройку источников света. Управление настройкой кнопок и настройкой источников света может осуществляться соответствующими игровыми драйверами настроек в игровых драйверах 259. Например, игровой драйвер настройки кнопок может управлять настройкой кнопок, а игровой драйвер настройки источников света может управлять настройкой источников света посредством USB-связи 850.

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

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

Как указывается при описании фиг.5 и 6, в некоторых случаях может быть желательным проведение загрузки аппаратно-программного обеспечения в игровую USB-периферию, которая была подвергнута нумерации без аппаратно-программного обеспечения, или обновления существующего аппаратно-программного обеспечения в игровой USB-периферии. Аппаратно-программное обеспечение может быть загружено или обновлено для одного или более периферийных устройств в составе игровой USB-периферии. При описании фиг.9-12 рассматриваются уникальные идентификаторы устройств, обеспечивающие возможность подключения периферийного устройства в составе игровой USB-периферии к хост-системе для приема загружаемого аппаратно-программного обеспечения. Уникальные идентификаторы могут представлять собой строковые идентификаторы, хранимые в игровой USB-периферии. Строковые идентификаторы могут стать доступными в режиме обновления аппаратно-программного обеспечения устройств (DFU), определяемом USB, или в режиме нормального времени выполнения. Программное обеспечение хоста может использовать строковую идентичность для поиска аппаратно-программного обеспечение устройств в базе данных или файловой структуре каталога и загрузки или обновления аппаратно-программного обеспечения устройств с использованием методов, являющихся совместимыми со "Спецификацией классов USB-устройств для обновления аппаратно-программного обеспечения устройств" ("USB Device Class Specification for Device Upgrade"), опубликованной группой по стандартам USB, USB-IF, Portland, Oregon, http://www. usb. org., version 1.0 от 13 мая 1999 г., которая включена в данное изобретение полностью и для всех целей.

На фиг.9 представлена блок-схема периферийных устройств с возможностью DFU, участвующих в обмене информацией с менеджерами классов USB-устройств во время режима времени выполнения. Промышленные стандарты USB обеспечивают возможность подключения множества периферийных устройств к хост-системе. Например, на фиг.9 три периферийных устройства 701, 703 и 705 подключены к игровой хост-машине через менеджер 75 классов USB-устройств. Эти три периферийных устройства могут быть компонентами одной игровой USB-периферии или комбинацией комплектов игровой USB-периферии.

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

В общем случае аппаратно-программное обеспечение может относиться к исполнимому программному обеспечению, хранимому в периферийном устройстве. Аппаратно-программное обеспечение может быть хранится в перезаписываемой энергонезависимой памяти, в постоянной энергонезависимой памяти или в энергозависимой памяти. Разумеется, аппаратно-программное обеспечение, хранимое в постоянной памяти, как правило, является необновляемым. В настоящем изобретении один класс периферийных устройств может включать в себя встроенное аппаратно-программное обеспечение (например, программное), используемое для обслуживания устройство и для обмена информацией с хостом. Как правило, эти устройства хранят аппаратно-программное обеспечение в энергонезависимой памяти. Может быть использован другой класс периферийных устройств, которые постоянно не хранят часть своего аппаратно-программного обеспечения и могут полагаться на программное обеспечение хоста для загрузки части этого аппаратно-программного обеспечения после нумерации. Например, эти устройства могут включать в себя базовое аппаратно-программное обеспечение, которое позволяет им обмениваться информацией через USB и идентифицировать себя хосту. Однако, как об этом говорится при описании фиг.5, периферийное устройство может быть инициализировано без части требуемого для работы аппаратно-программного обеспечения.

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

Стандарты USB создают инфраструктуру, которая позволяет хосту типа менеджера 75 классов USB-устройств обновлять аппаратно-программное обеспечение периферийного устройства типа 701, 703 и 705. USB-спецификации DFU требуют, чтобы DFU-способное периферийное устройство во время операции нормального времени выполнения осуществило нумерацию дополнительного интерфейса. Например, периферийное устройство 701, 703 и 705 - каждое объявляет во время выполнения один или более интерфейсов, например, от интерфейса 0 до интерфейса X. Дополнительно, периферийные устройства 701 и 703 - каждое объявляет во время выполнения дополнительный DFU-интерфейс 717 и 719. Периферийное устройство 705 не объявляет DFU-интерфейса хосту и поэтому не может обеспечивать обновления аппаратно-программного обеспечения USB-DFU-совместимыми методами. Однако обновление периферийного устройства может осуществляться другими методами. Другие методы загрузки периферии, которые могут быть использованы в настоящем изобретении, описываются в патенте №5759102 США Pease с соавт. под названием "Peripheral Device Download method and Apparatus" ("Способ и устройство для загрузки периферийного устройства"), опубликованном 2 июня 1998 г., который включен в данное изобретение полностью и для всех целей.

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

Во время операций времени выполнения периферийное устройство может объявить дескриптор одного DFU-интерфейса класса и функциональный дескриптор в дополнение к своему нормальному набору дескрипторов. Например, периферийное устройство 701 объявляет набор 707 дескрипторов времени выполнения, а периферийное устройство 703 объявляет набор 711 дескрипторов времени выполнения. Хост может использовать информацию из наборов дескрипторов и интерфейса, чтобы инициировать USB-процесс загрузки DFU (см. фиг.11 и 12).

USB-спецификация DFU была разработана исходя из предположений, что 1) уже развернутое и эксплуатируемое устройство должно быть модернизировано с помощью аппаратно-программного обеспечения и 2) одновременное выполнение операций DFU и действий нормального времени выполнения является для устройства непрактичным. Таким образом, спецификация требует от устройства объявления DFU-интерфейса во время операций нормального времени выполнения и прекращения этих нормальных действий во время операций DFU. Это означает, что устройству требуется изменение своего режима работы; т.е. принтер во время обновления аппаратно-программного обеспечения не является принтером; это - программатор энергонезависимой памяти типа программатор ППЗУ. Однако устройство, поддерживающее DFU, не может изменить свой режим работы по своей собственной воле. Может потребоваться внешнее вмешательство (со стороны человека или операционной системы хоста).

Имеются четыре различные стадии, требуемые для выполнения обновления аппаратно-программного обеспечения (детали показаны на фиг.12):

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

2. Реконфигурация: хост и устройство соглашаются инициировать обновление аппаратно-программного обеспечения. Хост отдает устройству команду сброса USB, сопровождаемую запросом на отключение DFU, в пределах периода времени, задаваемого устройством, и устройство затем экспортирует второй набор дескрипторов при подготовке к стадии передачи. Это дезактивирует драйверы времени выполнения устройства, ассоциированные с устройством, и позволяет драйверу DFU перепрограммировать аппаратно-программное обеспечение устройства без препятствий со стороны любого другого трафика связи, адресуемого устройству.

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

4. Демонстрация: Как только устройство сообщает в хост о завершении операций перепрограммирования, хост отдает устройству команду сброса USB. Устройство проводит повторную нумерацию и исполняет обновленное аппаратно-программное обеспечение.

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

Как было указано выше, как только начинается процесс DFU, периферийное устройство утрачивает свои исходные функциональные возможности и сохраняет лишь способность к передаче аппаратно-программного обеспечения. Периферийное устройство объявляет второй набор дескрипторов в этом режиме. На фиг.10 представлена блок-схема менеджера классов USB-устройств и периферийного устройства при обмене информацией в режиме DFU. Хост, а именно менеджер 75 классов USB-устройств может осуществить загрузку драйвера DFU 725, который выполняет процесс загрузки. Драйвер DFU 725 обменивается информацией с периферийным устройством 701 через оконечную точку 721 управления. Через оконечную точку 721 периферийное устройство 701 поставляет информацию на хост с помощью своего набора 709 дескрипторов DFU.

Периферийные устройства, постоянно не хранящие аппаратно-программного обеспечения нормального времени выполнения, могут требовать загрузки программы со стороны хоста после нумерации. Для этой цели может быть использован процесс DFU, задаваемый USB. Таким устройствам может потребоваться включение питания в режиме DFU. Они объявляют набор дескрипторов режима DFU, как описывается выше, включают питание и ожидают от хоста продолжения процесса DFU. Например, на фиг.10 периферийное устройство 701 может включить питание в режиме DFU скорее, чем хост переключит его из режима времени выполнения в режим DFU.

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

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

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

В других примерах осуществления модифицированию может быть подвергнут один из других дескрипторов в дескрипторе устройства для режима DFU или дескрипторах интерфейса для режима DFU. Версия Version 1.0 спецификации описывает 18 полей в наборе дескрипторов устройства для режима DFU, 9 полей в наборе дескрипторов интерфейса для режима DFU, 9 полей в наборе дескрипторов DFU-интерфейса для времени выполнения и четыре поля в наборе функциональных дескрипторов DFU для времени выполнения, который используется как в режиме времени выполнения, так и в режиме DFU. Недостаток модифицирования других дескрипторов состоит в том, что модификации могут приводить к несоответствию USB или к утрате другой существенной информации. Например, может быть модифицирован тег idProduct, назначенный фирмой-изготовителем. Однако модифицирование тега idProduct приводит к невозможности определения фирмы-изготовителя устройства, что является желательным при нарушении работоспособности устройства.

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

На фиг.11 представлена блок-схема менеджера классов USB-устройств, загружающего аппаратно-программное обеспечение во множество периферийных устройств. Периферийные устройства могут быть инсталлированы в игровой машине способом, описываемым при рассмотрении фиг.1 и 5. На фиг.11 показаны пять периферийных устройств - бонусное периферийное устройство 707, бонусное периферийное устройство 711, бонусное периферийное устройство 732, периферийное устройство 734 в виде принтера и периферийное устройство 738 в виде малой клавишной панели.

Каждому устройству назначена строка идентификатора аппаратно-программного обеспечения. В одном примере осуществления строка идентификатора аппаратно-программного обеспечения может быть просто числом, причем это число может быть отображено в дополнительной информации, обеспечивающей возможность локализации аппаратно-программного обеспечения для периферийного устройства. В другом примере осуществления строка идентификатора аппаратно-программного обеспечения может содержать алфавитно-цифровые знаки. Формат и значение чисел и/или алфавитно-цифровых знаков может быть определен как часть протокола идентификации устройств. Один протокол идентификации устройств, который может быть использован в настоящем изобретении, был описан в патенте №6251014 США, ранее включенном в данное изобретение.

В настоящем изобретении в контексте USB-методов DFU строка идентификатора аппаратно-программного обеспечения может быть как отделена, так и совмещена с идентификатором фирмы-поставщика (idVendor), идентификатором продукта (idProduct), номером версии устройства (bcddevice), также как и дескрипторы строк iManufacturer, iProduct и iSerial в наборе дескрипторов устройства режима DFU. В конкретном примере осуществления информация протокола устройства может передаваться через поле ilnterface, которое определяет индекс дескриптора строки, в дескрипторе интерфейса для режима DFU и наборе дескрипторов DFU-интерфейса для времени выполнения.

Как показано на фиг.11, строка 730 идентификатора для устройства 707 обеспечивает информацию, которая позволяет хосту определить, что устройство 707 требует аппаратно-программное обеспечение "бонусное устройство А". Устройство 711 также использует строку 730 идентификатора аппаратно-программного обеспечения и поэтому устройство 711 использует то же самое аппаратно-программное обеспечение в этом примере как устройство 730. Устройство 732 использует строку 733 идентификатора, которая указывает, что для устройства 732 требуется аппаратно-программное обеспечение "бонусное устройство В". Используя строку 733 идентификатора аппаратно-программного обеспечения, хост (например, менеджер классов USB-устройств и/или драйвер DFU 725) может определить, что устройству 732 необходимо аппаратно-программное обеспечение, локализовать аппаратно-программное обеспечение в базе 453 данных и загрузить аппаратно-программное обеспечение в устройство 732 или закончить загрузку аппаратно-программного обеспечения в случае невозможности локализации необходимого аппаратно-программного обеспечения.

В настоящем примере бонусные периферийные устройства 707, 711 и 732 могут быть устройствами одного и того же типа, например бонусным колесом. Поэтому устройства 707, 711, 732 могут совместно использовать одну и ту же идентификационную информацию в USB-протоколе DFU, типа одного и того же идентификатора фирмы-поставщика, одного и того же идентификатора фирмы-изготовителя, одного и того же идентификатора продукта и одного и того же регистрационного номера. В общем случае настоящее изобретение может поддерживать различные экземпляры реализации одного и того же устройства. В настоящем изобретении при наличии различных экземпляров реализации одного и того периферийного устройства строки идентификатора аппаратно-программного обеспечения могут быть сделаны уникальными для каждого устройства, что позволит загружать различное аппаратно-программное обеспечение для идентичных устройств. Так как для идентичных устройств идентификационная информация устройств в контексте USB-протокола DFU может быть одной и той же, хост не может использовать эту информацию для определения аппаратно-программного обеспечения, подлежащего загрузке, и вместо этого может использовать строку идентификатора аппаратно-программного обеспечения в протоколе идентификации устройств, соответствующем настоящему изобретению. Этот способ позволит хосту передавать уникальное аппаратно-программное обеспечение в периферийные устройства одной и той же конфигурации, что не возможно осуществить с помощью существующих USB-процедур DFU.

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

Как показано на фиг.11, периферийное устройство 734 в виде принтера может использовать строку 736 идентификатору аппаратно-программного обеспечения, которая позволяет хосту локализовать и загрузить аппаратно-программное обеспечение "принтер А", подлежащее загрузке в устройство. Периферийное устройство 738 в виде малой клавишной панели может использовать строку 740 идентификатора аппаратно-программного обеспечения, которая позволяет хосту локализовать и загрузить аппаратно-программное обеспечение "малая клавишная панель А" в устройство. Настоящее изобретение не ограничено загрузками аппаратно-программного обеспечения для этих 5 периферийных устройств, показанных на фиг.11, которые представлены исключительно в иллюстративных целях.

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

На фиг.12 представлена диаграмма взаимодействия между хостом и периферийным устройством 707 во время загрузки аппаратно-программного обеспечения USB 750 в игровую машину. Хост-устройство, которое может быть ведущим игровым контроллером, может исполнять один или более процессов типа менеджера 75 классов USB-устройств и драйвера DFU (см. фиг.10 и 11) для загрузки аппаратно-программного обеспечения в периферийное устройство 707. Периферийное устройство 707 может постоянно находиться в игровой USB-периферии (см. фиг.8), соответствующей настоящему изобретению.

На этапе 751 может быть осуществлен запуск обновления аппаратно-программного обеспечения. Например, после приема нового аппаратно-программного обеспечения с удаленного сервера или после инсталляции запоминающее устройства типа нового CD или DVD, содержащего новое аппаратно-программное обеспечение, в игровой машине. Хост может проверить новое аппаратно-программное обеспечение, чтобы сравнить его с записями аппаратно-программного обеспечения, в настоящее время хранимого в каждом из своих периферийных устройств. Эти записи могут храниться в база данных аппаратно-программного обеспечения, поддерживаемого в игровой машине. Кроме того, хост может сделать запрос в одно или более периферийных устройств, чтобы определить аппаратно-программное обеспечение, исполняемое в настоящее время в устройстве, и сравнить его со вновь принимаемым аппаратно-программным обеспечением, чтобы определить запуск обновления аппаратно-программного обеспечения. В одном примере осуществления удаленное устройство типа удаленного сервера или специалист по обслуживанию игровой машины может запустить обновление аппаратно-программного обеспечения с помощью ведущего игрового контроллера.

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

В некоторых случаях обновление может быть критическим. Например, может быть обнаружена брешь безопасности в устройстве типа банкнотоприемника. Для исправления бреши устройство может потребовать обновления аппаратно-программного обеспечения. В этом случае игровая машина может реализовать обновление по возможности скорее.

При подготовке к загрузке игровая машина может сделаться недоступной для проведения игр. Например, на экране дисплея игровой машины может появиться сообщение о неисправности. Затем, на этапе 754 хост может осуществить пересылку команды на сброс USB в периферийное устройство для приема аппаратно-программного обеспечения. Сброс шины USB осуществляется для останова всех драйверов времени выполнения в периферийном устройстве 707 и может вызвать разгрузку драйверов.

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

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

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

На этапе 762 хост может загрузить выбранное аппаратно-программное обеспечение в периферийное устройство. Изображения в составе аппаратно-программного обеспечения для устройств конкретной фирмы-поставщика по определению зависят от фирмы-поставщика. Поэтому USB-спецификация DFU требует инкапсуляции целевых адресов, размеров записей и всей другой информации относительно поддержки обновления внутри файла изображений в составе аппаратно-программного обеспечения. Фирма-изготовитель устройства и разработчик аппаратно-программного обеспечения несут ответственность за гарантию потребления их устройствами инкапсулированных данных. За исключением суффикса DFU файла, содержимое файла изображений в составе аппаратно-программного обеспечения является несоответствующим хосту. Хост просто делит файл изображений в составе аппаратно-программного обеспечения на N частей и пересылает их в устройство посредством операций управляющей записи в заданной по умолчанию оконечной точке управления.

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

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

Если устройство 707 обнаруживает ошибку, он сигнализирует хосту путем выдачи подтверждения сигнала STALL связи в оконечной точке управления. Хост затем может переслать запрос на DFU конкретного класса устройств, называемый DFU_GETSTATUS, в оконечной точке управления, чтобы определить природу проблемы. Имеются три общих механизма приема изображения в составе аппаратно-программного обеспечения из хоста, используемых устройством. Первый механизм заключается в приеме всего изображения в буфер и выполнении фактического программирования во время стадии демонстрации. Второй механизм состоит в накоплении блока данных аппаратно-программного обеспечения, стирании блока эквивалентного размера в памяти и записи блока в освобожденную память. Третий механизм является вариантом второго. В третьем методе стирается большая часть памяти, и небольшие блоки аппаратно-программного обеспечения записываются по одному в пустую область памяти. Необходимость в этом может возникать, когда степень структурированности памяти при стирании превышает доступный размер буфера.

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

На фиг.13 представлены блок-схемы игровых машин, которые используют распределенное игровое программное обеспечение и распределенные процессоры для генерации азартной игры для одного примера осуществления настоящего изобретения. Для представления одной или более игр на игровых машинах, 61, 62 и 63 используется ведущий игровой контроллер 224. Ведущий игровой контроллер 224 исполняет ряд игровых программных модулей для обслуживания игровых устройств 70 типа накопителей монет, банкнотоприемников, монетоприемников, динамиков, принтеров, источников света, дисплеев (например, 34) и других механизмов ввода/вывода (см. фиг.1 и 8). Игровая машина может также управлять настройками комплектов игровой периферии, локализованных вне игровой машины, типа удаленной игровой USB-периферии 84. Игровые машины 61, 62 и 63 могут также загружать программное обеспечение/аппаратно-программное обеспечение в эти игровые устройства (например, 70 и 84). Для USB-связи и загрузок аппаратно-программного обеспечения в игровые устройства 70 и 84 может быть использован менеджер классов USB-устройств, соответствующий настоящему изобретению.

Ведущий игровой контроллер 224 может также исполнять игровое программное обеспечение, позволяющее обмениваться информацией с игровыми устройствами, в том числе с удаленными серверами 83 и 86, локализованными вне игровых машин 61, 62 и 63, типа серверов трекинга игроков, серверов бонусных игр, игровых серверов и серверов прогрессивных игр. В некоторых примерах осуществления связь с устройствами, локализованными вне игровых машин, может осуществляться с помощью главной коммуникационной платы 213 и сетевых подключений 71. Сетевые подключения 71 могут обеспечивать обмен информацией с удаленными игровыми устройствами через локальную сеть, интрасеть. Internet, большую сеть 85 или их комбинацию.

Игровые машины 61, 62 и 63 могут использовать для генерации азартной игры игровые программные модули, которые могут быть распределены между локальными файловыми запоминающими устройствами и удаленными файловыми запоминающими устройствами. Например, для проведения азартной игры на игровой машине 61 ведущий игровой контроллер может загружать в RAM 56 игровые программные модули, которые могут быть локализованы в 1) файловом запоминающем устройстве 226 в игровой машине 61, 2) удаленном файловом запоминающем устройстве 81, 3) удаленном файловом запоминающем устройстве 82, 4) игровом сервере 90, 5) файловом запоминающем устройстве 226 в игровой машине 62, 6) файловом запоминающем устройстве 226 в игровой машине 63 или 7) их комбинации. В одном примере осуществления настоящего изобретения игровая операционная система может обеспечивать возможность использования файлов, хранимых в локальных файловых запоминающих устройствах и удаленных файловых запоминающих устройствах, как части совместно используемой файловой системы, где файлы в удаленных файловых запоминающих устройствах смонтированы в удаленной локальной файловой системе. Файловые запоминающие устройства могут представлять собой жесткий диск, CD-ROM, CD-DVD, статическую RAM, флэш-память, ППЗУ, компактную флэш-память, носитель информации "Смарт Медиа", твердотельный накопитель типа disk-on-chip, сменные носители информации (например, накопители "ЗИП" с дисками "ЗИП"), дискеты или их комбинации. В целях как безопасности, так и регламента игровое программное обеспечение, исполняемое в игровых машинах 61, 62 и 63 ведущими игровыми контроллерами 224, может подвергаться регулярной проверке путем сравнения программного обеспечения, хранимого в RAM 56 для исполнения в игровых машинах, с заверенными копиями программного обеспечения, хранимого в игровой машине (например, файлы могут храниться в файловом запоминающем устройстве 226), доступного для игровой машины через удаленное коммуникационное подключения (например, 81, 82 и 90) или их комбинации.

Игровой сервер 90 может быть репозиторием для игровых программных модулей, аппаратно-программного обеспечения игровой периферии и программного обеспечения для других игровых услуг, предоставляемых на игровых машинах 61, 62 и 63. В одном примере осуществления настоящего изобретения игровые машины 61, 62 и 63 могут загружать игровые программные модули с игрового сервера 90 в локальное файловое запоминающее устройство для проведения азартной игры или игровой сервер может инициировать загрузку. Один пример игрового сервера, который может быть использован в настоящем изобретении, описан в совместно рассматриваемой заявке №09/042192 на патент США под названием "Using a Gaming Machine as a Server" ("Использование игровой машины в качестве сервера"), поданной 16 июня 2000 г., которая включена в данное изобретение полностью и для всех целей. В другом примере игровой сервер может быть также специализированным компьютером или услугой, выполняемой на сервере вместе с другими прикладными программами.

В одном примере осуществления настоящего изобретения процессоры, используемые для генерации азартной игры, могут быть распределены среди различных машин. Например, логика игрового потока для проведения азартной игры может исполняться на игровом сервере 92 процессором 90, в то время как ведущий игровой контроллер 224 может исполнять логику представления игры в игровых машинах 61, 62 и 63. Игровые операционные системы в игровых машинах 61, 62 и 63 и игровой сервер 90 могут обеспечивать обмен игровыми событиями между различными игровыми программными модулями, исполняемыми в различных игровых машинах через определенные интерфейсы API. Таким образом, программный модуль игрового потока, исполняемый на игровом сервере 92, может осуществлять пересылку игровых событий в программный модуль представления игры, исполняемый в игровых машинах 61, 62 или 63, чтобы управлять проведением азартной игры или управлять проведением бонусной азартной игры, представляемой на игровых машинах 61, 62 и 63. В другом примере игровые машины 61, 62 и 63 могут осуществлять пересылку игровых событий одна другой через сетевое подключение 71, чтобы управлять проведением совместно используемой бонусной игры, проводимой одновременно на различных игровых машинах.

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

Реферат

Изобретение относится к средствам и способам обмена информацией между игровыми устройствами. Предлагаемая игровая машина соединена с множеством "комплектов игровой USB-периферии", которые могут включить в свой состав одно или более периферийных устройств, обмениваются информацией с ведущим игровым контроллером с использованием архитектуры USB-связи. Комплекты игровой USB-периферии могут включать в свой состав DFU-совместимые периферийные USB-устройства (DFU - обновление аппаратно-программного обеспечения устройств). Один или более хост-процессов типа менеджера классов USB-устройств или драйвера DFU могут быть выполнены с возможностью загрузки аппаратно-программного обеспечения в DFU-совместимое периферийное USB-устройство. Хост-процессы могут осуществлять прием идентификатора аппаратно-программного обеспечения из DFU-совместимого периферийного USB-устройства, причем идентификатор аппаратно-программного обеспечения допускает загрузку различного аппаратно-программного обеспечения для двух DFU-совместимых периферийных USB-устройств с идентичной идентификационной информацией о продукте. Изобретение позволяет упростить процесс разработки и тестирования программного обеспечения в игровых машинах. 57 з.п. ф-лы, 13 ил.

Формула