RU2331926C9 - Протоколы и стандарты для коммуникаций с usb-периферией - Google Patents

Abstract

Изобретение относится к средствам и способам обмена информацией между игровыми устройствами. Предлагаемая игровая машина соединена с множеством "комплектов игровой USB-периферии". Комплекты игровой USB-периферии, которые могут включить в свой состав одно или более периферийных устройств, обмениваются информацией с ведущим игровым контроллером с использованием архитектуры USB-связи. Архитектура USB-связи может включать в свой состав протокол классов USB-устройств конкретной фирмы-поставщика. Протокол классов USB-устройств конкретной фирмы-поставщика может содержать: 1) базовый протокол для определения обработки сообщений, относящихся к функциональным возможностям периферийных устройств, являющимся общими для множества периферийных устройств; и 2) одно или более расширений протокола для специфических настроек для определения обработки сообщений, являющихся специфическими для USB-настройки, причем каждое расширение протокола для специфической настройки определяет сообщения о специфической настройке. Базовый протокол может быть спроектирован так, что при модифицировании одного из сообщений о специфической настройке базовый протокол не изменяется. Изобретение позволяет упростить процесс разработки и тестирования программного обеспечения в игровых машинах. 68 з.п. ф-лы, 13 ил.

Description

РАЗРЕШЕНИЕ НА ИСПОЛЬЗОВАНИЕ

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

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

В соответствии с разделом 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-связи может включать в себя протокол класса устройств конкретной фирмы-поставщика. Протокол классов USB-устройств конкретной фирмы-поставщика может содержать: 1) базовый протокол для определения обработки сообщений, относящихся к функциональным возможностям периферийных устройств, являющимся общими для множества периферийных устройств; и 2) одно или более расширений протокола для специфических настроек для определения обработки сообщений, являющихся специфическими для USB-настройки, причем каждое расширение протокола для специфической настройки определяет сообщения о специфической настройке. Базовый протокол может быть спроектирован так, что не меняется при модифицировании одного из сообщений о специфической настройке.

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

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

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

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

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

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

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

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

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

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

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

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

В конкретных примерах осуществления игровая машина может дополнительно содержать 1) USB-стек, загружаемый игровой операционной системой, спроектированный для обеспечения коммуникационного USB-подключения для каждого из множества комплектов игровой USB-периферии, 2) запоминающее устройство для хранения санкционированного аппаратно-программного обеспечения, используемого одним или более комплектами игровой USB-периферии, 3) запоминающее устройство для хранения множества игровых программных модулей, 4) USB-совместимый хост-контроллер и/или 5) одно или более периферийных 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В - блок-схема архитектуры программного обеспечения игровой машины и ее взаимодействия с интерфейсом игровой машины для генерации азартной игры на игровой машине.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показаны три модуля игрового программного обеспечения - игровая операционная система 102, модуль 106 логики представления и модуль 104 логики игрового потока, используемые для представления азартной игры 125 в игровой машине. Дополнительные детали операционной системы игровой машины и аппаратно-программного USB-интерфейса описываются при рассмотрении фиг.1С. Игровая операционная система 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-периферии, согласующуюся с принципом разделения, описанным в предшествующих абзацах.

На фиг.1С представлены программные USB-компоненты, используемые в архитектуре USB-связи, типа менеджера 75 классов USB-устройств, интерфейсов USB-совместимых устройств и USB-стек 265, относящихся к различным другим процессам, исполняемым игровой операционной системой 102, и к аппаратным устройствам типа USB-монетоприемника 293, USB-считывателя 298 карточек, банкнотоприемника 296 и малой клавишной панели 294, которые являются частью интерфейса игровой машины. Для реализации этого изобретения могут быть использованы различные архитектуры аппаратных средств и программного обеспечения, и настоящее изобретение не ограничено архитектурой, показанной на фиг.1С. Основные части программного обеспечения 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 1.x и USB version 2.x, а также с будущими версиями USB. Далее, программные модули, используемые в архитектуре USB-связи для обеспечения USB-совместимой связи между USB-совместимым устройством и игровой операционной системой 102, которые удовлетворяют уникальным требованиям игровой машины типа требований по безопасности и требований по регламенту, описываются в следующих абзацах.

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

Обычно менеджер классов USB-устройств осуществляет инициализацию, обслуживание и управление интерфейсом 254 USB-устройств. Интерфейс 254 USB-устройств может содержать один или более специфических интерфейсов устройства, доступных на игровой машине. Например, на фиг.1С интерфейс 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 и в совместно рассматриваемой заявке №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/460822 (№ IGT1 Р099 по реестру поверенных) США под названием "USB Software Architecture in a Gaming Machine" ("Архитектура программного обеспечения USB в игровой машине"), поданной 11 июня 2003 Lam с соавт., которая включена в данное изобретение полностью и для всех целей. Настоящее изобретение не ограничено теми немногими стандартами и теми немногими классами устройств конкретных фирм-поставщиков, представленными на фиг.2, менеджером 75 классов USB-устройств могут поддерживаться и другие классы типа 409. Например, класс запоминающих устройств большой емкости и класс DFU-устройств представляют собой два класса, которые могут поддерживаться настоящим изобретением.

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-устройств. Как описывается при рассмотрении фиг.1С, процесс менеджера 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 драйвера - ни одного клиента. Как описывается со ссылками на фиг.1С, менеджер 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.11x (например другие стандарты IEEE 802.11 типа 802.11с или 802.11e), hyperian/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-стеку, рассмотренному при описании фиг.1С. Однако USB-совместимые контроллеры периферии не могут хранить аппаратно-программное обеспечение или игровое программное обеспечение, необходимое для обслуживания периферийных устройств в комплектах игровой периферии. Подробное описание USB-совместимых контроллеров периферии приводится в совместно рассматриваемой заявке №10/246367 США, включенной в данное изобретение ранее.

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

