[go: up one dir, main page]

WO2000023885A1 - Stockage de donnees statiques pour acces et extension de zone efficaces - Google Patents

Stockage de donnees statiques pour acces et extension de zone efficaces Download PDF

Info

Publication number
WO2000023885A1
WO2000023885A1 PCT/US1999/024242 US9924242W WO0023885A1 WO 2000023885 A1 WO2000023885 A1 WO 2000023885A1 US 9924242 W US9924242 W US 9924242W WO 0023885 A1 WO0023885 A1 WO 0023885A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
field
static data
code
memory
Prior art date
Application number
PCT/US1999/024242
Other languages
English (en)
Inventor
Erik Walter
Garth Conboy
Brady Duga
Original Assignee
Softbook Press, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Softbook Press, Inc. filed Critical Softbook Press, Inc.
Priority to AU12088/00A priority Critical patent/AU1208800A/en
Publication of WO2000023885A1 publication Critical patent/WO2000023885A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs

Definitions

  • This invention relates to data storage.
  • the invention relates to efficient storage of static data.
  • information retrieval programmable devices have become popular. Consumers can have portable devices to access a large amount of on-board data or information downloaded from a communication network. Examples of these information retrieval programmable devices include Personal Digital Assistant (PDA) and electronic book (EB) .
  • PDA Personal Digital Assistant
  • EB electronic book
  • Static data are data that are not modified when the device is in use.
  • static data include constants, tables, and fixed image structures.
  • Dynamic data are data that are modified dynamically when the device is in use. Examples of dynamic data include graphic information and computational data structures .
  • Static data are usually stored on mass storage devices (e.g., disk) as a database system.
  • static data are transferred to on-board random access memory (RAM) to allow the processor on the programmable device to access directly.
  • RAM random access memory
  • the use of a disk subsystem on an information retrieval programmable unit presents a number of disadvantages.
  • a disk subsystem is bulky, creating inconvenience to users and difficulty in the manufacturing process.
  • a disk subsystem is slow, resulting in long start-up time when the programmable unit is powered up and initialized.
  • using RAM to store data transferred from a disk subsystem is redundant and takes up valuable RAM storage space.
  • the present invention is a method and apparatus for storing static data in a memory.
  • the static data are represented according to a resource file structure and included in a source code of an execution code.
  • the source code is compiled to generate a machine code which includes the static data and the execution code.
  • the machine code is transferred to the memory.
  • the technique allows access to a data field in a data structure embedded in a program code.
  • the data field corresponds to a structure element.
  • a pointer to the data field which is stored in the data structure is obtained.
  • the data field is retrieved using the pointer.
  • Figure 1 is a diagram illustrating a system in which one embodiment of the invention can be practiced.
  • Figure 2 is a diagram illustrating an environment for storing static data and field update according to one embodiment of the invention.
  • Figure 3 is a diagram illustrating an resource file structure of a resource file representing the static data according to one ⁇ embodiment of the invention.
  • Figure 4 is a diagram illustrating a data structure of a resource file on a ROM/flash program code according to one embodiment of the invention.
  • Figure 5 is a flowchart illustrating a process of retrieving resource information according to one embodiment of the invention.
  • Figure 6 is an example of a resource file according to one embodiment of the invention.
  • Figure 7 is a machine code of the resource file shown in Figure 6 according to one embodiment of the invention.
  • Figure 8A is a source code to store the static data for a target processor shown in Figure 7 according to one embodiment of the invention.
  • Figure 8B is a source code to store the static data for a non-target processor shown in Figure 7 according to one embodiment of the invention.
  • the present invention is a method and apparatus for storing static data on an information retrieval programmable device for efficient access and convenient field update.
  • the static data are incorporated into the program code stored on a programmable or flash memory.
  • the static data are organized as a resource file with a simple data structure. Upon initialization, the static data are accessed efficiently using this simple data structure.
  • the static data are also conveniently updated remotely or in the field via a communication port or by a plug-in replacement of the programmable or flash memory.
  • Figure 1 is a diagram illustrating a system in which one embodiment of the invention can be practiced.
  • the system 100 comprises: (a) at least one portable electronic book 10 operative to request a digital content from a catalog of distinct digital contents, to receive and display the requested digital content in readable form; (b) an information services system 20 which includes an authentication server 32 for authenticating the identity of the requesting portable electronic book 10 and a copyright protection server 22 for rendering the requested digital content sent to the requesting portable electronic book 10 readable only by the requesting portable electronic book 10; (c) at least one primary virtual bookstore 40 in electrical communication with the information services system 20, the primary virtual bookstore being a computer-based storefront accessible by the portable electronic book and including the catalog of distinct digital contents; and (d) a repository 50, in electrical communication with the primary virtual bookstore 40, for storing the distinct digital contents listed in the catalog.
  • the system 100 preferably includes more than one portable electronic book 10, to be commercially viable. This is illustrated in Figure 1 by including the portable electronic books 12 and 14.
  • the system also preferably includes more than one primary virtual bookstore 40, each serving a different set of customers, each customer owning a portable electronic book.
  • the system 100 further comprises a secondary virtual bookstore 60 in electrical communication with the information services system 20.
  • the information services system 20 also includes a directory of virtual bookstores 26 in order to provide the portable electronic book 10 with access to the secondary virtual bookstore 60 and its catalog of digital contents.
  • the information services system 20 can optionally include a notice board server 28 for sending messages from one of the virtual bookstores, primary or secondary, to a portable electronic book in the system.
  • the information services system 20 also includes a registration server 24 for keeping track of the portable electronic books that are considered active accounts in the system and for ensuring that each portable electronic book is associated with a primary virtual bookstore in the system.
  • the registration server 24 also allows each portable electronic book user to define his/her own notice board and document delivery address.
  • the information services system 20 preferably comprises a centralized bookshelf 30 associated with each portable electronic book 10 in the system.
  • Each centralized bookshelf 30 contains all digital contents requested and owned by the associated portable electronic book 10.
  • Each portable electronic book 10 user can permanently delete any of the owned digital contents from the associated centralized bookshelf 30. Since the centralized bookshelf 30 contains all the digital contents owned by the associated portable electronic book 10, these digital contents may have originated from different virtual bookstores.
  • the centralized bookshelf 30 is a storage extension for the portable electronic book 10. Such storage extension is needed since the portable electronic book 10 has limited non-volatile memory capacity.
  • the user of the portable electronic book 10 can add marks, such as bookmarks, inking, highlighting and underlining, and annotations on a digital content displayed on the screen of the portable electronic book, then stores this marked digital content in the nonvolatile memory of the electronic book 10.
  • the user can also upload this marked digital content to the information services system 20 to store it in the centralized bookshelf 30 associated with the portable electronic book 10, for later retrieval. It is noted that there is no need to upload any unmarked digital content, since it was already stored in the centralized bookshelf 30 at the time it was first requested by the portable electronic book 10.
  • the information services system 20 further includes an Internet Services Provider (ISP) 34 for providing Internet network access to each portable electronic book in the system.
  • ISP Internet Services Provider
  • Figure 1 further illustrates that the electronic books 10, 12, and 14 are used in the field.
  • the electronic book 10 may be upgraded via the Internet or an upgrade ROM/ flash cartridge 270.
  • FIG. 2 is a diagram illustrating an environment for storing static data and field update according to one embodiment of the invention.
  • the environment 200 includes a development/manufacturing stage 205 and a field use stage 206.
  • the development/manufacturing stage 205 includes the development of prototypes and manufacturing of final products . During prototype development or product manufacturing, the development/manufacturing stage 205 stores static data in the information retrieval programmable device.
  • the development/manufacturing stage 205 includes a resource file structure 210 and a read-only memory (ROM) /flash memory 220.
  • the resource file structure 210 is a database structure that organizes the static data in a predefined format.
  • the static data includes data whose values are not changed during program execution, or from execution to execution. Examples of the static data include the parse tables, images, user interface layout information, string constants, etc.
  • a resource file is a database that organizes the static data in a structured manner to facilitate information access and management.
  • the resource file structure 210 may include a number of resource files, each representing a resource type.
  • the resource file structure 210 is incorporated into the ROM/flash memory 220.
  • the ROM/flash memory 220 represents a storage system in the information retrieval programmable unit .
  • the ROM/flash memory 220 may be implemented by semiconductor memories such as programmable read-only memory (PROM) or flash memory.
  • PROM programmable read-only memory
  • the ROM/flash memory 220 normally stores the program code that is executed by the processor in the information retrieval programmable unit . Storing the static data in the program code instead of a disk system provides a number of advantages. First, the ROM/flash memory 220 is more compact, light, reliable, and faster than a disk system. Static data can be retrieved quickly, reducing start-up time when the unit is initialized at power-up. Second, there is no need to use valuable random access memory (RAM) storage space to store the static data transferred from the disk system.
  • RAM random access memory
  • the updating of the static data can be conveniently and efficiently performed at the field merely by replacing or reprogramming the ROM/flash memory 220.
  • the integrity of information is maintained by storing static data together with program code in the same physical ROM/flash memory. The synchronization of information storage is guaranteed when the ROM/flash memory 220 is programmed.
  • the program code in the ROM/flash 220 includes a static data structure 222 and an executing code 224.
  • the static data structure 222 contains the static data transferred or compiled from the resource file structure 210.
  • the static data structure 222 has a simple data structure that allows direct access by the processor.
  • the executing code 224 is the code that is executable by the processor.
  • the processor can access the static data structure 222 by executing the appropriate portion of the executing code 224.
  • the executing code 224 also contains other functions, routines, subprograms, etc. that allows the processor to perform the intended tasks of information retrieval in the programmable unit .
  • the field use stage 206 is the stage when the unit is finalized and is used in the field, either by the user or by the field technician.
  • the field use stage 206 includes the field unit 240.
  • the field unit 240 represents the final product.
  • the field unit 240 includes a programmed ROM/flash memory 250, a processor 255, and a remote port 260.
  • the programmed ROM/flash memory 250 is the ROM/flash memory 220 that has been programmed with the static data in the development/ manufacturing stage 205.
  • the processor 255 is any processor that can execute the code contained in the programmed ROM/flash memory 250 and access the static data structure embedded in the program code .
  • the remote port 260 represents a communication port that allows an upgrade ROM/flash cartridge 270 to update the programmed ROM/flash memory 250.
  • the upgrade ROM/ flash cartridge 270 contains the updated program code that replaces the program code stored in the programmed ROM/ flash memory 250.
  • the replacement of the programmed ROM/flash memory 250 can be performed by transferring the contents of the upgrade ROM/flash cartridge 270. The transfer can be done locally or remotely via a communication network.
  • the use of a remote upgrade provides a fast, efficient, and convenient upgrading procedure.
  • Figure 3 is a diagram illustrating the resource file structure 214 of a resource file representing the static data according to one embodiment of the invention.
  • a resource file is a hierarchical organization of resource data as static data.
  • the static data may be organized as a multi-level data structure.
  • the resource file has two tiered data objects, or two levels.
  • the first level is the resource type and the second level is the resource identification (ID).
  • the resource file structure 214 has four fields: a type field 310, an ID field 320, a name field 330, and a data field 340.
  • the type field 310 indicates the resource type.
  • the type field 310 has N types from TYPE_1 to TYPE_N.
  • the type field is 32-bit or 4-byte long.
  • the ID field 320 indicates the ID code for the corresponding static data.
  • the ID field 320 is 16-bit long.
  • a resource type may have a number of different ID's.
  • the resource TYPE_1 has one ID, ID_1, and the resource TYPE_N has two ID'S, ID_N1 and ID_N2.
  • the name field 330 is optionally provided to give the ID a descriptive name. It is represented by a string key.
  • the ID_1 has a NAME_1
  • the ID_N1 has a NAME_N1
  • the ID_N2 has a NAME_N2.
  • the data field 340 is the value of the corresponding ID. The length of the data field depends on the ID of the data. In the example shown in Figure 3, the ID_1 has DATA_1, the ID_N1 has DATA_N1, the ID_N2 has DATA_N2.
  • the resource file structure 210 is included as part of the source code of the program code .
  • the source code of the program code is compiled and the machine code for the program code is produced which include the corresponding static data represented as the resource file.
  • the machine code is then programmed to the ROM/flash memory for final unit.
  • the organization of the static data in the machine code has a simple data structure to allow fast access.
  • Figure 4 is a diagram illustrating a data structure 400 of a resource file on a ROM/flash program code according to one embodiment of the invention.
  • the data structure 400 of the embedded static data as compiled from the source code follows the resource file structure 210.
  • additional fields are provided.
  • the name length field specifies the length of the name.
  • the data length field specifies the length of the data field. Using the lengths of the name and data fields, it is possible to determine the address (or pointer) of any item in the resource file.
  • the data structure 400 includes a version stamp 410, type blocks 4201 through 420N, and an end of resource file indicator 430.
  • the version stamp 410 is the version of the resource file to provide a track history for the resource file.
  • the version stamp 410 provides a means for record keeping and for field upgrade.
  • the type blocks 4201 to 42ON are the static data organized according to TYPE.
  • Each type block has three major parts: a TYPE part, a DESCRIPTOR part, and an END_OF_TYPE part.
  • the DESCRIPTOR part contains the fields as described in Figure 3 with the addition of two fields: the NAME_LENGTH and DATA_ ENGTH fields which show the length of the name and the data, respectively.
  • the type block 4201 has a part TYPE_1 4301, the DESCRIPTOR_l part 4401, and an END_OF_TYPE_l part 4601.
  • the DESCRIPTORS part 4401 includes the following fields: ID_1 4421, name length_l 4441, NAME_1 446, DATA LENGTH_1 4481, DATA_1 4501, and END_OF_TYPE_l 4601.
  • the type block 420N has a TYPE_N part 430N, a DESCRIPT0R_N1 part 440N1, a DESCRIPTOR_N2 part 440N2, and an END_OF_TYPE_N part 46ON.
  • the DESCRIPT0R_N1 part 440N1 has the following fields: ID_N1 442N1, NAME_LENGTH_N1 444N1, NAME_N1 446N1, DATA_LENGTH_N1 448N1, and DATA_N1 450N1.
  • the DESCRIPT0R_N2 part 440N2 has the following fields: ID_N2 442N2, NAME_LENGTH_N2 444N2 , NAME_N2 446N2, DATA_LENGTH_N2 448N2, and DATA_N2 50N2.
  • the end of resource file indicator 430 is a delimiter code to indicate the end of the resource file.
  • Figure 5 is a flowchart illustrating a process 500 of retrieving resource information according to one embodiment of the invention.
  • the process 500 obtains the pointer for the resource file (Block 510) .
  • the pointer is the address offset stored in some fixed location or part of the execution code to allow the processor to point to the beginning of the data structure.
  • the process 500 obtains the number of types in the resource file (Block 520), and the number of ID'S in each type (Block 530) .
  • the process 500 obtains the data lengths of the ID's in each type (Block 540) .
  • the process 500 determines the pointer for the ID k in TYPE j (Block 550) . Then the process 500 accesses the resource file for the specified type and ID using the pointer computed in block 550 (Block 560) . Then the process 500 is terminated.
  • Figure 6 is an example of a resource file according to one embodiment of the invention.
  • the resource file 600 has a name foo.RES.
  • the TYPE type has two resource ID's: 1001 and 1002.
  • the resource ID 1001 has a name "Namel” and a data "Datal”.
  • the resource ID 1002 has a name "Name2" and a data "Data2".
  • the TTOO type has one resource ID: -31782.
  • the resource ID -31782 has an empty name "" and a data "Data3" .
  • Figure 7 is a binary data 700 of the resource file shown in Figure 6 according to one embodiment of the invention.
  • the binary data 700 represents the static data in hexadecimal of the resource file shown in Figure 6.
  • the binary data 700 includes an address field 710 and a content field 720.
  • the address and content fields are in hexadecimal.
  • the address field 710 shows the addresses of the corresponding static data items.
  • Address location 00 contains the version number. In this example, the version number is 0001.
  • Address location 02 contains the resource type TYPE encoded as "54 59 50 45".
  • Address location 06 contains dummy information reserved for future use.
  • Address location 0A contains the offset for the resource file. This offset is used as a pointer to point to the logical beginning of the static data structure. The logical beginning of the static data structure is at address location 2A.
  • Address location 0E contains dummy data, reserved for other uses.
  • Address location 20 contains the value of "Data2" having 5 bytes “44 61 74 61 32".
  • Address location 25 contains the value of "Datal” having 5 bytes “44 61 74 61 31” .
  • Address location 2A contains the ID number 1002 or "03 EA" in hexadecimal.
  • Address location 2C contains the size of the data of ID number 1002 which is "Data2". The size of "Data2" is 5, so address location 2C contains "00 00 00 05".
  • Address location 30 contains the offset or pointer to point to "Data2". Since "Data2" is stored at address location 20, address location 30 contains "00 00 00 20".
  • Address location 34 contains the size of the resource name "Name2". The resource name "Name2" has 5 bytes, so address location 34 contains "00 05".
  • Address location 36 contains the code for "Name2" which is 5-byte long, "4E 51 6D 65 32".
  • Address location 3B contains the ID number 1001 or "03 E9" in hexadecimal.
  • Address location 3D contains the size of the data of ID number 1001 which is "Datal”. The size of "Datal” is 5, so address location 3D contains "00 00 00 05".
  • Address location 41 contains the offset or pointer to point to "Datal”. Since "Datal" is stored at address location 25, address location 41 contains "00 00 00 25".
  • Address location 45 contains the size of the resource name "Namel” . The resource name "Namel” has 5 bytes, so address location 45 contains "00 05".
  • Address location 47 contains the code for "Namel” which is 5-byte long, "4E 51 6D 65 31".
  • Figure 8A is a source code to store the static data for a target processor shown in Figure 7 according to one embodiment of the invention.
  • the first version compiled under the compiler directive #if defined (_MC68K_) is for the target programmable device platform. In this example, it is a Motorola 68000 family processor. This version is coded as a "procedure" having a collection of in-line functions . The code is compiled and linked directly into a ROM/flash storable and executable module.
  • Figure 8B is a source code to store the static data for a non-target processor shown in Figure 7 according to one embodiment of the invention.
  • the second version is built as initialized data for use on non-target platforms.
  • the present invention provides a simple and efficient technique to store static data on an information retrieval programmable device.
  • the static data are organized as a resource file which is compiled together with the program code and stored on a ROM/ flash memory.
  • the technique allows fast access and convenient field update.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé et un dispositif permettant de stocker des données statiques dans une mémoire, ces données étant représentées d'après une structure de fichier des ressources et incorporées à un code source de code d'exécution. Le code source fait l'objet d'une compilation, de manière à fournir un code machine englobant les donnée statiques et le code d'exécution. Le code machine est transféré à la mémoire. Le procédé considéré permet d'accéder à une zone dans une structure de données intégrée à un code de programme. La zone correspond à un élément de structure. On obtient un pointeur de zone, qui est enregistré dans la structure de données. La zone est ensuite récupérée au moyen du pointeur.
