Method and system for creating and maintaining version-specific properties in a distributed environment

[0001] [Technical field to which the invention belongs] The present invention relates generally to distributed computing environments, and more specifically to the formatting and management of object properties stored as part of each object in a particular system. More specifically, the present invention relates to the use of object properties to provide status information to third party applications. [0002] [Conventional technology] In a distributed environment such as the Internet, computer information is usually stored in units called "resources" or "objects". A resource is a Uniform Resource Locator (URL) or Uniform Resource. It can be any entity that can be accessed on the Web via an Identifier (URI). A collection of groups of resource members is called a "collection". The advantage of grouping resources is about the fact that once a resource group is grouped, it can be processed in the same way as computer files in a non-distributed environment, in this case files and resource collections. Both have data and metadata, respectively. The data is the actual target data for either the object or the resource, and the metadata is the information representing the contents of the file or the resource, which may be data. [0003] With the widespread use of the Internet and other distributed environments, improvements have also been made to the typical functions that client systems use when interacting with server systems and resources on them. For example, Hypertext Transfer Previous protocols, such as Protocol (HTTP) version 1.1, were the ability to "put" information into server-side applications and documents. The client uses a specific Hypertext Markup Language (HTML) request with a "PUT" command in the header. The server then interprets this header information and executes the command. [0004] Recent developments have increased the concept of authoring resources on a server system from a client system over a distributed network. One prominent example of this is the development of the WebDAV standard, which stands for the World Wide Web Distributed Authoring and Versioning standard, and is now simply referred to as "DAV" herein. DAV provides a set of headers and methods, with HTTP extended to provide functionality for overwrite protection (locking), properties, and namespace management. Created by the IETF and proposed by the IESG A document approved as standard) RFC 2518 was published in February 1999, and DAV is described in more detail in this standard. [0005] DAV creates a property object associated with a resource, which is similar to the file properties used in traditional file systems. Properties can store information such as the name of the resource, the author of the resource, and the latest version number of the resource (or resource collection). [0006] Third-party applications often provide additional system characteristics or functionality, such as virus scanning capabilities, in combination with server-side resource systems. These third-party applications can either "intercept" access attempts for their respective resources to scan for virus targets, or perform other tests before performing actual access operations. However, scanning and other tests every time a resource is accessed can be time consuming. Therefore, it is possible to keep a log of information that stores the version information of each resource. For example, a log can keep a list of resources on the system, whether each resource was scanned, and if so, what version of the virus definition file was used. Virus scanners can use the log of this information to reduce processing time by scanning only new or modified resources, or resources scanned by old virus definition files. [0007] Systems that always scan every resource before access can be greatly improved by using logs, but there are drawbacks to using such logs. For example, significant overhead is required to maintain such information logs. In addition, the process of accessing the log to determine if each item has been scanned must place a separate file on the disk and examine it, which reduces overall system performance. In addition, the information log is not updated when resources are copied or backed up, which can lead to unwanted scanning behavior in some situations. [0008] One way to solve the performance degradation problem caused by keeping information logs as separate files is to keep volatile memory, for example "in-memory" logs created and stored in RAM. It is to be. Since access to the in-memory log is faster than that to another file, using the in-memory log instead of the above log file improves system performance. However, the in-memory log is erased or lost when the system is powered off, such as when the system is turned off, shut down, or rebooted. Therefore, it may not be possible to immediately identify the status information or version information after the power is stopped. Another drawback associated with in-memory logs is that such logs consume large amounts of operational memory used by the system. Therefore, in-memory logs do not provide an appropriate solution to the above problems. [0009] [Problems to be Solved by the Invention] One object of the present invention is to provide a solution for the above or other considerations. Therefore, an object of the present invention is to create and maintain a version-specific property or a property stored as part of an object in a distributed environment, and store version-specific information about when and how the property was created. The purpose is to provide a method and system that is automatically disabled when a given "update" event occurs. [0010] [Means for solving problems] The invention is stored as part of a collection of resources or objects, stores version-specific information about when and how a property was created, and is automatic when a given "update" event occurs. Resolve these issues by creating and using version-specific attributes or properties that are invalid. Third-party applications can generally eliminate the need for external logs or databases by creating and accessing these version-specific properties. [0011] One aspect of the invention relates to a method of providing an application with version-specific information related to an object stored in a computer system. This method involves creating version-specific properties associated with the object and automatically disabling version-specific information in response to a given access request so that updates to the related object are always in the version-specific property. It includes making it reflected, as well as allowing third-party applications to analyze version-specific properties. [0012] According to another aspect of the invention, the application is a third party application, such as a virus scanning application or a replicator type application that makes redundant copies of data objects for backup or performance purposes. In addition, version-specific properties of the invention can include meta information, version information, and mask information. Version information relates to the version of the object itself or the application used to create the unique property, and mask information relates to the policy or definition of a given event that can invalidate the version-specific property. In other embodiments, the version-specific property also provides a validation element to other applications to prevent unauthorized access to the property or data object, or to determine if a data object is corrupted. Can include digital signatures or other security information to be used. [0013] According to another aspect of the invention, a version-specific property is based on a given event, such as modifying data in an object or metadata associated with the object, or when other version-specific properties change. It can be disabled. The invalidation action may be the deletion or truncation of the version-specific property, or other means of indicating that the version-specific property is invalid. [0014] According to another aspect, the present invention relates to an object format having version-specific properties. Version-specific properties include a meta information section, a version information section to store information about the version of the application that created the property, and a mask information section to store information about a given event that causes the property to be invalidated. There is. Furthermore, the present invention also relates to a system that provides a protocol for creating and retaining such version-specific properties. [0015] The present invention can be implemented as products such as computer processes, computing systems, and computer program products. The computer program product may be a computer system and a computer storage medium that can be read by encoding computer program instructions to perform computer processes. Further, the computer program product may be a propagating signal on a carrier that can be read by encoding a computer program instruction to execute a computing system and a computer process. [0016] A more complete understanding of the invention and its improvements is provided by reference to the accompanying drawings briefly described below, the following detailed description of current preferred embodiments of the invention, and the appended claims. Can be done. [0017] BEST MODE FOR CARRYING OUT THE INVENTION The present invention relates to a data object model that creates version-specific properties, or properties that define or provide meta information about a data object. Other than that, version-specific properties can be stored in association with a data object, either through a meta-information identification pointer or by making it resident with the data object itself. Similar to the data object property of. However, version-specific properties have features that are relatively different from existing meta-information properties, including the ability to store version-specific information about the application that created the version-specific property. In addition, version-specific properties are automatically updated as soon as a given event occurs. In fact, information about the event that causes the invalidation may also be stored as part of the version-specific properties. [0018] FIG. 1 is a diagram showing an example of a suitable computing system environment 100 in which the present invention can be implemented. The computing system environment 100 is merely an example of a suitable computing environment and is not intended to impose any restrictions on the scope of use or functionality of the present invention. Furthermore, the computing environment 100 does not have any dependency or requirement with respect to any one component or combination thereof exemplified in the exemplary operating environment 100. [0019] In addition to the environment 100 shown in Figure 1, the invention is capable of operating in a number of other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use in the present invention include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, and settops. Includes, but is not limited to, boxes, programmable home electronics, networked PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the above systems or devices. [0020] Furthermore, the present invention can be described in the context of general computer executable instructions, such as program modules executed by a computer. Program modules typically include routines, programs, objects, components, data structures, etc., which either perform specific tasks or perform specific abstract data types. The present invention can also be implemented in a decentralized computing environment where tasks are performed by remote processing devices linked over a communication network. In a distributed computing environment, program modules can be located on both local and remote computer storage media, including memory storage devices. [0021] [0021] Referring to FIG. 1, exemplary systems for carrying out the present invention include general purpose computing devices in the form of computer 102. The components of the computer 102 include, but are not limited to, a processing unit 104, a system memory 106, and a system bus 108 that connects various system components, including system memory, to the processing unit 104. .. The system bus 108 can be any of several types of bus structures, including memory buses or memory controllers, peripheral buses, and local buses that use any of the various bus architectures. To give an example, but not limited, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architectures (MCA) bus, Extended ISA (EISA) bus, and Video Electronics Standards Association (VESA) local. Bus, and Peripheral Component, also known as mezzanine bus Includes the Interconnect (PCI) bus. [0022] Computer 102 typically includes various computer readable media. The computer-readable medium may be any usable medium accessible to the computer 102, including both volatile and non-volatile media, removable and non-removable media. By way of example, but not by limitation, computer readable media can include computer storage media and communication media. Computer storage media are volatile and non-volatile, removable and non-removable, implemented by any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Both media are included. Computer storage media include RAM, ROM, EEPROM, flash memory, or other memory technology, CDE-ROM, digital general purpose disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other. It includes, but is not limited to, magnetic storage devices, or other media that can be used to store desired information and are accessible to the computer 102. [0023] A communication medium typically embodies a computer-readable instruction, data structure, program module, or other data with a modulated data signal such as a carrier wave or other transport mechanism, any information transmission medium. including. The term "modulated data signal" means a signal having one or more of its feature sets, or a signal modified by a method of encoding information within the signal. By way of example, but not by limitation, communication media include wired media such as wired networks or direct line connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Is included. When any of the above is combined, it shall be within the range of computer readable media. [0024] System memory 106 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 110 and random access memory (RAM) 112. The basic I / O system 114 (BIOS), which contains basic routines that help transfer information between elements in computer 102, such as at boot time, typically has a ROM. Stored in 110, RAM 112 typically contains files and / or program modules that are immediately accessible and / or are currently running by processing unit 104. By way of example, but not by limitation, FIG. 1 illustrates an operating system 132, an application program 134, other program modules 136, and program data 138. Further, the computer 102 includes a file system that defines the file format of the system 102 and defines the version-specific property format, as described below. [0025] Computer 102 may also include other removable / non-removable, volatile / non-volatile computer storage media. To give an example only for illustrative purposes, FIG. 1 shows a hard disk drive 116 that reads / writes to and from a non-removable, non-volatile magnetic medium, and a removable, non-volatile magnetic disk 120 that reads / writes. Writing magnetic disk drive 118, and CD An optical disk drive 122 that reads / writes to and from a removable, non-volatile optical disk 124, such as a ROM or other optical medium, is exemplified. Other removable / non-removable, volatile / non-volatile computer storage media that can be used in an exemplary operating environment include magnetic tape cassettes, flash memory cards, digital general purpose disks, digital videotapes, solid-state RAM, and solid-state. ROM and the like are included, but the present invention is not limited to these. Hard disk drive 116 is typically connected to system bus 108 via a removable memory interface such as interface 126, and magnetic disk drive 118 and optical disk drive 122 are typically memory such as interfaces 128 and 130, respectively. The interface connects to system bus 108. [0026] The drives described above and illustrated in FIG. 1 and their associated computer storage media store computer-readable instructions, data structures, program modules, and other data relating to the computer 102. For example, in FIG. 1, hard disk drive 116 is shown as storing operating system 132, application program 134, other program modules 136, and program data 138. [0027] The user can enter commands and information into the computer 102 via an input device such as a keyboard 140 and a pointing device 142, commonly referred to as a mouse, trackball, or touchpad. Other input devices (not shown) can include microphones, joysticks, gamepads, satellite dishes, scanners, and the like. These and other input devices are often connected to the processing unit 104 via an input interface 148 coupled to system bus 108. The monitor 150 or other type of display device can also be connected to the system bus 108 via the video adapter 152. In addition to the monitor, the computer can also include other peripheral output devices such as speakers and printers (not shown). [0028] Computer 108 can operate in a network environment that uses a logical connection to one or more remote computers, such as remote computer 154. The remote computer 154 may be a personal computer, server, router, network PC, peer device, or other common network node and typically includes many or all of the elements mentioned above with respect to the computer 102. [0029] When used in a LAN network environment, the computer 102 is connected to the LAN via a network interface or adapter 162. When used in a WAN network environment, the computer 102 typically includes a modem 164 or other means for establishing communication over a WAN, such as the Internet. Modem 164 may be internal or external and can be connected to system bus 108 via user input interface 148 or other suitable mechanism. In a network environment, a program module or part thereof depicted in connection with computer 102 can be stored in a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing communication links between computers can also be used. [0030] FIG. 2 is a diagram showing an example of a software operating environment 200 in which the present invention can be implemented. The software operating environment 200 is merely an example of a suitable operating environment and is not intended to limit the scope of use or functionality of the present invention. Software environment 200 has an XML store 202 that defines the format and structure of data objects such as data objects 204, 206, 208, and 210. Usually XML Store 202 also provides the entire structure in which objects are named, stored, and organized. In addition, this store provides a protocol for accessing any object in store 202. Although illustrated in connection with the XML store, the configuration or collection of other data objects can incorporate aspects of the invention. Data objects 204, 206, 208, and 210 are XML data objects that represent actual file type data. Data objects 204, 206, 208, and 210 can be accessed and / or modified by the user or other program modules. Of course, the XML store 202 can contain many other objects, as indicated by the ellipsis 223 and 225. [0031] Typically, each data object 204, 206, 208, and 210 has some form of meta-information object (not shown) associated with each object, where the meta-information is the author of the object, the object last. Includes information such as time accessed, etc. This meta information can be stored as part of a data object or as part of a pointer or other object that has some other identifying element that associates the meta information object with that particular data object. [0032] In addition to meta information objects, data objects can also be associated with version-specific property objects such as objects 220 and 222. Version-specific properties 220 and 222 are associated with data objects 208 and 210, respectively. Version-specific properties 220 and 222 contain version-specific information and can be overridden by other events that occur with respect to objects 208 and 210, respectively. [0033] The software environment 200 shown in Figure 2 also illustrates the interaction between the XML store 202 and application programs such as applications 224 and 226. In one embodiment, application program 226 is a client application program that runs on a client system that is separate from the server system where the XML store 202 is located. In other embodiments, the application program, or program 224, may actually be part of the server system. Applications 224 and 226 interact with XML Store 202 through application program interfaces 228 and 230, respectively. In addition, the application interface 230 can actually communicate with the XML store 202 over a complex network such as the Internet 232 according to a predefined protocol. In the present invention, it is important that an application or program module such as applications 224 and 226 interacts with the XML store 202 in some way in order to access data objects such as objects 204, 206, 208, and 210. Access includes moving, copying, deleting, reading, executing, or updating objects. [0034] Application programs 224 and 226 can access objects 204, 206, 208, and 210 through a layer of application modules, namely service layer 236. The service layer 236 can provide various functions such as that the object access request is related to an existing object and whether the module making the request has permission to make and execute the request. This interactive layer 236 can be application program interfaces 228, 230, as well as operating system interfaces (not shown) that may be part of a client or server computer system. [0035] In one embodiment of the invention, with respect to version-specific properties 220 and 222, application programs 224 and 226 can create and use version-specific properties 220 and 222 with respect to objects 208 and 210, respectively. Alternatively, service layer 236 can create and use version-specific properties. Once a version-specific property is created, other applications can access it and make decisions about performing actions on the object based on the evaluation of the version-specific property 220 or 222. In addition, the other application can perform actions on data objects that can disable version-specific properties that would produce different results when the application tests for the presence of valid version-specific properties. [0036] In a particular example, service layer 236 provides a virus scanning function that performs a virus scanning and cleaning function each time an object, such as object 204, 206, 208, or 210, is accessed by any other application or module. provide. To further expand this example, application program 224 may be a word processing application, objects 204, 206, 208, and 210 are word processing type objects such as XML objects with specific text components. In such cases, the virus scanning program module can be used as part of service layer 236 to scan the objects that the word processing application 224 actually requests access to. In this example, the virus scanner can create version-specific properties, such as properties 220 and 222 of the virus-scanned object. Therefore, if application 224 then makes a request for one of objects 208 and 210, the virus scanning application will determine if other scanning operations are required, such as properties 220 and 222. It only identifies the presence or absence of valid version-specific properties for. No scan is required in this particular example if valid version-specific properties are identified. On the other hand, if version-specific properties are not identified, such as when accessing objects 204 or 206, the virus scanning application states that these objects have not been scanned or have been scanned and then fixed. recognize. [0037] Looking further at the virus scanning example, assuming that the virus scanning application scans one of objects 204 or 206 as part of layer 236, a new version-specific property (not shown) is created. , Related to scanned objects. The newly created property (not shown) is then stored with the object so that it can be used for future access requests. [0038] In other embodiments, version-specific properties can be encoded using digital signatures that can be accessed and evaluated by other applications. The digital signature can then be examined to determine if the file is a valid copy. In such cases, if the file has been arbitrarily modified by another application, that is, it has been corrupted, the digital signature will be invalid. An invalidated digital signature is treated as if the signature did not exist, so the data object can be treated as invalid. [0039] Version-specific attributes can include additional security information to prevent unauthorized access to the attribute or data object. Service layer 236 uses this information as a means of locking properties to prevent inappropriate applications, such as virus applications, from using it. The service layer can be configured to evaluate version-specific properties on a per-access basis to ensure that only valid applications access the property or the data object itself. [0040] A collection of objects 300 incorporating the present invention is shown in FIG. Collection 300 has data objects 302 with respect to the actual object information. In addition, collection 300 has meta information object 304, which in this particular example contains general information including some standard properties such as time and object size. In other embodiments, the meta information object 304 does not contain standard properties, instead the standard properties may be stored in another object (not shown). [0041] Collection 300 also has a version-specific property 306, as shown in FIG. Version-specific property 306 contains three types of information. One of them is Meta Information Section 308, which typically includes the name of the property, such as the name of the third-party application used to create the property, as well as the length of the property, its address location on disk, etc. Has information on. [0042] Version-specific property 306 also includes version information section 310. Version Information Section 310 contains information about the latest specific application version used to create version-specific property 306, such as the version of the third-party application used to create the property. That is, such version information can be associated with the program module that is evaluating the property, so a section is dedicated to this type of information. [0043] Version-specific property 306 also includes mask information section 312, which is used to provide information about related updates to the server system. Mask information section 312 essentially tells other applications or server systems which protocol or policy event can or cannot disable version-specific property 306. [0044] In certain embodiments, when version-specific property 306 is created by the virus-scanning application, meta-information section 308 may retain the name of the virus-scanning application used to create version-specific property 306. In addition, version information section 310 will contain information related to the particular virus definition file used when version-specific property 306 was created. Version information is important in this particular case, as virus scanning applications are updated frequently to include recently detected viruses. Therefore, virus scanning applications must not only determine if an object has been previously scanned, but also whether it was scanned using an updated virus definition file. [0045] For mask information section 312, if a virus scanning application creates version-specific property 306, mask information section 312 may contain certain events that may cause the invalidation of version-specific property 306, which is an event. It may be uniquely directly related to the virus scanning application. In this particular case, such an event that may result in invalidation of property 306 includes modification of data object 302 by either adding new data or erasing data. In other embodiments, other predetermined events may cause invalidation of version-specific properties, such as modification of other properties related to data object 302 and the like. [0046] In this particular example, a read-only access event, object renaming, or object's to a given event where the version-specific property is not disabled because it cannot be specifically included in mask information section 312. Can include backups of collection 300. In fact, if the event does not invalidate the version-specific property, the property remains associated with object 302 even if the object is renamed. [0047] Version-specific property 306 is created by a third-party application, such as an application separate from the specific object store. When creating version-specific properties, the third-party application provides name, version, and mask information to the server system where the XML object is stored. The server system then creates a property and associates it with a particular data object. Alternatively, you can create a version-specific property and store it on the remote computer system while it is associated with the data object 302. [0048] In one embodiment of the invention, the version-specific property is WebDAV, an extension of HTTP as part of the World Wide Web Distributed Authoring and Versioning protocol (DAV). Originally, version-specific properties are a new type of DAV property, with the same degree of live / dead freedom as other DAV properties, that is, live properties are managed on the server side and dead properties are clients. It is managed on the side. To define new version-specific properties in DAV, you can implement the document type definitions (DTDs) shown in Tables 1-4. These samples are, of course, sketched. [0049] [table 1]<img file="JP4416366B2_D0001.tif" />[0050] [Table 2]<img file="JP4416366B2_D0002.tif" />[0051] [Table 3]<img file="JP4416366B2_D0003.tif" />[0052] [Table 4]<img file="JP4416366B2_D0004.tif" />[0053] To actually create version-specific properties, third-party properties use standard DAV mechanisms such as PROPPATCH and PUT. These mechanisms are described in detail in Appendix A. In alternative embodiments, these version-specific properties are created using other methods. [0054] Although collection 300 is illustrated and described as having only one version-specific property, collection 300 can also have other properties, including other version-specific properties. In fact, some third-party applications can require that persistence information be associated, thus creating a number of version-specific properties, such as property 306, and storing them with collection 300. Can be done. [0055] Although the exemplary physical environment has been discussed above, the following sections describe operating modules that embody aspects of the invention. The logical operations of the various embodiments of the invention are interconnected as (1) a series of steps or program modules performed by a computer running on a computing system and / or (2) within the computing system. It is implemented as a hardware module or a logical module. This implementation is a matter of choice depending on the performance requirements of the computing system in which the present invention is implemented. Therefore, the logical actions that make up the embodiments of the present invention described herein are sometimes referred to as actions, steps, or modules. [0056] FIG. 4 is a flow chart showing operating characteristics related to access to an object according to the embodiment of the present invention. Before flow 400 is started, objects such as objects 204, 206, 208, or 210 shown in FIG. 2 exist in an XML store such as store 202 (FIG. 2). In one embodiment of the invention, once an object is created, attempts to access that object initiate the flow 400 illustrated and described with respect to FIG. In reality, process 400 is started with access attempt 402, which is about reading, executing, or updating any object. Access attempts can be performed by a third party application such as application 224 (Figure 2) or by service layer 236 (Figure 2). [0057] Following the access attempt 402, the decision action 404 determines whether the access is an invalidated access. The determination of whether or not the access is invalid access includes the evaluation of the mask information in each version-specific property assuming that the access is accessing a plurality of specific objects. By evaluating the mask information, you can see what type of access to that object is requesting that certain version-specific properties be disabled. Therefore, by comparing the mask information with the actual access attempt, it is possible to know whether the version-specific property should be disabled. If decision action 404 identifies such a related update access attempt, the flow proceeds to YES invalidation action 406. [0058] [0058] In one embodiment of the invention, version-specific properties are created and used by virus scanning applications. In such a situation, the decision action 404 determines whether the access attempt is an update access involved, based on criteria set by the virus scanning application. That is, the virus scanning application predetermines what the relevant update access is, such as whether the access attempt modifies the actual object data by modifying the old data or adding new data. ing. For example, a particular virus scanning application may want its version-specific properties to be disabled whenever any changes are made to the data in an object, including the creation of new data. Invalidation does not occur if the changes relate only to version-specific properties or metadata or metadata of other objects. [0059] In an alternative embodiment, the Replicator application can create and use version-specific properties. In such cases, the Replicator application may want its version-specific properties to be disabled whenever any changes are made to either the object's data or its metadata. These particular version-specific properties are invalidated whenever changes are made that do not affect only the version-specific properties of this class. In this case, by defining a specific class, the existence of multiple replicators prevents the object from being repeated many times, and each replicator instance from one replicator application is a second replicator application. Will occur as needed for repetition by. [0060] The invalidation operation 406 invalidates the version-specific property. Invalidation of a version-specific property can, in one embodiment, be achieved by deleting or truncating the version-specific property. Alternatively, the invalidation action 406 marks the version-specific property or gives an indication that the property is otherwise invalid. Originally, the act of invalidating a property makes an application that relies on a version-specific property recognize that the version-specific property is invalid by setting its contents to an empty string. Must. Other methods of disabling a version-specific property can include disabling access or adding information to the version-specific property, or modifying the information contained therein. Invalidation 406 does not change other properties, such as properties related to the last access or write to the object. [0061] If the data object has multiple related version-specific properties, actions 404 and 406 are repeated for each version-specific property. [0062] Following the invalidation action 406, the access execution action 408 executes the requested access to the object. It is important that the act of performing access to an object begins after the version-specific property has been disabled. Otherwise, version-specific properties can become unreliable. Following the access execution operation 408, the flow 400 ends with the end operation 410. [0063] If the decision action 404 determines that the access attempt is not related to the invalidation access, the flow proceeds to the NO decision action 412. Decision action 412 determines whether the access depends on version-specific properties, for example, whether the access attempt is an access attempt by an application that uses the version-specific property to perform the action. For example, a virus scanning application that uses version-specific properties can generate an access attempt, in which case the decision action 412 is whether the access attempt was generated by such an application that uses version-specific properties. Judge whether or not. [0064] If the access attempt was not performed by an application that relies on version-specific properties, the flow proceeds to NO access execution action 408. The access execution operation 408 executes the first requested access operation. If the decision action 412 is followed by the access execution action 408, the access action is not related to the action requesting invalidation as determined by the decision action 404. For example, this access attempt may be related to a read operation in which the user cannot modify the actual data. Following the access execution operation 408, the process flow ends at 410 as described above. [0065] If the decision action 412 determines that the access depends on the version-specific property, the flow proceeds to the decision action 414 of YES. Decision action 414 analyzes the version-specific property to determine if it is valid. To determine if a property is valid, among other methods of determining whether a property is valid, whether the property exists, whether it is marked as invalid, or no information is available. Includes whether or not it has been truncated. If the decision act 414 determines that the property is not valid, the flow proceeds to the access execution act 416 for the invalid property of NO. [0066] In the execution act 416, a predetermined function is executed based on the determination that the access is invalid. In one embodiment, if the access attempt was generated by a virus scanning application, Execution Action 416 relates to performing such a virus scanning function on an object. [0067] Following the action execution 416 related to the invalid property, the version-specific property creation action 418 creates or enables the version-specific property for the object. Enabling version-specific properties involves creating version-specific properties for the object or adding information to existing version-specific properties. In other embodiments, by giving an indication that the property is valid, the property can be enabled in other ways as long as the property is later found to be valid. Following the version-specific property activation action 418, process 400 terminates with termination action 410. [0068] If the decision action 414 determines that the version-specific property is valid, the flow proceeds to the YES execution action 420. Execution action 420 relates to performing any action relating to the determination that the version-specific property is valid. Execution behavior 420 may contain different types of behavior, depending on the particular application that uses version-specific properties. In one example, if the property is determined to be valid, no action will be taken in a virus scan situation or the like. In such a case, if the decision action 414 determines that the version-specific property is valid, the object has been previously scanned and no other scan is needed. Therefore, no action is performed on that object, action 420 only passes control to termination action 410. In other embodiments, the operation may start at 420 if the version-specific property is determined to be valid. [0069] [Effect of the invention] The system and method described above is the traditional method of providing version information to a program module or application because the version information is part of an object or object collection rather than residing in another log or database file. Compared to, it is quite advantageous. The accessing application does not need to access external type files that may be unavailable, corrupted, or otherwise unmanageable. In addition, the property is not lost when the power is turned off, and the property does not consume a large amount of operating memory as in the case of in-memory information logging. In addition, the process is automatically updated, that is, version-specific information is invalidated when the relevant event occurs. In addition, the process is automatically updated, i.e., version-specific information is invalidated when a related event or update occurs. By automatically disabling version-specific information, related related updates are not missed and there is a high probability that unnecessary actions will not be performed. For example, when it comes to performing virus scanning, prior art methods did not retain such version information after the backup and / or copy functions, so additional processing steps were performed, but version information. Is no longer disabled by the backup and copy functions, so virus scanning is not required when accessing it in the future. [0070] As mentioned above, the invention described herein can be implemented as a product such as a computer process, computing system, or computer program product. The computer program product may be a computer system and a computer storage medium that can be read by encoding computer program instructions to perform computer processes. Further, the computer program product may be a propagating signal on a carrier that can be read by encoding a computer program instruction to execute a computing system and a computer process. [0071] Further, while the invention is described in a language specific to structural features and / or methodological steps, the invention defined in the appended claims is to the particular features or steps described. Please understand that it is not limited. As an example, other applications can take advantage of version-specific properties in addition to virus scanning applications and replicators. In addition, other types of objects and object stores other than XML object stores can also benefit from the principles of the invention. Therefore, the particular features and steps are disclosed as preferred embodiments of the described invention. [Simple explanation of drawings] FIG. 1 is a functional diagram of a computer system into which aspects of the present invention can be incorporated. FIG. 2 is a configuration diagram showing software components of the present invention. FIG. 3 is a functional diagram showing a component of a resource according to the present invention. FIG. 4 is a flow chart showing a functional feature of an embodiment of the present invention. [Explanation of symbols] 100 computing system environment 102 computer 104 Processing unit 106 System memory 108 system bus 110 ROM 112 RAM 114 BIOS 116 hard disk drive 118 magnetic disk drive 120 magnetic disk 122 optical disk drive 124 optical disc 126 Hard disk drive interface 128 magnetic disk drive interface 130 optical drive interface 132 Operating system 134 Application program 136 Program module 138 Program data 140 keyboard 142 Pointing device 148 User input interface 150 monitor 152 Video Adapter 154 Remote computer 162 Network interface 164 modem