После установления 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. Кроме того, каждая игра может иметь свой собственный каталог в файловой структуре энергонезависимой памяти, чтобы обеспечить при необходимости возможность инсталляции и удаления каждой игры из энергонезависимой памяти.

При начальной загрузке менеджер по играм (см. фиг.1С) или другой процесс в игровой операционной системе может выполнять итерации через игровые каталоги на жестком диске 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/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-стек, рассмотренный при описании фиг.1С.

На самом высоком уровне драйвер 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-реализацией. В одном примере осуществления каждая настройка может иметь свой собственный интерфейс. Отображение настроек в интерфейсах типа каждой настройки, имеющей свой собственный интерфейс, может быть задано как часть описания протокола класса устройств конкретной фирмы-поставщика.

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

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

КЛАССЫ УСТРОЙСТВ КОНКРЕТНЫХ ФИРМ-ПОСТАВЩИКОВ ДЛЯ ИГРОВЫХ СРЕД

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

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

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

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

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

В настоящем изобретении протокол класса устройств IGT может содержать как команды и запросы, которые могут быть направлены в игровую периферию в целом, так и подмножество сообщений, которые являются специфическими для объявленной настройки (настроек). Таким образом, класс устройств IGT может включать в себя два элемента:

- базовый протокол, который управляет сообщениями об общем устройстве и общей инфраструктурой связи между игровой машиной и игровой периферией;

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

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

На фиг.9 представлена блок-схема демонстрирующая три комплекта игровой USB-периферии, физически подключенные к игровой машине. Эти три комплекта игровой USB-периферии, периферийное устройство 901 для бонусных игр, периферийное устройство 905 для вывода денег и периферийное устройство 908 для ввода денег - каждое подключено посредством USB-подключения 818 (т.е. кабеля с USB-совместимыми вилками и USB-совместимыми розетками) к хост-контроллеру 814. Настоящее изобретение не ограничено тремя комплектами игровой USB-периферии, приведенными в иллюстративных целях, и возможна нумерация большего числа комплектов игровой USB-периферии. Как указывается при описании фиг.8, периферийные устройства 901, 905 и 908 могут быть логически абстрагированы как группы интерфейсов и настроек. На фиг.9 периферийное устройство для бонусных игр абстрагировано как три настройки: настройка 902 барабана, настройка 903 источников света и настройка 904 счетчика. Периферийное устройство 905 для вывода денег абстрагировано как две настройки: настройка 906 накопителя и настройка 907 принтера. Периферийное устройство 908 для вывода денег абстрагировано как две настройки: настройка 909 банкнотоприемника и настройка 910 монетоприемника.

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

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

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

- Хосту может потребоваться поддержание непрерывной постоянной связи с периферией. Периферия может прекратить все действия, исполняемые в текущий момент, и сбросить все настройки в известные состояния в случае отсутствия сообщения по каналу управления в заданный интервал времени. Более подробно канал управления описывается при рассмотрении фиг.11.

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

- Шифрование данных в сообщениях между игровой машиной и периферийным устройством может быть использовано для обеспечения безопасности уязвимых данных (см. рис.5).

- Комплектам игровой периферии может потребоваться постоянное обновление их статуса в игровой машине и ожидание коррекции ошибок перед инициированием дальнейшего действия.

- Комплекты игровой периферии могут назначать мероприятия по самодиагностике под управлением игровой машины.

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

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

На фиг.10 представлена блок-схема, демонстрирующая логическую связь между менеджером 75 классов USB-устройств и игровой периферией 900. На фигуре менеджер 75 классов USB-устройств имеет три загруженных драйвера: 1) драйвер 940 настройки "0", 2) драйвер 911 настройки "1" и 3) драйвер 912 настройки "2" для управления настройками игровой периферии 900. Драйвер 940 подключен к интерфейсу "0" 916. Через подключение 913 может осуществляться пересылка сообщений об общем устройстве между менеджером 75 классов USB-устройств и каждой из настроек в игровой периферии 900. Через подключение 914 может осуществляться пересылка сообщений о настройке колеса между драйвером 911 и интерфейсом 917. Сообщения могут касаться работы колеса в игровой периферии 900. Через подключение 918 может осуществляться пересылка сообщений о настройке источников света между драйвером 912 и интерфейсом 918. Сообщения могут касаться работы источников света в игровой периферии 900. Маршрут связи между менеджером 75 классов устройств и игровой периферией 900 иллюстрирует далее фиг.11.

