PatentDe  


Dokumentenidentifikation DE69522256T2 13.06.2002
EP-Veröffentlichungsnummer 0681297
Titel Speichermodulprogrammiersystem für Spielprogramme
Anmelder International Business Machines Corp., Armonk, N.Y., US
Erfinder Dorak, John, Boca Raton, Florida, 33428, US;
Cook, Ross L., Boynton Beach, Florida, 33435, US;
Gruse, George G., Lighthouse Point, Florida, 33064, US;
Nguyen, Minhtam, Boca Raton, Florida, 33428, US;
Tsevdos, James T., Fort Lauderdale, Florida, 33308, US;
Waefler, Susan Elizabeth, Delray Beach, Florida, 33484, US
Vertreter Teufel, F., Dipl.-Phys., Pat.-Anw., 70569 Stuttgart
DE-Aktenzeichen 69522256
Vertragsstaaten DE, FR, GB, IT
Sprache des Dokument EN
EP-Anmeldetag 01.05.1995
EP-Aktenzeichen 953029584
EP-Offenlegungsdatum 08.11.1995
EP date of grant 22.08.2001
Veröffentlichungstag im Patentblatt 13.06.2002
IPC-Hauptklasse G11C 16/06
IPC-Nebenklasse A63F 9/24   

Beschreibung[de]

Die vorliegende Erfindung bezieht sich im allgemeinen auf das Gebiet Video- und Audio-Datenspeicherung und gesteuerte Informationserstellung und im besonderen auf ein Produktionssystem für den Zugriff auf Informationen, z. B. Audio- und Video-Daten an lokalen und entfernten Speicherstellen, sowie für die Übertragung dieser Informationen an einen Endpunkt in Echtzeit, wobei Nachprüfbarkeit und Dateisicherheit zur Reproduktion der übertragenen Informationen in einem materiellen Objekt für die Verwendung durch den Endbenutzer Voraussetzungen sind.

Allein in den Vereinigten Staaten gibt es mittlerweile über 50 Millionen Benutzer von Videospielen. Die Vermietung und der Einzelhandel von Speichermodulprogrammiersystemen für Spielprogramme bilden einen großen Markt angesichts einer Zunahme neuer Spiele auf über 2.000 Titel und einer ständigen Preissteigerung. Verbraucherstudien haben gezeigt, dass eine der größten Unzufriedenheitsquellen unter Spielemietern und -käufern darin liegt, dass es schwierig ist, sich im reichhaltigen Angebot zurecht zu finden. Für Spielehändler ist es schwer, die Nachfrage nach Videospielen vorherzusagen, da es normalerweise keine Bestandsaufzeichnungen gibt, die hierfür als Grundlage dienen könnten. Die Beliebtheit eines Spiels kommt häufig durch eine informelle Mund-zu-Mund- Propaganda unter den Spielern zustande. Darüber hinaus ist die Zeit, die für ein Spiel zur Verfügung steht, um seine Beliebtheit zu erlangen, sehr kurz. Ein Händler, der Speichermodulprogrammiersysteme für Spielprogramme in ausreichender Anzahl einkauft, um eine Spitzennachfrage zu decken, kann auf unverkauften Modulen "sitzenbleiben", wenn die Nachfrage nachläßt. Das umgekehrte Problem tritt ein, wenn ein Händler nicht genügend Module eingekauft hat, um die Nachfrage zu decken. In diesem Fall müssen weitere Module beim Hersteller nachbestellt werden. Dieser Vorgang kann zu Einbußen führen, wenn die Lieferzeiten sehr lang sind, da die Module, die maskenprogrammierbaren Nur-Lese-Speicher (MPROM) enthalten, normalerweise nur in beschränkten Stückzahlen (häufig in Übersee) produziert werden, was für den Händler zu Verzögerungen führt.

Derzeit müssen Händler die Nachfrage des Verbrauchers nach MPROM-gestützten Speichermodulprogrammiersystemen für Spielprogramme im Miet- und Verkaufsgeschäft vorhersagen können. Normalerweise ist eine solche Vorhersage nicht sehr genau, insbesondere, wenn sie sich auf einen neuen Titel bezieht, für den es bisher keine Marktdaten gibt. Die Händler kaufen somit gezwungenermaßen zu viele oder zu wenige Spiele ein, was in Kapitalflußproblemen oder Umsatzeinbußen resultiert, beides Ursachen für Gewinnrückgänge. Wenn die Händler zu viele Module einkaufen, dann haben sie ggf. zum Schluß zu viele Exemplare übrig, da die Module nicht veränderbar sind. Wenn sie auf der anderen Seite zu wenig Vorrat anlegen, lassen sie sich Miet- und Verkaufsumsätze entgehen, weil sie die Nachfrage der Kunden nicht decken können. Darüber hinaus läßt es die Effizienz bei der Programmierung von MPROM oder Umprogrammierung von EPROM oder EEPROM nicht zu, dass diese Bausteine für unmittelbare Geschäfte sinnvoll eingesetzt werden.

Das Patent EP-A-0 275 510 beispielsweise beschreibt ein Verfahren, mit dem Module mit allgemeinen Programmen beschrieben werden können. Dieses Verfahren besteht aus der Auswahl eines Programms, der Bestimmung seiner Indizes, der Übertragung dieser Indizes an einen Speichercomputer, der Übertragung von Transaktionsdaten und dem Herunterladen des Programms. Das Patent enthält jedoch keinerlei Beschreibung einer Unterbrechung des Herunterladens im Fall einer Störung.

Die vorliegende Erfindung beschreibt ein von einem Personalcomputer gesteuertes Verfahren zur Herstellung eines Videospiels auf einer Kassette, die sich in ein entsprechend kompatibles Videospielgerät einlegen läßt. Das Spiel wird interaktiv mit einem Benutzer gespielt. Das genannte Verfahren umfaßt folgende Schritte: Auswahl eines Videospiels zur Herstellung eines ausgewählten Videospielinhalts entsprechend dem ausgewählten Videospiel auf Kassette; Suche nach Indizes für das ausgewählte Videospiel; Übertragung der gefundenen Indizes entsprechend dem ausgewählten Videospiel zur Herstellung des ausgewählten Videospielinhalts auf Kassette an einen Spielespeicher auf einem Computer - dazu gehören auch die Daten des Spieleinhalts entsprechend dem ausgewählten Videospiel; Übertragung von Transaktionsdaten an den Personalcomputer in Abhängigkeit von der Übertragung der kennzeichnenden Indizes an den Spielespeicher; Herunterladen von Spielkontaktdaten entsprechend den kennzeichnenden Indizes des ausgewählten Videospiels aus dem Spielespeicher in den Speicher der Kassette; und Unterbrechung des Herunterladens der Spielinhaltdaten aus dem Speicher, bevor die Inhaltdaten des ausgewählten Videospiels vollständig in den Speicher der Kassette heruntergeladen wurden, wenn infolge eines Fehlers bei der Übertragung der Transaktionsdaten an den Personalcomputer entsprechend den kennzeichnenden Indizes ein unvorhergesehenes Störereignis eintritt.

In einem ersten Ausführungsbeispiel verwendet das Spielprogrammiersystem wiederbeschreibbare Kassetten, die mit handelsüblichen Spielsystemen (beispielsweise SegaTM und NintendoTM) kompatibel sind, um in der Verkaufsstelle oder Mietstelle Spielkassetten zu erzeugen. Der Mietkunde oder Käufer ist zufrieden, weil das gewünschte Spiel sofort verfügbar ist. Die Händler brauchen nur noch Leerkassetten in genügender Stückzahl bereitzuhalten, um die Kundennachfrage zu befriedigen. Es ist keine Nachfrageprognose für einen Spieletitel mehr notwendig.

Das System besteht aus einer Programmiereinrichtung, die darauf ausgelegt ist, digitale Inhalte aus einem Computerspeicher zu laden, um damit in kürzester Zeit eine wiederbeschreibbare Spielkassette zu programmieren. Die Spielkassette ist so konstruiert, dass sie einen wiederprogrammierbaren Flash-Speicher anstatt der herkömmlichen MPROM-, EPROM- oder EEPROM-Speicher verwendet. Die Kombination aus Flash-Speicher und Programmiereinrichtung ermöglicht es diesem System, eine wiederbeschreibbare Spielkassette in weniger als 30 Sekunden zu programmieren. Somit kann eine Spielkassette auf Anfrage hergestellt werden, was die Zufriedenstellung des Kunden verbessert. Die Händler brauchen nur noch wiederbeschreibbare Spielkassetten mit Flash-Speichern, die mit idealistischeren Eigenschaften ausgestattet sind, vorrätig zu halten.

Die wiederbeschreibbare Spielkassette mit Flash-Speichern enthält außerdem Kennzeichnungshardware, die es dem Programmierer gestattet, anzugeben, dass das Spiel urheberrechtlich geschützt ist und nur von einem bestimmten autorisierten Vertreiber oder Händler vertrieben werden darf. Der Programmierer kann nur die richtig gekennzeichneten Kassetten programmieren, was eine strenge Qualitätskontrolle der Herstellung ermöglicht. Nachdem der Programmierer eine Kassette als verwendungstauglich identifiziert hat, hat der Benutzer die Möglichkeit, die Kassette zu initialisieren und zusätzliche Informationen in den Flash-Speicher einzugeben, beispielsweise die Speicherstelle und den Kassettentyp. Wenn eine Initialisierung nicht erforderlich ist, dann kann der Benutzer den Programmierer anweisen, mit dem Laden von Daten aus dem Speicher auf die Kassette zu beginnen.

Die wiederbeschreibbare Spielkassette mit Flash-Speichern eignet sich besonders gut für das Leihgeschäft, wo ein Spiel auf eine Kassette programmiert und an einen Kunden verliehen werden kann. Bei der Rückgabe kann der Spielinhalt von der Kassette gelöscht werden, und die Kassette steht für erneutes Programmieren mit einem anderen Spiel zur Verfügung, usw. Ebenfalls in Betracht gezogen wird ein Verkaufsszenario, bei dem der Kunde die Möglichkeit hat, seine eigene Kassette mitzubringen, um sie mit einem neuen Spieltitel beschreiben zu lassen. Sobald Flash-Speicher preiswerter wird und in Kassetten integriert werden kann und diese Kassetten zum Verkauf angeboten werden können, ist ein höherer Gewinn zu erwarten, indem auf Anfrage viele Kassetten programmiert und an die Kunden verkauft werden. Bei relativ hohen Preisen für Flash-Speicher ist ein Verkauf em ehesten möglich, indem zunächst an den Kunden eine Leerkassette verkauft wird, die daraufhin gegen eine zusätzliche Gebühr mit dem gewünschten Spielinhalt beschrieben wird. Nach einer bestimmten Zeit hat der Kunde im Normalfall oft genug sein Spiel verwendet und möchte ein anderes Spiel haben. In diesem Fall wird die Kassette zurückgebracht und ein neues Spiel gekauft, ohne jedoch eine neue Leerkassette kaufen zu müssen. Das spart Hardware-Kosten, wenn ein Kunde ein neues Spiel kauft.

Zu den Neuheiten und Vorteilen, die das Spielprogrammiersystem bietet, gehören auf Anfrage das schnelle Programmieren spezieller Kassetten, die verbesserte Zufriedenstellung des Kunden, die Möglichkeit, nur solche Kassetten zu programmieren, die den urheberrechtlichen Schutz berücksichtigen, die Programmierung von Kassetten unterschiedlicher Arten und mit verschiedenen Speicherdichten, die einfache Bereitstellung von Leerkassetten an die Händler, die Tatsache, dass ein bestimmter Spieltitel nie "ausgehen" kann, das Herunterladen neuer Spielinhalte von entfernt gelegenen Server-Standorten, um so eine sofortige Verteilung neuer Spieletitel an die verschiedenen Händler zu gewährleisten, die Fernprogrammierung von Kassetten, bei der eine Spielprogrammiererbox mehrere Meter vom PC entfernt sein kann, die Steuerung mehrerer Spielprogrammiererboxen über einen einzigen PC, um Kosten zu sparen und dem Händler ein neues Instrument zur Auswertung des Spielegeschäfts an die Hand zu geben, beispielsweise die Bestimmung, welche Spiele besonders beliebt sind, die Überwachung der täglichen Transaktionen, die Anzahl der vermieteten Tage, die Bereitstellung einer Bestandsanalyse (die Auflistung von Kassetten nach Typ und/oder Speicherdichte).

Es folgt eine Beschreibung der vorliegenden Erfindung anhand eines bevorzugten Ausführungsbeispiels, wobei auf die folgenden Zeichnungen bezug genommen wird:

Fig. 1 ist ein Blockdiagramm eines Spielprogrammiersystems.

Fig. 2 ist ein Blockdiagramm der wiederprogrammierbaren Kassette gemäß Darstellung in Fig. 1.

Fig. 3 ist ein logisches Flußdiagramm für den Kassetten- und Spieleprogrammierer gemäß Darstellung in Fig. 1.

Fig. 4 ist ein Blockdiagramm der Spieleprogrammierer- Schnittstellenkarte gemäß Darstellung in Fig. 1.

Fig. 5 ist ein Blockdiagramm des Spieleprogrammierers gemäß Darstellung in Fig. 1.

Fig. 6 ist ein Blockdiagramm für den Spiele-Sequencer gemäß Darstellung in Fig. 4.

Fig. 7 ist ein Blockdiagramm der Software-Treiberauslegung der Hardware-FIFO, des Sequencers und der Kassette.

Fig. 8 ist ein logisches Flußdiagramm eines Initialisierungsprozesses für die wiederbeschreibbare Spielkassette gemäß Darstellung in Fig. 1.

Fig. 9 ist ein logisches Flußdiagramm eines Herstellungsverfahrens für die wiederprogrammierbare Kassette gemäß Abbildung in Fig. 1;

Fig. 10 ist ein logisches Flußdiagramm des Verfahrens, bei dem ein Spiel auf die Kassette kopiert wird;

Fig. 11 ist ein logisches Flußdiagramm des Verfahrens, bei dem das Spiel auf der Kassette gelöscht wird;

Fig. 12 ist ein schematisches Blockdiagramm einer Master- Inhaltsdatei (Master Content File) zur Verschlüsselung;

Fig. 13 ist ein logisches Flußdiagramm zur Verschlüsselung einer Inhaltsdatei (Content File); und

Fig. 14 ist ein logisches Flußdiagramm zur Entschlüsselung einer Inhaltsdatei (Content File).

Das Spielprogrammiersystem gemäß Fig. 1 umfaßt ein Speichersubsystem 10, einen Personalcomputer (PC) 12, beispielsweise einen IBM PS/ValuePoint Mod. No. 6384L00 mit 527 MB Festplattenkapazität, der mit einer Spieleprogrammier- Schnittstellenkarte 14 ausgestattet ist, die mit einem externen Spieleprogrammierer 16 verbunden ist. Das Konzept der vorliegenden Erfindung ist in die Spieleprogrammier- Schnittstellenkarte 14, den Spieleprogrammierer 16 und die Programmierung einer wiederprogrammierbaren Spielekassette 18 integriert.

Die Spieleprogrammier-Schnittstellenkarte 14 ermöglicht die Kommunikation und Datenübertragung zwischen dem Personalcomputer 12 und dem Spieleprogrammierer 16. Die Spieleprogrammier-Schnittstellenkarte 14 ist über einen 16- Bit-Bus mit dem PC 12 verbunden. Die Spieleprogrammier- Schnittstellenkarte 14 enthält, wie aus der Darstellung in Fig. 4 deutlicher hervorgeht, einen Adressenpuffer 56, einen Datenpuffer 58, Steuerungen 60, einen FIFO-Speicher 62 und einen Sequencer 64. In einer Leseoperation erhält die Spieleprogrammier-Schnittstellenkarte 14 Informationen von der wiederprogrammierbaren Spielekassette 18, die an der Buchse 40 in den Spieleprogrammierer eingesteckt ist. Die Informationen werden durch den Spieleprogrammierer 16 und anschließend direkt an den PC 12 geleitet. Der PC 12 verwendet diese Informationen, um den Kassettentyp zu bestimmen und um festzustellen, ob der Typ, die Konfiguration und die Qualität für die Verwendung durch das Programmiersystem im voraus festgelegt sind.

Um eine eindeutige Prüfung der urheberrechtlichen Bestimmungen und der Qualitätskriterien der Spielekassetten zu gewährleisten, wird eine programmierbare Array-Logik (PAL) oder eine generische Array-Logik (GAL) 38 programmiert, um die Flash-Speicher 30 und 32 der Kassette 18 beschreibfähig zu machen, allerdings nur, wenn der richtige Datenstrom vom Spieleprogrammierer 16 an die Spielekassette 18 gesendet wird, wie aus der Darstellung in Fig. 18 deutlich hervorgeht. Die PAL 38 sendet an den Spieleprogrammierer 16 außerdem das Signal "Kassette geprüft". Dieses Konzept erfüllt zwei Ziele: a) der Spieleprogrammierer 16 programmiert ausschließlich Kassetten, die die urheberrechtlichen Bestimmungen erfüllen, und b) andere Spieleprogrammierer können nur dann Kassetten, die die urheberrechtlichen Bestimmungen erfüllen, verwenden, wenn sie den eindeutigen Datenstrom bereitstellen können.

Wie aus der Darstellung in Fig. 3 hervorgeht, sendet der Spieleprogrammierer 16 an Schritt 42 die Identifikationsdaten an die Kassette 18. An der Kassette 18 werden die Daten geprüft, wie aus der Darstellung an Schritt 44 hervorgeht. Sind falsche Daten vorhanden, wird ein Signal 'falsche Daten' an die Schreiblogik des Sequencer 64 gesendet, der an Schritt 46 ausgeschaltet wird. An Schritt 49 wird an den Spieleprogrammierer 16 ein Fehlercode gesendet, der es dem Spieleprogrammierer 16 ermöglicht, den Prozeß an Schritt 48 anzuhalten. Werden die Identifikationsdaten der Kassette bestätigt, wird die Schreiblogik an Schritt 50 aktiviert und an Schritt 51 ein Code 'Kassette OK' an den Spieleprogrammierer 16 gesendet. Der Spieleprogrammierer 16 setzt den Prozeß fort bis Schritt 52.

Wie aus der Darstellung weiterhin hervorgeht, enthält in Fig. 2 die wiederprogrammierbare Spielekassette 18 einen oder mehrere Flash-Speicherchips 30 und 32. Das abgebildete Ausführungsbeispiel der Kassette mit dem Flash-Speicher 30 und/oder 32 läßt sich in weniger als 30 Sekunden programmieren.

Der Flash-Speicher 30 und 32 enthält außerdem vom Händler verwendbare Informationen wie beispielsweise eine Speicheridentifikation und den Kassettentyp. Der Speichermanager oder die Benutzeranwendung kann diese Informationen bei der Initialisierung der Kassette mit angeben. Eine Batterie 34, die die Sicherung für einen statischen RAM-Speicher (SRAM) 36 gewährleistet, ist optional. Welche Batterie dabei in Frage kommt, hängt ab von den Anforderungen des jeweiligen Spiels. Normalerweise werden die Batterie 34 und der SRAM 36 verwendet, um die Spielstände und andere Informationen wie beispielsweise Vergleichsdaten der Mitspieler zu speichern. Die Kassette 18 enthält die Hardware 38 zur eindeutigen Identifikation, beispielsweise die PAL, die sie für den jeweiligen Hersteller, autorisierten Vertriebsbevollmächtigten oder Händler identifiziert. Die Logik 39 dient zur Unterscheidung zwischen dem Flash-Speicher 30 und 32 und dem SRAM 36.

Während eine Kassette beschrieben wird, empfängt die Spieleprogrammier-Schnittstellenkarte 14 Daten vom PC 12 und füllt den FIFO-Speicher 62 in der Spieleprogrammier- Schnittstellenkarte 14. Der Sequencer 64 in der Spieleprogrammier-Schnittstellenkarte 14 erzeugt Adressen, geeignete Befehle, Steuer- und Zeitsignale und sendet den Spieleinhalt vom FIFO-Speicher 62 an den Spieleprogrammierer 16, der diese Informationen wiederum an die wiederprogrammierbare Spielekassette 18 weiterleitet. Der Sequencer 64 in der Schnittstellenkarte 14 versetzt dieses Spieleprogrammiersystem in die Lage, Daten sehr schnell auf die wiederprogrammierbare Spielekassette 18 zu schreiben. Der Spieleprogrammierer 16 stellt eine Schnittstelle zwischen der Spieleprogrammier-Schnittstellenkarte 14 und der wiederprogrammierbaren Spielekassette 18 her. Wie aus der Darstellung in Fig. 5 genauer hervorgeht, umfaßt der Programmierer 16 eine elektronische Hardware und die physikalischen Schnittstellen 70 einschließlich Kabel. Der Programmierer ist so ausgelegt, dass er an den Schlitzen 65, 66, 67 und 68 ein Plug-In mehrerer wiederprogrammierbarer Spielekassetten 18 aufnehmen kann. Die Kassetten der verschiedenen Hersteller und Spieleformate weisen unterschiedliche Dichten und Formfaktoren auf. Beispielsweise paßt eine Kassette des Typs Sega Genesis nicht in einen Schlitz, der auf ein Nintendo SNES (Super Nintendo Entertainment System) ausgelegt ist. Darüber hinaus hat jeder Kassettentyp andere elektrische Anschlüsse. Deshalb gibt es im Spieleprogrammierer 16 entweder die separaten Schlitze 65, 66, 67 und 68, oder es ist ein Kassettenadapter vorhanden, um mehrere Spieleformate berücksichtigen zu können. Dabei könnte es sich beispielsweise um folgende Formate handeln: (a) Sega Genesis 65, (b) Nintendo SNES 67, (c) Sega Game Gear 67 und (d) Nintendo Game Boy 68. Weitere Schlitze können hinzugefügt werden, um noch andere Formate zu berücksichtigen. Die Dichte gibt an, wieviel ein Speicherchip oder eine Kassette aufnehmen kann. Eine höhere Dichte bedeutet, dass mehr Bits für das Videospiel zur Verfügung stehen.

Das Spieleprogrammiersystem ermöglicht die Programmierung wiederbeschreibbarer Flash-Speicher-Spielekassetten, die gemietet oder gekauft werden können. Die Flash-Speicher- Halbleitertechnologie wurde von der Intel Corporation im Jahr 1988 eingeführt. Auf der Ebene der Halbleitertechnologie basiert der Flash-Speicher ETOX (EPROM tunnel oxide) von Intel auf einer einzigen Transistor-EPROM-Zelle. Sie ermöglicht einen hochdichten, nichtflüchtigen und leistungsstarken Schreib-/Lesespeicher. Die wichtigsten Merkmale dieses Speichers sind ein niedriger Energieverbrauch, extreme Robustheit und eine hohe Zuverlässigkeit. Der niedrige Energieverbrauch kommt besonders im Vergleich zu anderen löschbaren PROM-Speichern wie beispielsweise EEPROM und EPROM zum Tragen.

Die Flash-Speichertechnik verwendet eine Ein-Transistor-Zelle, die höhere Dichten, Skalierbarkeit, höhere Zuverlässigkeit und niedrigere Kosten ermöglicht, während gleichzeitig die systeminterne elektrische Löschbarkeit genutzt wird. Darüber hinaus bietet der Flash-Speicher im Vergleich zu anderen Festkörperspeichern zahlreiche herausragende Vorteile, beispielsweise besitzt er im Vergleich zu elektrisch löschbaren programmierbaren Nur-Lese-Speichern (EEPROM), EEPROM, den Vorteil, dass er nicht nur nichtflüchtig ist, sondern einzelne Bytes elektrisch löschen kann. Hierfür ist eine komplexere Zellstruktur erforderlich, die zu völlig anderen Eigenschaften und Fähigkeiten führt, beispielsweise zu einer begrenzten Kapazität im Vergleich zur Dichte, zu einer geringeren Zuverlässigkeit und zu höheren Kosten. Diese Eigenschaften machen den Speicher für die breite Anwendung ungeeignet. Daher ist die Zellstruktur eines EEPROM komplexer (d. h. sie enthält mehr Teile/datengespeichert) als ein Flash- Speicher. Darüber hinaus dauert es bei der Programmierung eines EEPROM etwa 10 ms, um jeden Speicherort (Zelle) zu beschreiben. Bei der Programmierung eines Flash-Speichers dauert es nur 9 Mikrosekunden, um jede Speicherstelle zu programmieren. Im dargestellten Beispiel können mit den Flash- Speichern 30 und 32 (je 8 Bit Breite, und bei der Adressierung parallel für 16 Bit) zwei Megabyte in weniger als 10 Sekunden programmiert werden. Dies ist etwa drei Größenordnungen schneller als mit dem EEPROM.

In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung werden zwei 8-MB-Flash-Speicherchips (Intel 28F008SA) verwendet. Dies ergibt einen Speicherumfang von 2 MB in einer einzigen Kassette. Es ist zu beachten, dass der Spieleprogrammierer 16 bis zu 16 MB verarbeiten kann, was den meisten Anforderungen von Spielekassetten genügen müßte. Außerdem kann der Spieleprogrammierer 16 problemlos geändert werden, um bei Bedarf Spielekassetten mit einer höheren Dichte aufnehmen zu können. Die Produktionsdauer einer Kassette wurde erheblich reduziert, nämlich auf weniger als 30 Sekunden, so dass ein Kunde auf das Produkt warten kann, ohne dass dies lange dauert.

Der Sequencer (SEQ) 64 der Spieleprogrammier- Schnittstellenkarte 14 wird am besten in Fig. 6 veranschaulicht. Die Busschnittstelle ISA I/F oder ISA enthält den ISA BUS CONTROL I/F 71 sowie die Steuerlogik zur Schnittstelle zwischen dem ISA-Bus und dem SEQ 64. Der FLASH MEM I/F 73 liefert die Ein- und Ausgabesignale für den Flash- Speicher. Der FIFO 74 bzw. FIFO 62, wie er in Fig. 4 beziffert ist, wird vom ISA-Bus verwendet, um Spieledaten zu laden, während der SEQ 64 die Programmierung der Flash- Speicher 30 und 32 ausführt. Der SEQ 64 lädt die Daten einzeln bzw. paketweise, wenn der FIFO 74 nicht leer ist. PC CHKSUM 75, das an späterer Stelle genauer beschrieben wird, enthält die Spiele-Prüfsumme, die von der Software auf dem PC berechnet und geladen wurde. CNTL 76 wird vom PC SW verwendet, um dem SEQ 64 zu signalisieren, dass die Programmierung beginnen soll und dass dem SEQ 64 mitgeteilt werden soll, wann der Zustand End-of-Game eintritt, und auf der internen Steuerleitung weitergesendet. PC SEQ-mm-ADR 77 wird von der PC-Software zur Adressierung der SEQ 64 RAM 89-Speicherstellen verwendet. PC SEQ-RAM-DAT 78 wird von der PC-Software zum Schreiben von Daten in die SEQ 64 RAM-Speicherstellen verwendet.

Der SEQ I/F enthält ein DATA-OUT 79, der Daten vom FIFO 74 verwendet, um einen Befehl auf den Datenbus 73 des Flash Speichers I/F zu legen. DATA-IN 81 wird vom SEQ 64 verwendet, um Daten oder den Status des Datenbusses 73 vom Flash-Speicher I/F zu empfangen. ADR-OUT 83 ermöglicht es dem SEQ 64, eine Adresse zu erzeugen, um auf die Flash-Speicher 30 und 32 zuzugreifen. CNTL-OUT 85 wird vom SEQ 64 verwendet, um Steuersignale an die Flash-Speicher 30 und 32 zu erzeugen.

Die Sequence Engine enthält ADR-CNTR 87, der auf den internen Code von Seq 64 zugreift, der im RAM 89 gespeichert ist und die Funktion eines Code-Adressen-Zählers hat. Wie bereits angeführt wurde, speichert der RAM 89 den internen Code von Seq 64. Dieser Code wird von der PC-Software nach Power-On- Reset (POR) geladen. Darüber hinaus wird der Code ein zweites Mal gelesen und von der PC-Software geprüft, um sicherzustellen, dass der Inhalt korrekt geladen wurde. Der DECODER 91 von Fig. 6 dekodiert den SEQ-Maschinencode und erzeugt die geeigneten Steuersignale an andere Register. Ein OSC 93 ist ein Oszillator, der den Taktimpuls für die gesamte Sequence Engine erzeugt. JMP-ADR 95 speichert die Jump-Adresse der Code-Speicherstelle. Wenn der BIT-TEST 97 wahr ist, wird sein Inhalt in ADR-CNTR 87 geladen. Der BIT-TEST 97 wird vom SEQ 64 verwendet, um mehrere Hardware-Statusformen zu testen und um die Verzweigungsbedingungen für den internen Code von SEQ zu bestimmen. CNTR-1 99 wird vom SEQ 64 als Mehrzweckzähler verwendet und kann als Timer, Byte-Zähler, Loop-Zähler und Verzögerung dienen. CNTR-2 101 wird auf ähnliche Weise vom SEQ 64 als Mehrzweckzähler verwendet und kann ebenfalls als Timer, Byte-Zähler, Loop-Zähler und Verzögerung dienen. SAVED-ADR 103 wird vom SEQ 64 verwendet, um die aktuelle Flash-Adresse zur späteren Verwendung zu speichern. Während STAT-REG 105 vom SEQ 64 verwendet wird, um den Status an die PC-Software zu senden, wird FLSH CHK-SUM 107 vom SEQ 64 verwendet, um eine Hardware-Spiele- Prüfsummenberechnung durchzuführen und diese Summe mit PC CHK- SUM 75 zu vergleichen.

Die BUSES des Sequencers (64), der in Fig. 6 abgebildet ist, enthalten den SYSTEM DATA BUS, der mit einer einzelnen Hash- Markierung auf der Busleitung markiert ist. Auf diesen Systemdatenbus kann von der PC-Software aus zugegriffen werden. Als Eingabe an die PC-Software wird er vom Flash- Datenbus und vom SEQ-Datenbus multiplexiert. Als Ausgabe von der PC-Software ist das der ISA-Datenbus. SEQ ADR BUS ist mit einer doppelten Hash-Markierung markiert. Hierbei handelt es sich um den Adreßbus SEQ RAM, der auf den SEQ-Maschinencode in RAM 89 zugreift. SEQ DATA BUS ist mit einer dreifachen Hash- Markierung markiert. Dieser SEQ-Datenbus hat ein Ob-code-Feld, ein Datenfeld und ein Steuerfeld. Das Ob-code-Feld wird als Anweisung an den Dekoder 91 gesendet. Das Datenfeld wird beispielsweise als Daten an die Register gesendet, u. a. an 99, 101 und 105. Das Steuerfeld wird als Steuersignale direkt an die Flash-Speicher 30 und 32 gesendet. Das Steuerfeld ist unabhängig von anderen Feldern, d. h. es kann sich ändern, ohne dadurch die Abläufe der anderen Felder zu beeinträchtigen. Das Ob-code-Feld arbeitet normalerweise mit dem Datenfeld zusammen. Auch ist es möglich, ohne Datenfeld zu arbeiten, d. h. SAVED-ADR 103 oder FIFO 74 kann ohne Datenfeld arbeiten. Das Datenfeld arbeitet jedoch nicht unabhängig. Register, die in einer Anweisung ausführen können, sind FLASH CHK-SUM 107, SAVED-ADR 103, ADR-OUT 83, die eine Inkrementierung durchführen können, DATA-IN 81, das eine Niedrig-Byte-Auswahl treffen kann, und CNTR-1 99 und CNTR-2 101, die eine Inkrementierung und eine Dekrementierung durchführen können.

Die Software-Schnittstelle ermöglicht eine Adapterkommunikation über Port I/O, bei der ein einziger Port für alle Lese-, Schreib-, Lösch- und Statusoperationen sowie für LCD 72 und LED verwendet wird. Schreiboperationen verwenden den Sequencer 64 und die Hardware des FIFO 62, um Daten in die Flash-Speicher-Kassette 18 zu schreiben. Da die Größe des Hardware-FIFO 62 gleich 2 KB ist, werden alle Schreibanforderungen unter Verwendung von 1-KB-Blöcken ausgeführt. Dabei wird zur Leistungssteigerung ein Flip-Flop- Verfahren eingesetzt. Sobald die Daten den FIFO 62 erreichen, liest der Sequencer 64 den FIFO 62 und überträgt die Daten an die Flash-Speicherkassette 18. Während der Schreiboperation häuft die Hardware eine einfache 8-Bit-Prüfsumme an. Sobald die Schreiboperationen abgeschlossen sind, wird die Prüfsumme mit einer Software-Prüfsumme verglichen, um die Schreiboperation zu überprüfen. Darüber hinaus überprüft der Gerätetreiber während der Schreiboperation nach jeder Datenübertragung ein Schreibstatussignal auf Ausführungsfehler. LCD/LED-Schreiboperationen werden unter Verwendung von Port I/O auf der Schnittstellenkarte 14 ausgeführt.

Leseoperationen lesen Daten direkt über den I/O-Port von den Flash-Speicherchips 30 und 32 ein, während Löschoperationen den "Flash"-spezifischen Blocklöschbefehl verwenden. Jeder Typ von Flash-Speicherchip verwendet einen eigenen Löschbefehl.

Softwareoperationen, bei denen in einem PC 12 mehrere Schnittstellenkarten 14 verwendet werden, können entweder synchron oder asynchron verlaufen. Dies ist von der Betriebssystemplattform abhängig. Softwareoperationen, die auf einer einzigen Schnittstellenkarte 14 laufen und mit dem Spieleprogrammierer 16 verbunden sind, der mehrere Spielekassetten 18 und die Schlitze 65, 66, 67 und 68 aufweist, sind synchron. Somit werden mehrere Operationsanforderungen an eine einzelne Schnittstellenkarte 14 von Software-Semaphoren in einem Gerätetreiber und nicht in einem komplexeren Hardwareaufbau blockiert oder serialisiert. Für den Hardware-Aufbau, der einen Mikrocodetreiber enthält, erfordert der Sequencer 64 auf der PC-Schnittstellenkarte 14 einen herunterladbaren Mikrocode, um die Datenübertragungsoperationen zwischen dem FIFO 62 und den Flash-Speichern 30 und 32 zu bewerkstelligen. Hierbei handelt es sich um den Mikrocode, der die verschiedenen Spielekassettenformate des Spieleprogrammierers 16 steuert, die vom Spieleproduktionssystem unterstützt werden. Dieser Mikrocode wird vom Spielesystem-Gerätetreiber 16 heruntergeladen, der auch Befehle und Daten über die FIFO- Register 62 der Karte an den Sequencer 64 weiterleitet. Der interne Code des Sequencers steuert folgende Funktionen: Schreiben von Daten von den FIFO-Registern 62 in die Flash- Speicher 30 und 32, Berechnung und Vergleich von Datenprüfsummen, um Schreiboperationen zu prüfen, und Lesen von Daten aus den Flash-Speichern 30 und 32 in die FIFO- Register 62.

Der Vorteil bei der Verwendung eines Sequencers 64 in dieser Anwendung ist, dass der Sequencer-Code so abgeändert werden kann, dass er sich für mehrere verschiedene Typen von beschreibbaren ROMs eignet. Der Sequencer-Mikrocode wird ähnlich wie Standard-Assembly-Sprache erzeugt, wobei in einem ersten Schritt unter Verwendung vordefinierter Opcodes und Operanden eine Quellcodedatei erzeugt wird und in einem zweiten Schritt die Quellcodedatei unter Verwendung von GASM.EXE (Spiele-Assembler) zusammengefügt wird.

Der Befehl GASM.EXE erzeugt anhand der ursprünglichen Quellcodedatei zwei Ausgabedateien. Die erste ähnelt einem standardmäßigen Assembler Listing (Dateiname.LST), und die zweite Datei ist der binäre Sequencer-Mikrocode (BSM), der die Dateinamenerweiterung BIN annimmt. Für jeden Spielekassettentyp existiert eine BSM-Datei. Alle geeigneten BSM-Dateien werden während der Gerätetreiber-Initialisierung auf die Spieleprogrammier-Schnittstellenkarte 14 heruntergeladen.

Die Definition und Installation der Hardware- und Softwarekomponenten wird nachfolgend aufgeführt und anhand von Fig. 7 näher erläutert:

Die Variable LIBPATH für die Module FLRSYS.DLL, FLRIOPL.DLL und CFG.DLL, Blöcke 114, 116 bzw. 118 in Fig. 7, ist in der Datei Config.sys von OS/2, 2.x, definiert.

Der Aufbau des Software-Treibers beruht auf einer Strategie, die in Fig. 7 dargestellt ist. Dabei wird eine dynamische Link Library (Ring-3, 32-Bit) FLRSYS.DLL 114 als Software-Link zwischen der Benutzerschnittstellenanwendung 112, die beispielsweise die LCD-Anzeige 72 oder eine Tastatur umfaßt, und dem Flash-Speicher-Treiber (FLRIOPL.DLL) 116 verwendet. Bei FLRIOPL. DLL handelt es sich um einen IOPL-Treiber (IOPL = Input/Output Privilege Level), Ring-2, 16-Bit, der mit der Spieleprogrammier-Schnittstellenkarte 14 unter Verwendung von Port I/O verbunden ist, wie aus der Darstellung in Fig. 7 hervorgeht.

Die folgenden Szenarien beschreiben, wie das Spieleprogrammiersystem von Fig. 1 verwendet wird. Eine neue Prozedur zur Initialisierung von Kassetten, die in Fig. 8 veranschaulicht und näher beschrieben wird, umfaßt folgende Schritte: ein Kundendienst-Repräsentant (CSR) wählt an Schritt 80 auf dem Bildschirm eine neue Kassetteninitialisierung. Der Kundendienst-Repräsentant verwendet den Scanner 22, um an Schritt 82 von der Kassette 18 einen Barcode einzuscannen. Normalerweise besitzen neue unprogrammierte Kassetten Barcode- Indizien, die folgende Informationen (Kategorien) enthalten: (1) die Speicheridentifikation, (2) Kassettenart, z. B. Sega, Nintendo usw., und (3) eine Kassetten-Seriennummer. Diese Informationen werden von der Initialisierungsprozedur in einen Teil der Kassetten-Flash-Speicher 30 und 32 programmiert (entweder über Barcode oder über die Tastatur usw.). Normalerweise wird das von der jeweiligen Firma getan, bevor die Kassetten tatsächlich benötigt werden. Die Kassetten werden anschließend in ihre jeweiligen Fächer gelegt, wo sie zur Verwendung bereitliegen (z. B. bis ein Kunde ein Spiel bestellt). Spielekassetten, die wiederverwendet werden sollen, können in den gleichen Fächern aufbewahrt werden, da die Kategorienummern, die zu den jeweiligen Kassetten gehören, sich bereits auf der Kassette befinden. Weitere Informationen, die man in diesem Speicher unterbringen könnte, wären beispielsweise die Spieleidentifikation. Dies wäre der Fall, wenn der Kundendienst-Repräsentant an die Produktionsmaschine den Befehl ausgibt, ein bestimmtes Spiel herunterzuladen. Der Kundendienst-Repräsentant legt die Kassette 18 in den betreffenden Schlitz im Spieleprogrammierer 16 ein, wo sie an Schritt 84 mit dem Kassettenspieleanschluß 40 verbunden wird. Wie an Schritt 44 von Fig. 3 vorgesehen wird die Identifikationsprüfung der Kassette 18 vorgenommen. Der Spieleprogrammierer 16 identifiziert daraufhin die wiederprogrammierbare Spielekassette 18 und schreibt an Schritt 86 Barcode-Informationen in die Flash-Speicher 30 und 32 der Kassette, wodurch an Schritt 88 automatisch neue Kassetteninformationen in den Speicher 10 (Systembestand) eingefügt werden.

Die bedarfsorientierte Spieleproduktion, die in Fig. 9 veranschaulicht und näher beschrieben wird, umfaßt folgende Schritte: ein Kunde bringt an Schritt 90 eine Spieleplakette, eine leere Amaray-Hülle oder einen Abschnitt zu einem Kundendienst-Repräsentanten. Der Kundendienst-Repräsentant startet den Produktionsprozeß, indem er beispielsweise den Barcode von der leeren Amaray-Hülle oder dem Abschnitt einscannt (Schritt 92). Die LCD-Anzeige 72 im Spieleprogrammierer 16 fordert den Kundendienst-Repräsentanten in Schritt 94 auf, die richtige wiederprogrammierbare Spielekassette 18 einzugeben. Das Spieleprogrammiersystem prüft in Schritt 96, ob es sich um die richtige Kassette (Ausführung, Typ, Dichte) handelt. Sobald die Einholung und Identifizierung der Kassette durch die Schritte 98, 100, 102, 96 und zurück zu 98 abgeschlossen sind, fordert die LCD- Anzeige 72, als Beispiel oder optional, den Kundendienst- Repräsentanten auf, die Kassette 16 in den Schritten 104 und 106 zu löschen, falls sich ein Spiel darauf befindet. Befindet sich auf der Kassette kein Spiel, wird an Schritt 108 dafür gesorgt, dass das System die Spielekassette beschreibt und Informationen an den Drucker 24 sendet. Der Drucker 24 erzeugt die Identifikation und Anleitung für das Spiel. Sobald das Spiel an Schritt 110 fertiggestellt ist, wurde die Bestellung des Kunden abgewickelt, und die Transaktion ist damit beendet.

Wie an früherer Stelle bereits angeführt wurde, kann das Spieleprogrammiersystem so abgeändert werden, dass auch andere Datenkassetten bespielt werden können. Darüber hinaus ist das System nicht auf die Programmierung von Spielekassetten beschränkt.

In einem Geschäft wählt ein Kunde ein Spiel aus, das daraufhin in einem Spielekiosk hergestellt wird. Dieser Spielekiosk kann einen Bildschirm umfassen, der vorzugsweise mit einer berührungsempflindlichen graphischen Benutzerschnittstelle ausgestattet ist, wobei jedoch eine Tastatur ebenfalls eine vernünftige Alternative darstellt. Der Benutzer macht die folgenden Angaben in der folgenden Reihenfolge: (1) System des Kunden, oder er stellt die zum Verkauf oder zur Vermietung verfügbaren Spiele vor, d. h. Sega, Nintendo usw., (2) als nächstes wählt er eine Kategorie dieser verfügbaren Spiele aus, z. B. Sport, Kriegsspiel, Kinderspiel usw., und (3) danach geht er die einzelnen Titel durch und kann sich eine kurze Zusammenfassung des Spiels ansehen, in der die beteiligten Charaktere vorgestellt werden und/oder in der das Spiel grob beschrieben wird.

Sobald der Kunde entschieden hat, welches Spiel er haben möchte, wird auf dem berührungsempfindlichen Bildschirm eine Auswahl eingegeben und eine Bestellung ausgedruckt. Ein Drucker für diese Bestellung ist Bestandteil dieses Kiosks. Diese Bestellung wird dem Kundendienst-Repräsentanten übergeben, der diese am Bildschirm bearbeitet. Die gedruckte Bestellung kann den Titel des Spiels und/oder einen Barcode enthalten. Der Barcode enthält mindestens die für das ausgewählte Spiel nötigen Informationen; d. h. die Spielekennung oder seine Teilenummer. Der Kundendienst- Repräsentant bearbeitet daraufhin die Bestellung mit dem Barcode und der Teilenummer mit einem Computer, auf dem alle Spiele gespeichert sind. Die Bestellung wird in den Computer eingescannt, beispielsweise mit einem Barcode-Scanner, um die benötigten Indizien zur Identifikation des Spiels zu erhalten, damit die Vorbereitung der Kassette beginnen kann. Gleichzeitig wird eine geeignete Kassette in den Spieleprogrammierer 16 ("ROM-Brenner") eingelegt, der alle auf der Kassette enthaltenen Informationen einliest. Wurde die Kassette beispielsweise zuvor vermietet und enthält diese daher noch ein anderes Spiel sowie sonstige Kassetten- und Quelleninformationen im Flash-Speicher, werden die Schritte 96, 98, 100 und 102 von Fig. 9 aufgerufen. In diesem Fall enthält ein Teil des Flash-Speichers die vollständigen Bestandsdaten. Das bedeutet, dass der Flash-Speicher auf der Kassette gelöscht werden muß, bevor er wieder neu beschrieben werden kann, was anschließend in bezug auf Fig. 11 näher beschrieben wird.

Die Schritte für das Beschreiben, unabhängig davon, ob es sich um ein Spiel oder ein anderes Programm handelt, werden ausführlicher unter Verweis auf Fig. 10 beschrieben. Als Option kann der zu kopierende Inhalt als Datei verschlüsselt und/oder komprimiert werden. Dies wird ausführlicher unter Verweis auf die Fig. 12 bis 14 beschrieben. In Schritt 120 öffnet die Anwendung 112 im Speicher 10 eine Datei mit Inhalt, die für die Flash-Speicher 30 und 32 bestimmt ist. Die Anwendung 112 leitet daraufhin in Schritt 122 den Zeiger auf die Dateiinhalte an den Gerätetreiber API weiter, wie aus der Darstellung in Fig. 7 hervorgeht. In Schritt 124 werden die Inhalte für die Flash-Speicher 30 und 32 vom Gerätetreiber API in Blöcke von 1 KB aufgespalten. Jeder Block wird einzeln an den Gerätetreiber geleitet. Wie an früherer Stelle in Fig. 7 beschrieben wurde, schreibt der Gerätetreiber in Schritt 126 die Daten in den FIFO 62. Der Sequencer 64 liest die Daten in Schritt 128 aus dem FIFO 62. Die Daten werden daraufhin vom Sequencer 64 in die Flash-Speicher 30 und 32 geschrieben (Schritt 130). Die Prüfsummenoperation, die an früherer Stelle in bezug auf Fig. 6 beschrieben wurde, wird anschließend vom Sequencer 64 durchgeführt, um in Schritt 132 den Status der Schreiboperation zu bestimmen. Der Sequencer 64 sendet an diesem Punkt oder an Schritt 134 die Ergebnisse an den Gerätetreiber zurück. Wenn jedoch mehr als einer der 1-KB- Blöcke verarbeitet werden muß, werden die Schritte 126 bis 134 wiederholt, bis alle Blöcke verarbeitet sind.

Der in bezug auf Fig. 9 oben beschriebene Spielelöschprozeß und insbesondere die Schritte 104 und 106 davon werden anschließend in bezug auf Fig. 11 ausführlich beschrieben. Der Löschprozeß ist abhängig von den eingestellten Parametern des Flash-Speichers. Im allgemeinen muß die Anwendung 112 den Löschbefehl an den Gerätetreiber API weiterleiten, wie aus der Darstellung in Fig. 7 sowie in Schritt 136 von Fig. 11 hervorgeht. Dieser Befehl wird vom Gerätetreiber API an den Gerätetreiber in Schritt 138 weitergeleitet. In Schritt 140 löscht der Gerätetreiber die Flash-Speicher 30 und 32 in 16 separaten Löschprozessen, wie oben bereits angeführt wurde. Dies ist abhängig vom ausgewählten Flash-Speicher. Angenommen, der Flash-Speicher in der Kassette ist leer, so findet vor dem eigentlichen Einbrennen des Spiels zuerst das Anbringen des Barcodes auf einem Klebestreifen o. ä. statt sowie das Versehen der Kassette mit weiteren Informationen. Dies umfaßt einen weiteren Barcode-Streifen und in einem weiteren Teil des Flash-Speichers die folgenden Angaben: (1) die Speicherkennung, (2) die Seriennummer der Kassette, (3) den Kassettentyp (Sega, Nintendo usw.) und (4) die Teilenummer des Spiels. Bei der Programmierung der Kassette werden die gleichen Informationen auch auf das Anweisungsblatt gedruckt, das vom Kundendienst-Repräsentanten mit eingepackt wird. Die Informationen werden weiterhin an den lokalen Computerspeicher (z. B. einen IBM Modell 90) gesendet, der alle Informationen zu dem zu kopierenden Spiel umfaßt. Diese Informationen werden zusätzlich zur Angabe des Eingangs-/Ausgangsstatus für Mietkassetten in der Transaktion übertragen.

In einigen Geschäften (beispielsweise Blockbuster-Videotheken) werden die Transaktionsdaten beispielsweise einmal täglich oder in anderen sinnvollen Intervallen an den Computer in der Hauptgeschäftsstelle übertragen. Der Computer im jeweiligen Geschäft stimmt die Daten mit den im Spielecomputer gespeicherten Daten ab, um festzustellen, ob Angaben fehlen oder falsch sind. Wenn beispielsweise die Speichernummer falsch ist, sendet der Computer im jeweiligen Geschäft einen Fehlercode aus, der dazu auffordert, eine andere Kassette in den Spieleprogrammierer 16 einzulegen. Dies wäre auch der Fall, wenn die Kassette beispielsweise eine ungültige Kassetten-Seriennummer enthielte.

Der Kundendienst-Repräsentant (CSR) verarbeitet an der Kasse oder am Bildschirm auch die Anweisungen und die programmierte Spielekassette. Darauf lassen sich bezüglich der Kassette die mietrelevanten Daten speichern, z. B. die Teilenummer und verschiedene Identifikationsnummern sowie Zusatzinformationen, z. B. der Kundenname, seine Adresse usw. Diese Daten lassen sich auf einem Beleg zusammen mit dem Miet-/Verkaufspreis ausdrucken und im lokalen Computerspeicher speichern und mit der bereits im Computer befindlichen Kassettenidentifikation und -teilenummer vergleichen.

Wie aus der vorangegangenen Beschreibung leicht erkennbar ist, ist es nicht erforderlich, dass das POS-Register oder - Terminal direkt mit dem Spielespeichercomputer verbunden ist. Je nach Ablauf im jeweiligen Geschäft ist dies möglich und kann sogar Vorteile haben, wenn man das Laden der Spiele und das Programmieren der Kassetten automatisieren möchte.

Der Spielecomputer hat z. B. auf Festplatten, CD ROMs, Magnetbändern oder anderen lokalen Speichermedien den Spieleinhalt aller kopierbaren Spiele gespeichert. Ein Schutzsystem für den Dateiinhalt wird anschließend in bezug auf die Dateisicherheit beschrieben. Nach dem zu kopierenden Spiel werden Informationen oder Indizien an den Spielespeichercomputer bereitgestellt, worauf eine neue oder gebrauchte Kassette installiert wird. Anschließend wird, das Laden des Spiels sowie weiterer Angaben in die Flash-Speicher 30 und 32 begonnen.

Ebenfalls angeschlossen an den separaten Computer oder Spielespeichercomputer, beispielsweise über eine Telefonleitung, ist ein Host-Spielecomputer, der zur Aktualisierung des Verzeichnisses im Spielecomputer sowie bei Bedarf zur Ferndiagnose dient. Der Host-Computer dient weiterhin zum Herunterladen und Speichern neuer oder geänderter Spiele, die danach an den Spielespeichercomputer übertragen werden, sowie zur Übertragung anderer Daten.

Im Spieleproduktionssystem läuft ein Timer, der eine Zählung durchführt, solange ein Spiel 'aufgebrannt' wird. Zusätzlich liefert eine Zeituhr entweder eine voreingestellte Uhrzeit und Dauer oder einen voreingestellten Zeitabschnitt, nach dem die Verbindung wieder getrennt wird. In regelmäßigen Abständen wird versucht, eine Verbindung herzustellen zwischen dem Spielespeichercomputer und dem Host-Computer, der auch über eine Fernverbindung angeschlossen sein kann, beispielsweise über Modem, Satellit oder Direktleitung. Dieses System ist folgendermaßen aufgebaut: Wird zwischen dem Host und den Spielespeichercomputern eine Verbindung nicht zum vorgesehenen Zeitpunkt aufgebaut oder wird sie vorzeitig abgebrochen, wird der stets laufende Zeitzähler des Spielebrenners nicht von den anderen notwendigen oder regelmäßig übertragenen Daten, beispielsweise den Buchhaltungsdaten, zurückgesetzt, und das System arbeitet nur während der im Zähler verbleibenden Zeit. Danach endet die Funktion. Ist die Unterbrechung der Verbindung nicht auf den Bediener zurückzuführen (unabhängig davon, ob diese Unterbrechung versehentlich eintritt), kann der Bediener vom Host-Computer ein zweites Passwort anfordern, welches sozusagen eine 'Gnadenfrist' gewährt, in der eine normalerweise kurze Zeit für den weiteren Normalbetrieb der Spielebrennanwendung eingeräumt wird. Dadurch entsteht ein ausreichend langer Zeitabschnitt zwischen den Verbindungen, jedoch wird es der Spielebrennanwendung nicht gestattet, zu laufen, ohne dass zuerst ausreichend viele Unterstützungsdaten innerhalb der festgelegten Zeitabschnitte bzw. vor Ablauf der verlängerten Zeitabschnitte an und vom Host-Computer übertragen werden.

Die Buchhaltung der Geschäftsabläufe muß rechtzeitig erfolgen, wenn die Verbindung zwischen dem Spielecomputer und dem Host hergestellt wird, um eine Nachprüfbarkeit aller Abläufe zu gewährleisten und um sicherzustellen, dass die Buchhaltung in Einklang mit gängigen Buchprüfungsverfahren liegt. Die Spielebrennanwendung läuft nicht mehr, sobald die beiden ausgewählten Zeitabschnitte beendet sind. Jedoch wird diese Anwendung auf Normalbetrieb zurückgesetzt, wenn die Verbindung wiederhergestellt wird und alle anderen Daten einschließlich der Unterstützungsdaten zwischen dem Spielespeichercomputer und dem Host-System übertragen werden.

In den Fig. 12-14 wird ein Sicherheitsprozeß mit Varianten vorgestellt, die eine Computerdatei vor unerlaubtem Zugriff schützen. Diese Einrichtung umfaßt mehrere Ebenen, um die Daten und ihren Speicherort auf einem Speichermedium zu verbergen. Der angeführte Sicherheitsprozeß enthält eine verschlüsselte Verzeichnisdienstdatei, die Zeiger auf die eigentliche Videospiel-Dienstdatei sowie einen Schlüssel zur Entschlüsselung der Inhaltsdatei enthält. Die Inhaltsdateien sind verschlüsselt und können außerdem komprimiert werden, ein optionaler Schritt in diesem Prozeß. Das beschriebene Verfahren ist vom beschriebenen Speichermedium unabhängig, so dass wahlweise eine CD-ROM, eine Festplatte oder eine Netzwerkverbindung verwendet werden kann. Die Videospiel- Inhaltsdateien werden gemäß Beschreibung in Fig. 13 verarbeitet. Fig. 13 ermöglicht zu Beginn die Erstellung einer Inhaltsdateibasis und einer Verzeichnisdienstdatei, nachdem an Schritt 142 eine neue Inhaltsdatei identifiziert wurde. Ein optionaler Schritt 144 sieht die Komprimierung der Inhaltsdatei vor. Diese Bildkomprimierung wird mit Hilfe von Algorithmen durchgeführt, die in der Fachwelt gut bekannt sind. Der nächste Schritt 146 sieht die Verschlüsselung der Inhaltsdatei vor, und zwar mit Hilfe von Verschlüsselungen, die in der Fachwelt gut bekannt sind. Schritt 148 sieht die Erstellung einer Stammdatei mit Inhaltsdatei(en) oder das Kopieren der Inhaltsdatei auf das Speichermedium vor. Danach wird an Schritt 150 ein Verzeichnisdateieintrag für jede Inhaltsdatei erstellt, die folgendes enthält: Dateikennung, Zeiger/Pfad zu Inhaltsdatei, Schlüssel zur Entschlüsselung, Anzahl der verschlüsselten Blöcke, erste Aufzeichnung, Anzahl der Aufzeichnungen und ein Komprimierungs-Flag.

Dies wird in Fig. 12 in Blockform als Inhaltsstammdatei 152 veranschaulicht. Sobald gemäß Entscheidung an Schritt 154 alle Inhaltsdateien verarbeitet sind, wird die Verzeichnisdatei an Schritt 156 verschlüsselt.

Der Zugriff auf die Inhaltsdatei (beispielsweise zum Lesen) wird in den Schritten von Fig. 14 veranschaulicht. Die Entschlüsselung der Verzeichnisdatei erfolgt an Schritt 158. An Schritt 160 wird die Verzeichnisdatei verwendet, um die Inhaltdatei zu suchen. Daraus folgt, dass die Inhaltdatei an Schritt 162 gelesen wird, um mit der Entschlüsselung der Inhaltdatei an Schritt 164 beginnen zu können. Wurde an Schritt 144 die Option der Komprimierung gewählt, so wird die Inhaltdatei an Schritt 166 dekomprimiert, so dass an Schritt 168 eine einsatzbereite Datei zur Verfügung steht. Die an Schritt 150 von Fig. 13 erzeugte Verzeichnisdienstedatei läßt sich durch öffentliche (asymmetrische) oder private (symmetrische) Schlüssel verschlüsseln. Inhaltdateien werden separat gespeichert und lassen sich durch private (symmetrische) Schlüssel verschlüsseln. Private oder symmetrische Verschlüsselung bedeutet, dass der Absender und der Empfänger den Schlüssel kennen und diesen sowohl für die Verschlüsselung als auch die Entschlüsselung verwenden. Allerdings ist die Verschlüsselung mit einem öffentlichen Schlüssel (asymmetrische Verschlüsselung) um eine Stufe sicherer. Bei der Verschlüsselung mit einem öffentlichen Schlüssel ist der Schlüssel einem bestimmten Personenkreis bekannt. Vom beabsichtigten Empfänger der Informationen wird ein spezielles Softwareprogramm verwendet. Mit diesem speziellen Programm wird nach dem Zufallsprinzip ein öffentlicher Schlüssel zusammen mit einem privaten Schlüssel erzeugt, wobei der private Schlüssel von einem und für einen Benutzer erstellt wird, und nur der Empfänger kennt den privaten Schlüssel. Der private Schlüssel steht in einem mathematischen Verhältnis mit dem zufällig erzeugten öffentlichen Schlüssel, und jeder der beiden Schlüssel ist eine Funktion des jeweils anderen. Der Empfänger verwendet den privaten Schlüssel nur zur Entschlüsselung. Der Absender empfängt den öffentlichen Schlüssel vom beabsichtigten Empfänger, also von der Person, die die Informationen empfangen soll, und der Absender kann den öffentlichen Schlüssel nur zur Verschlüsselung eingeben.

Dieses Verfahren ist um eine Stufe sicherer, da alle Inhaltdateien in eine Inhaltstammdatei mit variablen und zufälligen Pads gestellt werden, wodurch zusätzlich die Anfangs- und Endpunkte der Inhaltdateien unkenntlich gemacht werden.

Die vorliegende Erfindung wurde unter Verweis auf ein Ausführungsbeispiel dargestellt und beschrieben, doch weiß der Fachmann auf diesem Gebiet, dass verschiedene Änderungen in Form und Detail möglich sind, ohne vom Anwendungsbereich der vorliegenden Erfindung gemäß beigefügten Ansprüchen abzuweichen.


Anspruch[de]

1. Ein von einem Personalcomputer (12) gesteuertes Verfahren zur Herstellung eines Videospiels auf einer Kassette (18), die in ein kompatibles Videospielgerät eingelegt werden kann, um ein interaktives Spiel mit einem Menschen zu spielen, wobei das genannte Verfahren folgende Schritte umfaßt:

Auswählen eines Videospiels zur Herstellung des ausgewählten Videospielinhalts entsprechend dem ausgewählten Videospiel auf einer Kassette (18);

Setzen (44) von Indizien für das ausgewählte Videospiel;

Übertragen der Kennzeichnungsindizien entsprechend dem ausgewählten Videospiel zur Herstellung des Videospielinhalts auf der Kassette (18) an einen Spielespeichercomputer (16), der Daten speichert, einschließlich der Spieleinhaltdateien entsprechend dem ausgewählten Videospiel;

Übertragen von Transaktionsdaten an den Personalcomputer (12) entsprechend der übertragenen Kennzeichnungsindizien an den Spielespeichercomputer (16); und

Herunterladen von Spieleinhaltdaten aus dem Spielespeichercomputer (16) entsprechend den Kennzeichnungsindizien des ausgewählten Videospiels in die Speicher (30, 32) auf der Kassette (18);

dadurch charakterisiert, dass

das Herunterladen von Spieleinhaltdaten aus dem Spielespeichercomputer (16) unterbrochen wird, bevor die Inhaltdaten des ausgewählten Videospiels vollständig in den Speicher auf der Kassette (18) heruntergeladen werden, und zwar sobald ein vorbestimmtes Ereignis auftritt, wobei dieses Ereignis abhängig von einer nicht zustandegekommenen Übertragung der Transaktionsdaten entsprechend den Kennzeichnungsindizien an den Personalcomputer (12) ist.

2. Ein Verfahren gemäß Anspruch 1, wobei das vorbestimmte Ereignis eintritt, wenn eine vom Personalcomputer (12) vorbestimmte Zeit abläuft.

3. Ein Verfahren gemäß Anspruch 1 oder 2, das weiterhin den Schritt der Wiederaufnahme des Herunterladens der Spieleinhaltdaten umfaßt, wobei dieser Schritt eingeleitet wird, sobald an den Personalcomputer (12) Transaktionsdaten übertragen werden, die mit den Kennzeichnungsindizien in Zusammenhang stehen.

4. Ein Verfahren gemäß allen obigen Ansprüchen, das weiterhin den Schritt der Wiederaufnahme des Herunterladens der Spieleinhaltdaten umfaßt, wobei dieser Schritt eingeleitet wird, sobald eine zusätzliche Dauer für das Herunterladen gewährt wird.

5. Ein Verfahren gemäß Anspruch 4, das weiterhin den Schritt des ununterbrochenen Herunterladens der Spieleinhaltdaten umfaßt, wobei dieser Schritt eingeleitet wird, sobald an den Personalcomputer (12) Transaktionsdaten übertragen werden, die mit den Kennzeichnungsindizien in Zusammenhang stehen.

6. Ein Verfahren gemäß Anspruch 4 oder 5, wobei die Gewährung einer zusätzlichen Dauer den Schritt des Einrichtens eines Passwortes enthält, um für den Spielespeichercomputer (16) die Zeit für das Herunterladen zu verlängern.







IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com