PCT/US1999/024242 1998-10-16 1999-10-15 Stockage de donnees statiques pour acces et extension de zone efficaces WO2000023885A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU12088/00A AU1208800A (en) 1998-10-16 1999-10-15 Storage of static data for efficient access and field upgrade

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17397698A 1998-10-16 1998-10-16
US09/173,976 1998-10-16

Publications (1)

Publication Number Publication Date
WO2000023885A1 true WO2000023885A1 (fr) 2000-04-27

Family

ID=22634300

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/024242 WO2000023885A1 (fr) 1998-10-16 1999-10-15 Stockage de donnees statiques pour acces et extension de zone efficaces

Country Status (2)

Country Link
AU (1) AU1208800A (fr)
WO (1) WO2000023885A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6983457B2 (en) * 2000-10-25 2006-01-03 Hitachi, Ltd. Compile method for storing source code within object code
WO2007040419A1 (fr) * 2005-10-04 2007-04-12 Georgy Mikhailovich Shagov Procede d'assemblage (de montage) d'un logiciel
CN108334325A (zh) * 2017-12-26 2018-07-27 努比亚技术有限公司 一种编译方法、计算机及计算机可读存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998006033A1 (fr) * 1996-08-08 1998-02-12 Agranat Systems, Inc. Serveur web integre

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998006033A1 (fr) * 1996-08-08 1998-02-12 Agranat Systems, Inc. Serveur web integre

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"OS/2 2.0 Technical Library: Presentation Manager Programming Reference, Vol. III", 1992, IBM CORP., USA, XP002131217 *
"OS/2 Version 2.0 ; Volume 4: Application Development", April 1992, IBM INTERNATIONAL TECHNICAL SUPPORT CENTERS, USA, XP002131216 *
CAROLINE ROSE ET AL: "Inside MacIntosh; Volumes I, II and III", October 1991, ADDISON-WESLEY PUBLISHING CO., XP002131215 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6983457B2 (en) * 2000-10-25 2006-01-03 Hitachi, Ltd. Compile method for storing source code within object code
WO2007040419A1 (fr) * 2005-10-04 2007-04-12 Georgy Mikhailovich Shagov Procede d'assemblage (de montage) d'un logiciel
CN108334325A (zh) * 2017-12-26 2018-07-27 努比亚技术有限公司 一种编译方法、计算机及计算机可读存储介质