На фиг.11 представлена блок-схема, демонстрирующая подключения между менеджером 75 классов USB-устройств и игровой периферией 900 в оконечных точках. В USB транзакции по шине включают в себя передачу до трех пакетов. Каждая транзакция может начаться, когда хост-контроллер (см. фиг.8 и 9) в соответствии с расписанием пересылает USB-пакет, описывающий тип и направление транзакции, адрес USB-устройства и номер оконечной точки. Этот пакет называется "маркерным пакетом". Адресуемое USB-устройство выбирается путем декодирования соответствующих адресных полей. В данной транзакции данные передаются или с хоста в устройство, или из устройства на хост. Направление передачи данных задается в маркерном пакете. Затем источник транзакции пересылает пакет данных или указывает об отсутствии данных для передачи. Адресат обычно отвечает пакетом подтверждения, указывающим на успешную или неуспешную передачу. "Пакет с запросом на ввод/вывод" представляет собой идентифицируемый программным клиентом запрос на перемещение данных между собой (на хосте) и оконечной точкой устройства в соответствующем направлении.

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

Адрес оконечной точки представляет собой комбинацию номера оконечной точки и направления оконечной точки в USB-устройстве. Каждый адрес оконечной точки поддерживает передачу данных в одном направлении. Направление оконечной точки является направлением передачи данных по USB. Направление может быть или IN или OUT. IN относится к передачам на хост, a OUT - к передачам с хоста. Номер оконечной точки - это четырехбитовая величина в диапазоне значений между ОН и FH включительно, ассоциированная с оконечной точкой в USB-устройстве.

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

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

Как показано на фиг.11, драйвер 940 подключен к оконечной точке прерываний для настройки 920. Оконечная точка 940 прерываний обеспечивает передачи прерываний от настройки 940. Передача прерываний - один из четырех типов передачи по USB. В общем случае характеристиками передачи прерывания - небольшой объем данных, непериодичность, низкая частота и ограничение по времени ожидания. Передачи прерываний обычно используются для обработки потребностей сервиса. Через оконечную точку 923 управления драйвер 940 настройки подключен к настройке 920 921 и 922. Через оконечную точку 925 управления драйвер 911 настройки подключен к настройке 921, которая обеспечивает функциональные возможности колеса в игровой периферии 900. Через оконечную точку 926 управления драйвер 912 настройки подключен к настройке 922, которая обеспечивает функциональные возможности источников света в игровой периферии 900.

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

На фиг.12 представлена блок-схема, демонстрирующая подключения интерфейсов между менеджером 75 классов USB-устройств и игровой периферией 900 во время определения класса устройств. В настоящем изобретении предлагается способ, который позволяет хосту однозначно идентифицировать класс, поддерживаемый периферийным устройством, типа класса устройств IGT при обеспечении сохранения кодов идентичности продукта и фирмы-поставщика для периферийного устройства. Идентичность класса устройств конкретной фирмы-поставщика (например, класс устройств IGT) может быть определена путем использования строковых идентификаторов вместо общей практики использования кодов фирмы-поставщика при фирме-изготовителе и продуктов. Эта уникальная методология позволяет нескольким фирмам-изготовителям использовать класс устройств одной и той же конкретной фирмы-поставщика при сохранении своего собственного обозначения фирмы-поставщика. Например, индекс в специфической строке типа "©IGT2003" может быть размещен в поле iInterface дескриптора интерфейса для уникальной идентификации класса устройств конкретной фирмы-поставщика, указываемого как таковой полем bInterfaceClass. В USB предусмотрены различные наборы дескрипторов, которые позволяет хосту "узнавать" об игровой периферии во время процесса нумерации. Дополнительное описание наборов дескрипторов приводится в следующих абзацах. Поля bDeviceClass и bDeviceSubClass дескриптора устройства могут быть установлены на нуль, чтобы обозначить, что каждый интерфейс определяет свой собственный класс. Кроме того, этот пример указывает на то, что поля idVendor и idProduct дескриптора устройства, как правило, используемые для определения идентичности класса устройств конкретной фирмы-поставщика, не обязательно используются как таковые для определенных периферийных устройств.

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

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

Фиг.12 иллюстрирует пример, в котором менеджер 75 классов USB-устройств определяет класс трех периферийных устройств в игровой периферии 900. Как было указано ранее, интерфейс 0 может быть зарезервирован для общих команд в классе устройств IGT. Игровая периферия 900 объявляет три интерфейса 930 931 и 932 через подключения 936 937 и 938 интерфейсов к менеджеру 75 классов USB-устройств. С помощью информации, предоставленной в наборе дескрипторов интерфейсов, менеджер 75 классов USB-устройств определяет, что интерфейс 1 и интерфейс 2 подключены к настройкам, совместимым с классом устройств конкретной фирмы-поставщика типа класса устройств IGT. В ответ менеджер 75 классов USB-устройств может инициализировать загрузку драйверов настройки 933 и 934.

Для интерфейса 3 менеджер классов USB-устройств определяет, что интерфейс 3 подключен к настройке, которая является совместимой с классом стандартных устройств. В ответ менеджер классов USB-устройств загружает драйвер классов стандартных устройств. Например, если настройка для интерфейса 3 находится в стандарте HID (устройства интерфейса с пользователем), то менеджер классов USB-устройств загружает драйвер, который является совместимым с классом HID. Точно также, если настройка интерфейса 3 находится в классе стандартных звуковых устройств или принтеров, то менеджер классов USB-устройств загружает драйвер, совместимый с классами стандартных устройств.

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

Функциональные характеристики класса устройств IGT

Настройки

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

Интерфейсы

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

Оконечные точки

Хост обычно вырабатывает запросы IN и OUT в оконечных точках управления. Запросы на информацию, которые требуют нетривиальной обработки (например, вычисления CRC), могут использовать для ответа общую оконечную точку прерывания IN. Сообщения, которые инициируют настройки, могут использовать одну и ту же оконечную точку прерывания IN. Специфические настройки могут использовать дополнительные выделенные оконечные точки.

ACK, NAK, STALL и отклонение сообщения

Для сообщения, содержащего ряд пакетов данных, устройство может подтверждать прием (ACK) каждого пакет данных. После приема последнего пакета данных оно может прекратить подтверждение приема (NAK) во время стадии статуса при оценке сообщения. Оценка сообщения позволяет контролировать недействительные сообщения. В случае если тип запроса, номер интерфейса, код функции или любое другое поле является недействительным, устройство может отклонить сообщение и переслать символ STALL (останов). Оно может не подтверждать приема (NAK) оконечной точки управления пока не перешлет "Сообщение отклонено" в оконечной точке прерываний. Если сообщение является недействительным, то устройство может осуществить пересылку символа ACK.

Copyright ©2003 IGT. Все права защищены.

Таймауты

Устройство может объявить таймаут при отсутствии опросного сообщения в оконечной точке прерываний по истечении заданного времени. Оно может также объявить таймаут в случае отсутствия сообщения в оконечной точке управления через некоторое время или если обнаруживает разъединение кабеля USB. При объявлении таймаута устройство может 1) прекратить все действия, исполняемые в текущий момент, 2) вызвать конфликтную ситуацию со всеми настройками и 3) принять необходимые меры (например, замедлить вращение барабанов) для предотвращения возможных претензий. Оно может также отвергнуть отклоненные сообщения любого подвешенного сообщения и остановить сообщения NAK в оконечной точке управления. Хост может осуществить пересылку запроса "Получить статус" для настройки 0, в случае если устройство ничего больше не перешлет в течение заданного времени, чтобы избежать таймаута.

Сбросы USB и отключение DFU

Сброс USB обычно побуждает устройство к проведению повторной нумерации без отмены обслуживания настроек. Отключение DFU, сопровождаемое сбросом USB, может перевести устройство, которое поддерживает DFU, в режим DFU.

Статусы

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

Эти статусы могут применяться ко всем настройкам:

Статус	Содержание
Величина #1	Нормальный статус (отсутствие конфликтной ситуации или самотестирование).
Величина #2	Проведение самотестирования.
Величина #3	Конфликтная ситуация с настройкой вследствие таймаута связи.

Статусы заданных настроек для настройки 0 могут быть следующими:

Статус	Содержание
Величина #1	Аппаратная ошибка в RAM для данных.
Величина #2	Аппаратная ошибка в памяти для кодов.
Величина #3	Аппаратная ошибка в СППЗУ на I2С.
Величина #4	Программная ошибка CRC (во время начальной загрузки).
Величина #5	Программная ошибка CRC (в период, отличный от времени начальной загрузки).

Copyright© 2003 IGT. Все права защищены.

ЗАПРОСЫ КЛАССОВ УСТРОЙСТВ IGT

Управление сообщениями OUT

Команда

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

Сообщения Control IN

Команда: запрос интерфейса

Код запроса	Описание
Получить статус	Создает записи о статусе.
Специфическая настройка	Создает данные по заданной настройке.

Сообщения Interrupt IN

Отклонение сообщений

Это сообщение информирует хост о том, что устройство отклонило последнее сообщение о классе IGT, которое оно приняло в оконечной точке управления.

Поле	Описание
Тип отчета	Идентифицирует сообщение "Сообщение отклонено".
Номер интерфейса	Номер интерфейса.
Причина отклонения	См. ниже.
Данные	Дополнительные данные по заданной настройке (по выбору).

Copyright© 2003 IGT.

Все права защищены.

Причины отклонения:

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

Статус

Настройка пересылает этого сообщение при каждом изменении статуса.

Поле	Описание
Тип отчета	Идентифицирует сообщение о статусе.
Номер интерфейса	Номер интерфейса.
Данные	Одна или более записей о статусе.

Отчет о RCR

Настройка 0 пересылает это сообщение, когда заканчивает расчет кодов CRC.

Поле	Описание
Тип отчета	Идентифицирует отчет о CRC.
CRC	Коды CRC в отчете соответствуют именам файлов в строке дескриптора конфигурации.

Copyright© 2003 IGT. Все права защищены.

ДЕСКРИПТОРЫ КЛАССА УСТРОЙСТВ IGT

Дескриптор устройства

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

Поле	Описание
bLength	Длина этого дескриптора.
bDescriptorType	Тип дескриптора устройства.
bcdUSB	Номер версии спецификации USB.
bDeviceClass	Каждый интерфейс задает свой собственный класс.
bDeviceSubClass	Задается равным 0, когда bDeviceClass имеет значение 0.
bDeviceProtocol	Каждый интерфейс задает свой собственный протокол.
bMaxPacketSize0	В зависимости от реализации может иметь значения 8, 16, 32 и 64. (Максимальный размер пакета для оконечной точки равен 0.)
idVendor	Идентификатор фирмы-поставщика, присвоенный фирме-изготовителю.
idProduct	Идентификатор продукта фирмы-изготовителя. Каждый выпускаемый продукт использует следующий доступный номер.
bcdDevice	Версия аппаратно-программного обеспечения устройства.
iManufacturer	Индекс строкового дескриптора, описывающего фирму-изготовителя.
iProduct	Индекс строкового дескриптора, описывающего этот продукт.
iSerialNumber	Индекс строкового дескриптора, содержащего регистрационный номер, модификация платы или аналогичная информация, определяемая аппаратно-программным обеспечением из аппаратного обеспечения.
bNumberConfiguration	Число возможных конфигураций. Устройства IGT могут иметь одну конфигурацию.

Дескриптор конфигурации

Может быть один дескриптор конфигурации.

Поле	Описание
bLength	Длина этого дескриптора.
bDescriptorType	Тип дескриптора конфигурации
wTotalLength	Число байтов в конфигурации. Включает дескриптор конфигурации и все дескрипторы интерфейсов, оконечных точек, функциональные и настроек.
bNumInterface	Число интерфейсов для этой конфигурации - минимальное, равно двум.
bConfigurationValue	Значение, используемое в запросе SETCONFIGURATION для выбора этой конфигурации.
iConfiguration	Индекс дескриптора строки, описывающего эту конфигурацию.
bmAttributes	Характеристики конфигурации:
	Побитовое описание
	7	Зарезервирован равным 1
	6	Автономный источник питания
	5	Удаленная активизация
	4-0	Зарезервированы равными 0
bMaxPower	Максимальная потребляемая мощность этой конфигурации. Выражается в единицах по 2 мА (например, 50=100 мА)

Copyright© 2003 IGT. Все права защищены.

Дескриптор строки конфигурации может содержать одно или более имен файлов, каждое со своей датой файла.

Формат имени файла и дата

Поле	Описание
Имя файла	Кодирование в UNICODE. Имена файлов состоят из имени (до восьми символов), периода и трехбитового расширения. Если имя файла использует менее 12 символов, добавляются пробелы за расширением файла для доведения его до 12 символов.
Дата файла	Кодирование в UNICODE. Формат даты имеет выражение yyyy-mm-dd.

Дескриптор интерфейсов

Класс устройств IGT может поддерживать по меньшей мере два интерфейса: общий интерфейс, определяемый как настройка 0, и по меньшей мере один интерфейс настройки. Протоколы для заданных настроек могут описывать дополнительные интерфейсы.

Имеется дескриптор интерфейса для каждого интерфейса. Строка iInterface может быть использована для того, чтобы установить, что интерфейс является настройкой класса устройств IGT. Дескриптор может также обеспечивать номер интерфейса для настройки.

Поле	Описание
bLength	Длина этого дескриптора.
bDesriptorType	Тип дескриптора интерфейса.
bInterfaceNumber	Величина, идентифицирующая номер этого интерфейса, с отсчетом от нуля.
bAlternateSetting	Величина, используемая для выбора альтернативного интерфейса.
bNumEndpoints	Число оконечных точек в этом интерфейсе без учета оконечной точки по умолчанию.
bInterfaceClass	Класс интерфейса является классом устройств конкретной фирмы поставщика.
bInterfaceSubClass	Доступен для будущего использования.
bInterfaceProtocol	Доступен для будущего использования.
iInterface	Индекс строки, описывающей этот интерфейс. Первые восемь символов строки могут представлять собой "© IGT", a последующие четыре цифры - год"2003" авторского права. Эти символы идентифицируют класс устройств конкретно фирмы-поставщика как IGT. Могут быть использованы и другие форматы идентификации.

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

Поля дескриптора интерфейса для заданной настройки 0 могут быть следующими:

Поле	Описание
bNumEndpoints	Число оконечных точек в этом интерфейсе без учета оконечной точки по умолчанию.
iInterface	Индекс строки "© IGT2003".

Copyright© 2003 IGT. Все права защищены.

Дескриптор оконечной точки настройки 0

Эта таблица описывает дескриптор оконечной точки для оконечной точки IN настройки 0:

Поле	Описание
bLength	Длина этого дескриптора.
dDescriptorType	Тип дескриптора оконечной точки.
bmEndpointAddress	Адрес этой оконечной точки в USB-устройстве. Этот адрес является номером оконечной точки в диапазоне от 1 до 15.
	Бит 7=1 (оконечная точка IN)
	Биты 6-7 Зарезервированы равными 0
	Биты 3-0 номер оконечной точки
mAttributes	Это - оконечная точки прерываний.
wMaxPacketSize	Максимальный объем передаваемых данных может составлять 8, 16, 32 или 64 байта.
bInterval	Интервал для оконечной точки опроса для передачи данных.

Функциональный дескриптор и дескриптор настройки

Каждый интерфейс может иметь один функциональный дескриптор. Каждый функциональный дескриптор описывает один или более дескрипторов настроек. Каждый дескриптор настройки может обеспечивать информацию о заданном интерфейсе.

Формат функционального дескриптора

Поле	Описание
bLength	Размер этого дескриптора. Имеет значение bNumDescriptor * 2+9
bDescriptorType	Идентификатор для функционального дескриптора.
bcdVersion	Версия протокола IGT. Представляет собой версию соответствующего документа спецификации настройки.
wFeatureNumber	Номер настройки, назначенный IGT.
wSubFeature	Это число варьируется для различных устройств, которые могут поддерживать конкретную настройку. Например, игровые барабаны, бонусные барабаны и кости могут иметь различные значения wSubFeature при настройке барабанов. Каждый документ настройки задает значения для этой настройки. Ни в каких двух случаях одна и та же настройка в данном устройстве не может иметь одно и то же значение wSubFeature.
bNumDescriptors	Число дескрипторов настроек. Это поле равно 0 в случае отсутствия дескрипторов настроек.
bDescriptorLength (по выбору)	Размер дескриптора настройки.
bDescriptorType (по выбору)	Тип дескриптора настройки.

Copyright© 2003 IGT. Все права защищены.

Поля функционального дескриптора для настройки 0 могут быть следующими:

Поле	Описание
bLength	Размер дескриптора.
bDescriptorType	Идентификатор для функционального дескриптора.
bcdVersion	Версия протокола IGT. Это версия этого документа.
wFeatureNumber	Номер настройки, назначенный IGT.
wSubFeature	Может быть одна настройка 0.
bNumDescriptors	Дескрипторы настройки отсутствуют.

Общепринятый формат дескриптора настроек

Поле	Описание
bLength	Размер этого дескриптора. Совпадает с длиной, заданной в функциональном дескрипторе для этого дескриптора.
bDescriptorType	Совпадает с одним из типов дескрипторов в функциональном дескрипторе.
Данные по заданной настройке	Определены в документах настройки.

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

НАСТРОЙКА БАРАБАНА КЛАССА УСТРОЙСТВ IGT

Командное сообщение (Control Out)

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

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

В остальном, значения конфигурации остаются неизменными.

Функций барабана:

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

Copyright© 2003 IGT. Все права защищены.

Код функции	Описание Copyright© 2003 IGT. Все права защищены.
Задание значений по умолчанию	Задание всех характеристик для определенного барабана по умолчанию.
Задание ускорения	Выбор профиля ускорения для определенного барабана, обеспечивающего ускорение барабана из положения останова до конечной скорости в угловых градусах. Угол 0 может быть использован для задания профиля по умолчанию.
Задание замедления	Выбор профиля замедления для определенного барабана, обеспечивающего замедление барабана до останова в угловых градусах. Угол 0 может быть использован для задания профиля по умолчанию.
Задание скорости	Задание скорости определенного барабана в оборотах в минуту. Скорость 0 может быть использована для задания скорости по умолчанию.
Задание продолжительности	Задание полной продолжительности вращения (ускорение + постоянная скорость + замедление) для определенного барабана по возможности с наибольшим приближением ко времени в миллисекундах.
Задание направления	Задание направления вращения определенного барабана. Направление 0 означает, что настройка выбирает наиболее короткий путь до останова. Направление 1 означает, положения останова проходят через фиксированную точку на этапе ускорения. Направление 2 означает, положения останова проходят через фиксированную точку на этапе замедления.
Задание остановки	Задание желаемого положения останова для определенного барабана. Положения останова барабана могут варьироваться в диапазоне от 0 до числа, равного числу остановок минус 1.
Задание атрибута	Задание специального атрибута вращения для определенного барабана. Автоматическая очистка ранее выбранных атрибутов, конфликтующих с новым атрибутом.
	0	Вздрагивание барабана перед началом вращения.
	1	Биение барабана при останове.
	2	Вибрация барабана.
Очистка атрибута	Очистка специального атрибута вращения для определенного барабана
Вращение	Вращение определенного барабана обеспечивается использованием текущих значений конфигурации. Обычно барабан ускоряется из положения останова, вращается с постоянной скоростью и затем замедляется до останова. Если барабан уже вращается, то ускоряется или замедляется до новой скорости и использует вновь заданные установки. Останавливается или изменяет направление в случае необходимости. Настройка может игнорировать эту команду, если он уже замедляется до останова.
Останов	По возможности быстрый останов определенного барабана с использованием заданных установок конфигурации. Это позволяет сократить время вращения определенного барабана или задать останов в произвольный момент времени вращения. Это не позволяет изменить ранее заданное положение останова.
Медленное вращение	Эта команда допускается в конфликтной ситуации. Прекращение всех действий, исполняемых определенным барабаном, и "медленное вращение" этого барабана. В процессе медленного вращения игнорируются все характеристики вращения, за исключением направления вращения. Настройка отчитывается за конфликтные ситуации в процессе медленного вращения, но барабан продолжает вращение. Вращение барабана продолжается до того момента, когда настройка получит команду останова или приостановки. Цель медленного вращения заключается в предотвращении предъявления претензии со стороны игрока, которое может иметь место в случае останова барабана в выигрышной позиции во время конфликтной ситуации. Однако некоторые барабаны могут перегреваться при бесконечном вращении, и это может позволить остановить барабан в известной проигрышной позиции или скрыть положение барабана от взгляда игрока. Термин "медленное вращение" включает в себя любую настройку, позволяющую предотвратить предъявление претензии. Настройка отчитывается о своем статусе как медленном вращении только в случае продолжения движения. В одном примере осуществления при вращении барабана и по истечении определенного времени без USB-связи барабан автоматически переводится в конфликтное состояние и замедляет вращение.
Приостановка	Эта команда допускается во время конфликтной ситуации. Настройка обеспечивает по возможности скорый останов определенного барабана в разрешенном положении. В случае проблемы с аппаратным обеспечением или слишком длительного замедления барабана до останова в разрешенном положении настройка может остановить барабан "немедленно" независимо от его положения.
Задание ориентации барабана	В различных конфигурациях корпуса допускаются различные схема монтажа барабанов. Для предоставления игроку возможности наблюдать желаемые результаты может возникнуть необходимость в изменении направления вращения барабана в настройке на обратное или может потребоваться регулировка положений останова. Эта команда информирует настройку об использовании нестандартной ориентации.
Самотестирование	Тестирование всех барабанов.
Конфликтная ситуация	Останов всех действий, исполняемых определенным барабаном. За исключением медленного вращения. Медленно вращающийся барабан продолжает медленное вращение.
Сброс	Сброс всех барабанов.

СООБЩЕНИЯ

Сообщение с запросом (Control In)

В этом примере осуществления настройка барабанов поддерживает код запроса на получение статуса.

Сообщение об отклонении сообщений (Interrupt In)

В этом примере осуществления причины для отклонения сообщений о заданной настройке.

Сообщение о статусе (Interrupt In)

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

Статус	Содержание
Величина #1	Барабан А простаивает в положении В останова.
Величина #2	Барабан А простаивает (в неизвестном положении останова).
Величина #3	Барабан А ускоряется из положения останова.
Величина #4	Барабан А замедляется в положение останова.
Величина #5	Барабан А вращается с постоянной скоростью.
Величина #6	Барабан А совершает медленное вращение.
Величина #7	Барабан А совершает движение, не рассмотренное выше (например, с изменением скорости или с вибрацией).
Величина #8	Последняя команда останова для барабана А задала положение останова, являющееся положением останова по умолчанию или отличающееся от ранее запрошенного. Настройка игнорирует команду.
Величина #9	Игра пересылает команду на конфликтную ситуацию в барабан А.
Величина #10	Барабан А движется, когда должен находиться в неподвижном состоянии.
Величина #11	Барабан А остановлен, когда должен двигаться.
Величина #12	Барабан А не может найти запрошенного положения останова.
Величина #13	Барабан А имеет ошибки, обусловленные нарушением оптической последовательности во время замедления для останова в запрошенном положении. Барабан не движется и не может находиться в запрошенном положении останова.
Величина #14	Барабан А отключен. Copyright© 2003 IGT. Все права защищены.

ДЕСКРИПТОРЫ

Дескриптор интерфейсов

Поля дескриптора интерфейса для заданной настройки могут быть следующими:

Поле	Описание
bNumEndpoints	Число оконечных точек в этом интерфейсе без учета оконечной точки по умолчанию.
iInterface	Индекс строки с перечислением поддерживаемых игры(ы). Первые восемь символов строки могут быть "© IGT2003".

ФУНКЦИОНАЛЬНЫЙ ДЕСКРИПТОР

Функциональный дескриптор имеет поля:

Поле	Описание
bLength	Размер этого дескриптора.
bDescriptorType	Идентификатор для функционального дескриптора.
bcdVersion	BCD - версия этого документа.
wFeatureNumber	Номер настройки для барабанов.
wSubFeature	0 = Играющие барабаны
	1 = Бонусные барабаны.
	2 = Бонусные кости.
	3 = Бонусное колесо (например, колесо фортуны).
bNumDescriptors	Число дескрипторов настроек указывается ниже.
bDescriptorLength	Размер дескриптора настроек. Число барабанов * bReelConfigLength + 3.
bDescriptorType	Тип дескриптора настроек.

Дескриптор настроек

В одном примере осуществления дескриптор конфигурации настроек может быть только дескриптором настроек.

Поле	Описание
bLength	Размер дескриптора настроек. Число барабанов* bReelConfigLength + 3.
bDescriptorType	Тип дескриптора настроек.
bReelConfigLength	Длина конфигурации барабанов. Возрастание этой величины позволяет добавлять новые поля к конфигурации барабанов.
Конфигурация барабанов	Одна конфигурация для каждого барабана. Первый барабан - барабан 0, второй барабан - барабан 1 и т.д.

Конфигурация барабанов имеет поля:

Поле	Описание
bStops	Число остановок для этого барабана. (Это фактическое число остановок, поддерживаемых аппаратным обеспечением. Это необязательно число символов на барабанной полосе.)
bTimeout	Максимальное время, в течение которого барабан ускоряется, находит желаемую позицию на барабанной ленте и затем замедляется до останова без дополнительных оборотов.
	Copyright© 2003 IGT. Все права защищены.

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

Другие преимущества протокола класса устройств IGT и совместимого расширения для настроек в игровой среде могут заключаться в следующем:

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

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

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

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

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

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

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

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

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

На фиг.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-связи.

Claims (69)

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

2. Игровая машина по п.1, отличающаяся тем, что передача USB-класса первого USB-совместимого периферийного устройства осуществляется с использованием идентификационной информации о классе.

3. Игровая машина по п.2, отличающаяся тем, что идентификационная информация о классе хранится в одном или более строковых идентификаторах.

4. Игровая машина по п.2, отличающаяся тем, что идентификационная информация о классе передается в один или более хост-процессов в наборе дескрипторов USB-интерфейса.

5. Игровая машина по п.4, отличающаяся тем, что идентификационная информация о классе передается в поле iInterface набора дескрипторов USB-интерфейса.

6. Игровая машина по п.5, отличающаяся тем, что поле iInterface определяет индекс к дескриптору строки.

7. Игровая машина по п.2, отличающаяся тем, что протокол классов USB-устройств конкретной фирмы-поставщика задает формат и информацию в идентификационной информации о классе.

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

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

10. Игровая машина по п.9, отличающаяся тем, что одна из USB-настроек спроектирована для обработки команд и сообщений, являющихся общими для всех USB-настроек.

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

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

13. Игровая машина по п.9, отличающаяся тем, что каждой из USB-настроек присваивается уникальный номер настройки.

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

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

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

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

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

19. Игровая машина по п.18, отличающаяся тем, что запрос на проверку CRC содержит начальный адрес в аппаратно-программном обеспечении и/или конечный адрес в аппаратно-программном обеспечении.

20. Игровая машина по п.19, отличающаяся тем, что начальный адрес и/или конечный адрес генерируются ведущим игровым контроллером случайным образом.

21. Игровая машина по п.18, отличающаяся тем, что контрольное значение CRC, возвращаемое в ответ на запрос на CRC, используется для аутентификации периферийного устройства.

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

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

24. Игровая машина по п.1, отличающаяся тем, что команда отклоняется в случаях: 1) недействительного типа запроса, 2) недействительного запроса, 3) недействительного номера интерфейса, 4) несовпадения длины, 5) неизвестной команды, 6) недействительных данных, 7) слишком длинного сообщения, 8) занятости USB-настройки, адресуемой в команде, 9) конфликтной ситуации с адресуемой USB-настройкой и/или 10) самотестирования USB-настройки.

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

26. Игровая машина по п.1, отличающаяся тем, что комплекты игровой USB-периферии выполнены с возможностью пересылки следующих сообщений о статусе в ведущий игровой контроллер: 1) об аппаратной неисправности RAM для данных, 2) об аппаратной неисправности памяти для кодов, 3) об аппаратной неисправности I²С, 4) о программной ошибке CRC во время инициализации и/или 5) о программной ошибке CRC вне времени инициализации.

27. Игровая машина по п.1, отличающаяся тем, что комплекты игровой USB-периферии выполнены с возможностью очистки статуса.

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

29. Игровая машина по п.28, отличающаяся тем, что каждое расширение протокола для специфической настройки определяет сообщения о специфической настройке.

30. Игровая машина по п.29, отличающаяся тем, что при модифицировании одного из сообщений о специфической настройке базовый протокол не меняется.

31. Игровая машина по п.28, отличающаяся тем, что базовый протокол определяет, что каждая USB-настройка отображается в одном интерфейсе USB.

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

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

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

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

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

37. Игровая машина по п.1, отличающаяся тем, что по меньшей мере один из комплектов игровой USB-периферии включает в свой состав DFU-совместимое периферийное USB-устройство.

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

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

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

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

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

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

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

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

46. Игровая машина по п.1, отличающаяся тем, что дополнительно содержит базу данных аппаратно-программного обеспечения.

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

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

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

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

51. Игровая машина по п.1, отличающаяся тем, что выполнена с возможностью определения игровой юрисдикции, на территории которой она локализована.

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

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

54. Игровая машина по п.1, отличающаяся тем, что дополнительно содержит USB-совместимый хост-контроллер.

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

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

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

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

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

60. Игровая машина по п.59, отличающаяся тем, что контроллер USB-периферии включает в свой состав энергонезависимую память, предназначенную для хранения а) параметров конфигурации, специфических для отдельного комплекта игровой USB-периферии и/или b) хронологической информации о состояниях игровой USB-периферии.

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

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

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

64. Игровая машина по п.1, отличающаяся тем, что дополнительно содержит запоминающее устройство для хранения множества игровых программных модулей.

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

66. Игровая машина по п.1, отличающаяся тем, что первое USB-совместимое периферийное устройство адаптировано для перехода в конфликтное состояние в случае отсутствия сообщения из ведущего игрового контроллера в пределах заданного периода времени.

67. Игровая машина по п.1, отличающаяся тем, что дополнительно содержит: второе USB-совместимое периферийное устройство; и третье USB-совместимое периферийное устройство с аппаратной конфигурацией, отличной от второго USB-совместимого периферийного устройства, причем второе USB-совместимое периферийное устройство и третье USB-совместимое периферийное устройство - оба поддерживают протокол с расширением для первой специфической настройки.

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

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

Images