Also Published As

Publication number Publication date
AU1208800A (en) 2000-05-08

Similar Documents

Publication Publication Date Title
CN100498703C (zh) 以存储技术抽象方式在文件内创建文件系统
CN1641583B (zh) 自描述软件映象更新组件
CN100524210C (zh) 用于为组件创建语言中立和对应的语言专用资源文件的方法和系统
US9451203B2 (en) Downloading file reception process
AU2019283779A1 (en) Methods, systems, apparatus, products, articles and data structures for cross-platform digital content
JP3939923B2 (ja) 論理的ハイパーリンクを備えた知識供給装置
WO2002019652A2 (fr) Systeme et procede de transmission et d'extraction de donnees par l'intermediaire d'un cadre de persistance reparti
US20020069192A1 (en) Modular distributed mobile data applications
US20060069712A1 (en) System and method providing multi-tier applications architecture
KR20090035044A (ko) 네트워크에서의 생성자와 콘텐츠 서버 간의 업데이트 패키지 전송을 위한 업데이트 패키지 카탈로그
WO2003083688A1 (fr) Systeme de telechargement de dispositif mobile
CN113296854B (zh) 一种数据加载方法、系统、电子设备及存储介质
WO2008059257A1 (fr) Système informatique permettant de fournir des composants logiciels sur demande à un dispositif mobile
EP1573595A2 (fr) Navigation de l'espace de contenu d'un ensemble de documents
WO1999022501A1 (fr) Systeme et procede de communication
US9037966B2 (en) System and method for schema evolution in an E-commerce network
JP2004506968A (ja) データ処理装置、方法、及びシステム
CN109426515A (zh) 升级包的生成方法及装置
WO2008102221A1 (fr) Jeton personnel ayant des capacités améliorées pour distribuer des données html
US6980994B2 (en) Method, apparatus and computer program product for mapping file handles
US20080065750A1 (en) Location and management of components across an enterprise using reusable asset specification
EA001598B1 (ru) Переносимая защищенная система осуществления транзакций для программируемых устройств с микропроцессорами
US8719812B1 (en) Methods, systems, and computer readable media for dynamically modifying and utilizing a software package description for software installation
US20050050516A1 (en) Framework for providing and using schema data for markup languages
GB2360376A (en) Method and system for keeping files current in a network enabled computer

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref country code: AU

Ref document number: 2000 12088

Kind code of ref document: A

Format of ref document f/p: F

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase