Source: http://www.google.com/patents/US6910048?dq=5,973,252
Timestamp: 2016-02-06 22:05:44
Document Index: 46469431

Matched Legal Cases: ['Application No. 5', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 94', 'Application No. 95', 'Application No. 95', 'Application No. 95']

Patent US6910048 - Object oriented framework mechanism for data transfer between a data source ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsAn object oriented framework mechanism for data transfer between a data source and a data target provides an infrastructure that embodies the steps necessary to perform the data transfer and a mechanism to extend the framework to fit a particular data transfer environment. Certain core functions are...http://www.google.com/patents/US6910048?utm_source=gb-gplus-sharePatent US6910048 - Object oriented framework mechanism for data transfer between a data source and a data targetAdvanced Patent SearchPublication numberUS6910048 B1Publication typeGrantApplication numberUS 09/107,090Publication dateJun 21, 2005Filing dateJun 29, 1998Priority dateSep 30, 1996Fee statusLapsedAlso published asUS5915252Publication number09107090, 107090, US 6910048 B1, US 6910048B1, US-B1-6910048, US6910048 B1, US6910048B1InventorsDavid Joseph Misheski, Clifton Malcolm NockOriginal AssigneeNational Business Machines CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (30), Non-Patent Citations (103), Referenced by (7), Classifications (13), Legal Events (5) External Links: USPTO, USPTO Assignment, EspacenetObject oriented framework mechanism for data transfer between a data source and a data target
US 6910048 B1Abstract
at least one processor; a memory coupled to the at least one processor; and an object-oriented framework mechanism residing in the memory and executed by the at least one processor, the framework mechanism providing a user-extensible data transfer mechanism that transfers data from a data source to a data target according to portions of the framework mechanism that are extended by a user, wherein the framework mechanism comprises a user-extensible place class the place class defining: at least one place object corresponding to the data source; at least one place object corresponding to the data target; and a first set of object methods to transfer the data from the data source to the data target, at least one of the first set of object methods being extensible by a user. 2. The apparatus of claim 1 wherein the first set of object methods includes at least one object method that reads the data from the data source.
3. The apparatus of claim 1 wherein the first set of object methods includes at least one object method that writes the data to the data target.
4. The apparatus of claim 1 wherein a user extension of the place class defines the data source and the data target.
5. The apparatus of claim 1 wherein the framework mechanism further comprises:
a user-extensible source filter class, the source filter class determining the data to be transferred from the data source to the data target; user-extensible transfer condition class, the target mapping class determining at least one change to make to the data being read from the data source before writing the changed data to the data target. 6. The apparatus of claim 1 wherein the framework mechanism comprises at least one user-extensible source filter class, the source filter class defining:
at least one source filter object; and a third set of object methods that determine the data to be transferred from the data source to the data target. 7. The apparatus of claim 6 wherein the user extension of the source filter class defines the data to be transferred from the data source to the data target.
8. The apparatus of claim 1 wherein the framework mechanism comprises a user-extensible transfer condition class, the transfer condition class defining:
at least one transfer condition object; and a fourth set of object methods that determine at least one condition that must be satisfied for the data to be transferred from the data source to the data target. 9. The apparatus of claim 8 wherein the user extension of the transfer condition class defines the at least one condition that must be satisfied for data to be transferred from the data source to the data target.
10. The apparatus claim 1 wherein the framework mechanism comprises a user-extensible target mapping class, the target mapping class defining:
at least one target mapping object; and a fifth set of object methods that determine at least one change to make to the data being read from the data source before writing the changed data to the target. 11. The apparatus of claim 10 wherein the user extension of the target mapping class defines the at least one change to make to the data being read from the data source before writing the changed data to the data target.
12. The apparatus of claim 1 wherein the framework mechanism comprises:
at least one place object corresponding to the data source; at least one place object corresponding to the data target; a first set of object methods including at least one method for reading the data from the data source and at least one method for writing the data to the data target; at least one data transfer object that defines at least one user-defined data transfer environment, the data transfer object including a second set of object methods to transfer the data from the data source to the data target; at least one source filter object including a third set of object methods that determine the data to be transferred from the data source to the data target; at least one transfer condition object including a fourth set of object methods that determine at least one condition that must be satisfied for data to be transferred from the data source to the target; and at least one target mapping object including a fifth set of object methods that determine at least one change to make to the data being read from the data source before writing the changed data to the target. 13. The apparatus of claim 1 wherein the memory contains an application program that supports as object oriented programming environment containing the framework mechanism, and wherein the framework mechanism is extended by providing information that implements the at least one data transfer environment.
14. The apparatus of claim 1 wherein the framework mechanism comprises:
at least one core function defined by relationships between a plurality of classes within the framework mechanism, wherein the implementation of the at least one core function is defined by the framework mechanism and cannot be modified by a user of the framework mechanism; and at least one extensible function defined by at least one extensible class, wherein the implementation of the at least one extensible function is defined by the user of the framework mechanism by extending the at least one extensible class. 15. A method for transferring data from a data source to a data target, the method comprising the steps of:
(A) providing a user-extensible object oriented framework mechanism that performs the transfer of the data according to extended portions of the framework mechanism that are customized by a user to provide a data transfer environment wherein the framework mechanism comprises a user-extensible place class, the place class defining: at least one place object corresponding to the data source: at least one place object corresponding to the data target; and a first set of object methods to transfer the data from the data source to the data target, at least one of the first set of object methods being extensible by a user; and (B) executing the object oriented framework mechanism on a computer system. 16. The method of claim 15 further including the step of:
extending the framework mechanism to define the data transfer environment. 17. The method of claim 16 further including the steps of:
selecting at least one data source; selecting at least one data target; implementing the data transfer environment by defining the extended portions in accordance with the selected at least one data source and the selected at least one data target. 18. A program product comprising:
(A) an object-oriented framework mechanism for transferring data, the framework mechanism including a user-extensible data transfer mechanism that transfers data from a data source to a data target according to portions of the framework mechanism that are extended by a user, wherein the framework mechanism comprises a user-extensible place class, the place class defining: at least one place object corresponding to the data source; at least one place object corresponding to the data target; and a first set of object methods to transfer the data from the data source to the data target, at least one of the first set of object methods being extensible by a user; and (B) signal bearing media bearing the framework mechanism. 19. The program product of claim 18 wherein the signal bearing media comprises recordable media.
21. The program product of claim 18 wherein the first set of object methods in the place class includes at least one method to read the data from the data source and at least one method to write the data to the data target.
22. A user-extensible object oriented framework mechanism that transfers data from a data source to a data target, the framework mechanism comprising:
at least one core function defined by relationships between a plurality of classes within the framework mechanism, wherein the implementation of the at least one core function is defined by the framework mechanism and cannot be modified by a user of the framework mechanism; and at least one extensible class wherein the implementation of the at least one extensible class is defined by the user of the framework mechanism, by extending the at least one extensible class, thereby defining at least one user-defined data transfer environment for transferring data from the data source to the data target, the at least one extensible class including a place class the place class defining: at least one place object corresponding to the data source; at least one place object corresponding to the data target; and a first set of object methods to transfer the data from the data source to the data target, at least one of the first set of object methods being extensible by a user. 23. A program product comprising:
(A) a user-extensible object oriented framework mechanism for transferring data from a data source to a data target, the framework mechanism including at least one core function defined by relationships between a plurality of classes within the framework mechanism, wherein the implementation of the at least one core function is defined by the framework mechanism and cannot be modified by a user of the framework mechanism, the framework mechanism further including at least one extensible function defined by at least one extensible class, wherein the implementation of the at least one extensible class is defined by the user of the framework mechanism by extending the at least one extensible class, thereby defining a user-defined data transfer environment that governs the operation of the framework mechanism, wherein the at least one extensible class comprises a place class, the place class defining: at least one place object corresponding to the data source; at least one place object corresponding to the data target; and a first set of object methods to transfer the data from the data source to the data target, at least one of the first set of object methods being extensible by a user; and (B) signal bearing media bearing the object oriented framework mechanism. 24. The program product of claim 23 wherein the signal bearing media comprises recordable media.
This application is a divisional of U.S. Ser. No. 08/724,570 filed on Sep. 30, 1996 now U.S. Pat. No. 5,915,252 by Misheski et al., and entitled “Object Oriented Framework Mechanism for Data Transfer Between a Data Source and a Data Target”, which is hereby incorporated by reference in its entirety.
The start_zoo_admin( ) operation is responsible for starting ZAF. That is, a user or system administrator will interact with the start_zoo_admin( ) operation to begin administration of a zoo via ZAF. Once started, our framework designer has designed the start_zoo_admin( ) operation to initiate the 5_minute_timer( ) operation. Every five minutes, the 5_minute_timer( ) operation instructs the zoo keeper objects to go out and check on the animals. The add/delete_zoo_keeper operation is responsible for interacting with users of ZAF to define additional zoo keepers (i.e., additional zoo keeper classes), to add additional zoo keepers (i.e., zoo keeper objects), and to remove zoo keeper classes and/or objects. As will become clear in the forthcoming paragraphs, each zoo keeper object is responsible for performing a particular zoo task. Therefore, it is natural that a user of ZAF might well want to add a zoo keeper definition and object to handle an additional zoo task or to remove a definition or object that is no longer needed. As will be seen, this flexibility is provided by designing the zoo keeper mechanism as an extensible function.
It is important to note, though, that the common interface of a pure virtual operation definition must be honored by all subclasses such that requesting objects (called client objects) can use subclass member objects (called server objects) without needing to know the particular subclass of the server object. For example, whenever the object defined by the zoo administrator class needs a particular action performed, it interacts with a zoo keeper object. Because the interface to these objects was defined in abstract, base class zoo keeper and preserved in the subclass definitions for the check_animals operation, the zoo administrator object need not have special knowledge about the subclasses of any of the server objects. This has the effect of decoupling the need for the action (i.e., on the part of the zoo administrator object) from the way in which the action is carried out (i.e., by one of the objects of the zoo keepers subclasses). Designs (like the ZAF design) that take advantage of the characteristics of abstract classes are said to be polymorphic.
For the purposes of this framework overview, it is not necessary to explore each definition in detail. However, the temp_range data definition and the get_temp_range( ) and feed operation definitions are good examples of well thought out framework design choices.
Temp_range is a data definition for the range of temperatures that coincides with that of the specific animal's natural habitat and the get_temp_range( ) operation definition is designed to retrieve the temp_range for a specific animal and return it to a requesting client object. Subclass reptiles contains its own data definition for temp_range and its own definition for the get_temp_range( ) operation. ZAF has been designed this way to point out that data definitions can be overridden just like operation definitions. Since many reptiles live in desert conditions, where nights can be very cold and days very hot, the default temp range definition has been overridden in the reptiles class to include time and temperature information (not explicitly shown on FIG. 5). This is another good design choice because it allows ZAF to treat reptile containment units differently than other containment units by allowing temperature adjustments to be made based on the time of day as well as on the current temperature of the containment unit itself.
FIG. 7 is an object diagram showing how the example objects of ZAF interact to assist zoo personnel in operating the zoo. A detailed analysis of the interaction of all of the ZAF objects is unnecessary for the purposes of this overview. However, the reader should review the following simple control flow to obtain a rudimentary understanding of how objects interact to solve problems. p As mentioned, an object is created to be a member of a particular class. Therefore, Zelda the Zoo Administrator [object 706] is an object that is a member (actually the only member) of the zoo administrator class. As such, object Zelda is responsible for overall control of ZAF. All of the zoo keeper objects have registered with the Zoo Keeper Register object [object 700]. Therefore, object Zelda obtains a list of the current zoo keepers by calling the list_zoo_keeperso operation [step 1] of the Zoo Keeper Register object. The Zoo Keeper Register object has been created as a member of the zoo keeper register class. For the purposes of illustration, assume that this occurs every five minutes as part of Zelda's 5_minute_timer( ) operation. The Zoo Keeper Register object then responds with the zoo keepers list [step 2]. The list of zoo keepers includes Tina the Temperature Checker [object 714], Vince the Vet. [object 740], and Fred the Animal Feeder [object 752]. Each zoo keeper has been created as a member of the zoo keepers class. In particular, objects Tina the Temp. Checker, Vince the Vet., and Fred the Feeder are respectively members of the temperature controller, veterinarian, and feeder subclasses.
Object Tina's check_animal( ) operation then calls the get_temp_range( ) operations to get temperature ranges from objects Sam and Simba [steps 8 and 10]. Once the temperature ranges have been returned, the check_animals( ) operation of object Tina determines which containment units house the respective animals (i.e., Simba and Sam) and then calls the adjust_temp( ) operation of the appropriate containment unit (i.e., Lion Cage 7 in the case of object Simba and Snake Pit 3 in the case of object Sam) to adjust the temperature of the containment units [steps 12 and 13].
The adjust_temp( ) operation of each containment unit then completes the control flow by proceeding to adjust the temperature in a way that is appropriate for the animals contained in each containment unit. (That is, the temperature is adjusted based on time and temperature for Snake Pit 3 and based on time alone for Lion Cage 7.) The reader should note that the relationship between the check_animals( ) operation and the adjust temp( ) operations is polymorphic. In other words, the check_animals( ) operation of object Tina does not require specialized knowledge about how each adjust temp( ) operation performs its task. The check_animals( ) operation merely had to abide by the interface and call the adjust_temp( ) operations. After that, it is up to the individual adjust_temp( ) operations to carry our their tasks in the proper manner.
Main memory 820 contains application programs 822, objects 824, data 826, and an operating system 828. Computer system 800 utilizes well known virtual addressing mechanisms that allow the programs of computer system 800 to behave as if they only have access to a large, single storage entity (referred to herein as computer system memory) instead of access to multiple, smaller storage entities such as main memory 820 and DASD device 855. Therefore, while application programs 822, objects 824, and operating system 828 are shown to reside in main memory 820, those skilled in the art will recognize that these programs are not necessarily all completely contained in main memory 820 at the same time. Note that the term “computer system memory” is used herein to generically refer to the entire virtual memory of computer system 800.
The data transfer framework mechanism disclosed herein provides an architecture for transferring data from a data source to a data target within a computer system. Extending the framework to accommodate data transfer between a specific data source and a specific data target defines a “data transfer environment.” For example, for computer system 800 of FIG. 8, if data needs to be transferred from workstation 875 to DASD 855, a data transfer environment may be created by extending the framework to define the data source as workstation 875, the data target as DASD 855, and to define appropriate transfer parameters and protocols that allow the data to be transferred. Note that the terms “data source” and “data target” are encompassing terms that may refer to any portion of a computer system that is capable of sending or receiving data.
The classes have been broken down into five categories: the Data Transfer category, the Place category, the Source Filter category, the Transfer Condition category, and the Target Mapping category. All of these categories are extensible categories (as indicated by the “E” label), meaning that users may extend the classes in these categories by defining and implementing classes that are subclasses of framework-defined classes. The Data Transfer category has a using relationship with the other four categories, indicating that classes within the Data Transfer category invoke the methods provided by the classes in these other categories. Note that these relationships between categories are core relationships (as indicated by the “C” label), meaning that the framework user cannot modify these relationships.
FIG. 11 illustrates the relationships of the Data Transfer class to other classes in the framework. Data Transfer is an extensible class that contains the methods shown. Data Transfer is a class that a user of the framework will extend to define a specific data transfer environment that needs to be supported by the framework by subclassing the appropriate abstract classes (such as Place, Source Filter, etc.). Data Transfer has a “has by reference” relationship to the source Place class and the target Place class, indicating that a data transfer environment will include one or more objects from each of these classes. Data Transfer also has a “has by reference” relationship to the Source Filter class, the Transfer Condition class, and the Target Mapping class, indicating that a suitable data transfer environment implemented by appropriate subclassing of the framework may define zero, one or many of each of these classes. All of the relationships between classes in FIG. 11 are core relationships, that a user of the framework may not alter.
An object instantiated under the Data Transfer class will have the methods shown in FIG. 11. The DataTransfer( ) method and run( ) method simply call methods in the other extensible classes. The remaining methods (i.e., afterAll( ); afterRead( ); afterwrite( ); beforeAll( ); beforeRead( ); beforeWrite( )) are all private methods that may be initially implemented with no-ops, but may be overridden by subclassing from the Data Transfer class and by implementing these methods in the subclass. These methods are private (as marked by the two vertical lines), indicating that these methods are available only to the methods within the Data Transfer class, and cannot be invoked outside of Data Transfer. The specific sequence of these methods will be explained below in reference to the interaction diagrams of FIGS. 16 and 17.
A class diagram of the classes in the Place category are shown in FIG. 12. The Place class is an extensible abstract class, and has a “has” relationship with the Directory class, which is an extensible class. The Directory class has a “has” relationship with the Name extensible class, with the 0 . . . n indicating that each directory may have zero, one, or many Names. Each Name has associated Data, which has an associated Level. One example for Place is a hard disk drive, which contains a directory. The directory on a hard disk drive has zero to n files (i.e., Names); each file has its associated data (i.e., Data); and the data typically has an associated date stamp (i.e., Level). Note that the relationships between these classes are core relationships, those that may not be changed by the user of the framework.
The Place class has a check( ) method. A Name is passed as a parameter to the check( ) method, which causes the check( ) method to return the Level associated with the Data that corresponds to the Name passed. In this manner, the check( ) method is used to retrieve the Level corresponding to a particular Name. The directory( ) method returns the contents of the Directory class, which contains a list of all the Names stored in the Place. The read( ) method reads the data corresponding to a name passed to it, while the write( ) method writes a name and corresponding data to the Place.
Referring to FIG. 13, a Source Filter class is an extensible abstract class of the framework. The Source Filter class has a single method valid( ), which is passed a Name and its associated Data. Valid( ) is used to determine whether the Name and/or Data meet predetermined criteria for transfer. For example, if a framework user wants to transfer only executable files for a given data transfer environment, valid( ) may be programmed to return true if the file is an executable, and false otherwise. This might be the case for an Executable Source Filter, as shown in one of the possible subclasses for Source Filter. In another example, valid( ) might compare the name to a list of names in a name table that specifies transfer candidates, and return true of the data is listed in the table and return false otherwise. This could be the case for the Table Based Source Filter, another possible subclass for Source Filter. As illustrated by the empty subclasses of FIG. 13, other numerous possible subclasses for Source Filter may be implemented as well, and are shown as examples of additional user-extended classes that may be defined by subclassing from the Source Filter abstract class.
Referring to FIG. 14, a Transfer Condition class is an extensible abstract class of the framework. The Transfer condition class has a single method satisfied( ), which compares the Level of the data source to the Level of the data target. Satisfied( ) is used to determine whether the Levels of data source and data target will allow the transfer. One specific example is illustrated by the Transfer If Missing subclass. For this specific example, if a framework user wants to transfer the data only if the data is missing from the data target, satisfied( ) may be programmed to return true if the file is missing on the data target, and false otherwise. In another example, illustrated by the Transfer If Not Equal subclass in FIG. 14, satisfied( ) might return true (i.e., allow the transfer) if the levels between the data source and the data target are not equal. As illustrated by the empty subclasses of FIG. 14, other numerous possible subclasses for Transfer Condition may be implemented as well, and are shown as examples of additional user-extended classes that may be defined by subclassing from the Transfer condition abstract class.
Referring to FIG. 15, a Target Mapping class is an extensible abstract class of the framework. The Target Mapping class has a single method map( ), which is passed a Name and associated Data for the data source and the Name and associated Data for the data target. Map( ) is used to specify certain parameters for operating on the Name and/or Data during a transfer. For example, a file on one particular data source may need to be reformatted to comply with the file format for a different data target. One specific example, illustrated by the Table Based Target Mapping subclass in FIG. 15, would format a name from the data source to a different name on the data target. Another example would format data from the data source into table form, which is the form expected by the data target. As illustrated by the empty subclasses of FIG. 15, other numerous possible subclasses for Target Mapping may be implemented as well, and are shown as examples of user-extended classes that are defined by subclassing from the Target Mapping abstract class.
The operation of the framework of FIG. 11 may be best understood by the interaction diagrams of FIGS. 16 and 17. A main program first invokes the Data Transfer( ) method, which is a constructor method. The five parameters (i.e., data source place, data target place, source filter, transfer condition, and target mapping) are specified as parameters when the Data Transfer( ) method is invoked. The Data Transfer( ) method, as a constructor, builds the framework according to the parameters passed. The main program then invokes the run( ) method of the Data Transfer class just created, which causes the framework to perform its desired data transfer function. FIG. 16 shows the interaction diagram for the overall framework operation that is initiated when the run( ) method in the Data Transfer class is invoked (step 1). Data Transfer then invokes its own beforeAll( ) method (step 2). Once beforeAll( ) is complete, Data Transfer invokes the directory( ) method on the source place object (step 3). The directory( ) method returns the directory of data on the source place object, and corresponds to step 910 in method 900 of FIG. 9. Data Transfer then selects and processes each piece of data in the source place directory (step 4). The selection of data in step 4 corresponds to step 920 in FIG. 9. Once all data has been processed, the afterAll( ) method is invoked (step 5), and the Data Transfer function is complete.
The interaction diagram for the transfer of a single piece of data is shown in FIG. 17. First, the Data Transfer object invokes its own beforeRead( ) method (step 1). Next, Data Transfer invokes the read( ) method of the Source Place object to read the data corresponding to the Name passed to the read( ) method (step 2). This step 2 corresponds to step 930 of FIG. 9. Next, Data Transfer invokes its own afterRead( ) method. Next, it invokes the valid( ) method of the Source Filter object (step 4), which determines whether the Name and/or Data are valid for transfer. This step 4 corresponds to the Validate Data step 940 of FIG. 9. Data Transfer then invokes the map( ) method of the Target Mapping object (step 5), which performs any needed mapping of data during the transfer (step 950 of FIG. 9). Data Transfer then invokes the check( ) method of the Source Place object (step 6), which determines the Level corresponding to the Name on the Source Place object. In similar fashion, Data Transfer then invokes the check( ) method of the Target Place (step 7), which determines the Level corresponding to the Name on the Target Place object. Next the satisfied( ) method on the Transfer Condition object is invoked (step 8) to verify whether the data is to be transferred based on the Level of the Name at the Source Place object compared to the Level of the Name at the Target Place object (step 960 of FIG. 9). If the satisfied( ) method returns a true value, the beforeWrite( ) method is invoked (step 9). Next, Data Transfer invokes the write( ) method of the target place (step 10), to write the data to the data target (step 970 of FIG. 9). After the write, Data Transfer invokes its own afterWrite( ) method. At this point, Data Transfer continues processing if additional data remains to be processed (if step 980 of FIG. 9 is true).
As discussed above, the private methods of the Data Transfer class may be implemented with no-ops, or may provide some function that a framework extender may need. In either case, the private methods provided within the Data Transfer class may be overridden to provide any desired function at any time during the data transfer method. For example, if the framework user desires to perform a particular function before each portion of data is read, the user may implement the specific function by overriding the beforeRead( ) method. If the user desires to perform a particular function after each write, the afterWrite( ) method would be overridden. If the user desires a particular function after all data is transferred, the afterAll( ) method would be overridden. These private methods greatly expand the flexibility of the data processing framework by providing the capability of adding features to the framework at a later date by overriding the default methods without altering the basic structure or function of the framework.
1) The source place is a File System 2) The target place is an Internet Site 3) Only the files in the Beta Release Table will be transferred 4) The files in the Beta Release Table will be transferred only if the most recent file does not exist at the Internet Site 5) License Code will be embedded in the data during the transfer The class diagram for the Beta Product Internet Upload example are shown in FIG. 18. Each of the classes shown either correspond to classes defined and discussed above, or are concrete subclasses of these classes. By defining a data transfer environment in this manner, the operation of the framework may be illustrated by referring to the interaction diagrams of FIGS. 16 and 17.
First, the run( ) method of the Data Transfer object is invoked (step 1, FIG. 16). Next, the beforeAll( ) method is invoked (step 2), followed by invoking the directory( ) method of the Source Place object (step 3). The directory( ) method will return a directory listing of the File System. One of the files in the directory is selected for transfer (step 4). At this point, we refer to FIG. 17 for the steps involved with transferring a single piece of data. The beforeRead( ) method is invoked (step 1), followed by the read( ) method (step 2), which reads the data from the selected file in File System. The afterRead( ) method is invoked next (step 3), followed by the valid( ) method in the Source Filter object (step 4). If the selected file is listed in the Beta Release Table, valid( ) returns true. Next, the map( ) method of the Target Mapping object is invoked (step 5), which embeds license code into the data being transferred. Next, the Level of the Source Name is checked (step 6), the level of the Target Name is checked (step 7), and the satisfied( ) method of the Transfer Condition object is invoked (step 8). For this particular example, the transfer takes place if the levels are not equal. Next, the beforewrite( ) method is invoked (step 9), followed by the write( ) method of the Target Place object (step 10), which causes the file to be written to the Internet Site. The afterWrite( ) method is then invoked (step 11), which concludes the transfer for the selected piece of data. Once all data has been processed (i.e., once all files in File System that are in the Beta Release Table and that are not currently on the Internet Site are written to the Internet Site with License Code embedded), the afterAll( ) method is invoked (step 5 of FIG. 16), and the data transfer is complete.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4943932Apr 15, 1987Jul 24, 1990Cimflex Teknowledge CorporationArchitecture for composing computational modules uniformly across diverse developmental frameworksUS5057996Jun 29, 1989Oct 15, 1991Digital Equipment CorporationWaitable object creation system and method in an object based computer operating systemUS5101364Feb 9, 1990Mar 31, 1992Massachusetts Institute Of TechnologyMethod and facility for dynamic video composition and viewingUS5119475Aug 29, 1991Jun 2, 1992Schlumberger Technology CorporationObject-oriented framework for menu definitionUS5181162Dec 6, 1989Jan 19, 1993Eastman Kodak CompanyDocument management and production systemUS5195172Jul 2, 1990Mar 16, 1993Quantum Development CorporationSystem and method for representing and solving numeric and symbolic problemsUS5226161Aug 31, 1992Jul 6, 1993Wang Laboratories, Inc.Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data typesUS5247693Nov 17, 1992Sep 21, 1993The Foxboro CompanyComputer language structure for process control applications and method of translating same into program code to operate the computerUS5249270Mar 29, 1991Sep 28, 1993Echelon CorporationDevelopment system protocolUS5257384Sep 9, 1991Oct 26, 1993Compaq Computer CorporationAsynchronous protocol for computer system managerUS5261080Aug 28, 1992Nov 9, 1993Wang Laboratories, Inc.Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formatsUS5274572Mar 6, 1990Dec 28, 1993Schlumberger Technology CorporationMethod and apparatus for knowledge-based signal monitoring and analysisUS5276775Oct 13, 1992Jan 4, 1994Texas Instruments Inc.System and method for building knowledge-based applicationsUS5287447Jun 28, 1991Feb 15, 1994International Business Machines CorporationMethod and system for providing container object attributes to a non-container objectUS5293385 *Dec 27, 1991Mar 8, 1994International Business Machines CorporationMethod and means for using sound to indicate flow of control during computer program executionUS5293470Jan 28, 1991Mar 8, 1994International Business Machines CorporationData processing system for defining and processing objects in response to system user operationsUS5297283Oct 16, 1992Mar 22, 1994Digital Equipment CorporationObject transferring system and method in an object based computer operating systemUS5315703Dec 23, 1992May 24, 1994Taligent, Inc.Object-oriented notification framework systemUS5315709 *Dec 3, 1990May 24, 1994Bachman Information Systems, Inc.Method and apparatus for transforming objects in data modelsUS5367633Jan 11, 1994Nov 22, 1994Taligent, Inc.Objected oriented notification framework systemUS5369766Mar 25, 1993Nov 29, 1994Taligent, Inc.Object-oriented loader system with support for different load formatsUS5379430Aug 4, 1993Jan 3, 1995Taligent, Inc.Object-oriented system locator systemUS5388264Sep 13, 1993Feb 7, 1995Taligent, Inc.Object oriented framework system for routing, editing, and synchronizing MIDI multimedia information using graphically represented connection objectUS5390310 *Sep 30, 1991Feb 14, 1995Apple Computer, Inc.Memory management unit having cross-domain controlUS5390325Dec 23, 1992Feb 14, 1995Taligent, Inc.Automated testing systemUS5396626Aug 4, 1993Mar 7, 1995Taligent, Inc.Object-oriented locator systemUS5398336Jul 16, 1993Mar 14, 1995Consilium, Inc.Object-oriented architecture for factory floor managementUS5418949 *Sep 30, 1993May 23, 1995Fujitsu LimitedPage map, metamap, and relation group file management supervised by operation means for allocating, storing, and searching friendly and exclusive data itemsUS5581722 *Sep 26, 1994Dec 3, 1996Apple Computer, Inc.Memory management unit for managing address operations corresponding to domains using environmental controlUS5642511 *Dec 16, 1994Jun 24, 1997International Business Machines CorporationSystem and method for providing a visual application builder framework* Cited by examinerNon-Patent CitationsReference1Abstract for EPO Patent No. 619544, S. Danforth, Oct. 12, 1994, "Language-Neutral Object-Oriented Programming".2Abstract for U.S. Pat. No. 5,119,475, Schoen et al., Jun. 2, 1992, "Object-Oriented Framework for Menu Definition".3Abstract for U.S. Pat. No. 5,369,766, Henninger et al., Nov. 29, 1994, "Object Oriented Application Processing Apparatus".4Abstract for U.S. Pat. No. 5,388,264, Milne et al., Feb. 7, 1995, "Object-Oriented Framework System for Enabling Multimedia Presentation with Routing and Editing of MIDI Information".5Abstract for WIPO Pat. Application No. WO 95/04966, F. T. Nguyen, Feb. 16, 1995, "Automatic Management of Components in Object-Oriented System".6Abstract for WIPO Patent Application No. 5,371,891, "Object Constructions in Compiler in Object Oriented Programming Language", J. Gray et al., Dec. 6, 1994.7Abstract for WIPO Patent Application No. 94/15282, Anderson et al., Jul. 7, 1994, "Dialog System Object-Oriented System Software Platform".8Abstract for WIPO Patent Application No. 94/19740, Goldsmith et al., Sep. 1, 1994, "Framework Processor of Object-Oriented Application".9Abstract for WIPO Patent Application No. 94/19751, Anderson et al., Sep. 1, 1994, "Concurrent Framework Processing Apparatus for Application Users".10Abstract for WIPO Patent Application No. 94/19752, Anderson et al., Sep. 1, 1994, "Concurrent Framework Processing Apparatus for Two or More Users".11Abstract for WIPO Patent Application No. 95/01610, Koko et al., Jan. 12, 1995, "Object Oriented Product Structure Management in Computer-Aided Product Design".12Abstract for WIPO Patent Application No. 95/02219, Helgeson et al., Jan. 19, 1995, "Distributed Computation Based on Movement, Execution and Insertion of Processes in Network".13Abstract for WIPO Patent Application No. 95/04967, Feb. 16, 1995, "Access Method to Data Held in Primary Memory Based Data Base".14Abstract for WIPO Patent Application No. WO 94/15281, Anderson et al., Jul. 7, 1994, "Atomic Command Object-Oriented System Software Platform".15Abstract for WIPO Patent Application No. WO 94/23364, Heninger et al., Oct. 13, 1994, "Framework Processing Application Software".16Abstract for WIPO Patent Application No. WO 9415285, Jul. 7, 1994, "Object-Oriented Notification Framework System", D. R. Anderson et al.17Abstract for WIPO Patent No. 94/20912, Sep. 15, 1994, "Object-Oriented System for Managing Financial Instruments".18Abstract from EPO Patent Application No. EP 622730, "Encapsulation of Extracted Portions of Documents Into Objects", M. A. Malamud, Nov. 2, 1994.19Abstract from WIPO Patent Application No. WO 94/15286, Goldsmith et al., Jul. 7, 1994, "Object-Oriented Framework for Object Operating System".20Abstract from WIPO Patent Application No. WO 9422081, Sep. 29, 1994, "Hardware-Independent Interface for Interrupt Processing", G. O. Norman et al.21Abstract No. 95-091003/12, "Flexible Multi-Platform Partitioning for Computer Applications in Object Oriented System".22Inspec Abstract C9408-016, from Chen et al., 1994, "An Experimental Study of Using Reusable Software Design Frameworks to Achieve Software Reuse".23Inspec Abstract No. 4512593, from H. Sakai, 1993, "A Method for Contract Design and Delegation in Object Behavior Modeling".24Inspec Abstract No. 4525743, from Hakimzadeh et al., "Instance Variable Access Locking for Object-Oriented Databases".25Inspec Abstract No. 4528985, from Beneventano et al., 1993, "Taxonomic Reasoning with Cycles in LOGIDATA+".26Inspec Abstract No. 4534330, from Istavrinos et al., 1992, "Experiences wtih an Object-Oriented Mapper for Coherent Distributed Shared Memory".27Inspec Abstract No. 4534334, from Campbell et al., 1991, "A Technique for Documenting the Framework of an Object-Oriented System".28Inspec Abstract No. 4540729, from Bailes et al., "The Ecology of Class Refinement".29Inspec Abstract No. 4550414, from Parrish et al., 1993, "Automated Flow Graph-Based Testing of Object-Oriented Software Modules".30Inspec Abstract No. 4565630, from Karpovich et al, 1993, "A Parallel Object-Oriented Framework for Stencil Algorithms".31Inspec Abstract No. 4566447, from J. Rossazza, 1992, "An Object-Centered Fuzzy Representation".32Inspec Abstract No. 4588834, from G. Olander, 1992, "Chembench: Redesign of a Large Commercial Application Using Object-Oriented Techniques".33Inspec Abstract No. 4588839, from L. Fisher, 1992, "Constructing a Class Library for Microsoft Windows".34Inspec Abstract No. 4593721, Periyasamy et al., 1993, "A Formal Framework for Design and Verification of Robotic Agents".35Inspec Abstract No. 4596323, from Frank et al., 1993, "An Integrated Environment for Designing Object-Oriented Enterprise Models".36Inspec Abstract No. 4603430, from G. Booch, 1994, "Designing an Application Framework".37Inspec Abstract No. 4613481, from Thieme et al., 1993, "Schema Integration in Object-Oriented Databases".38Inspec Abstract No. 4618794, from Bowers, 1993, "Some Principles for the Encapsulation of the Bahaviour of Aggregate Objects".39Inspec Abstract No. 461931, from Islan et al, 1993, "Uniform Co-Scheduling Using Object-Oriented Design Techniques".40Inspec Abstract No. 4622794, from Campbell et al., 1993, "A Technique for Documenting the Framework of an Object-Oriented System".41Inspec Abstract No. 4626386, from Aroa et al., 1993, "Building Diverse Environments with PCTE Workbench".42Inspec Abstract No. 4642214, from Marshall et al., 1992, "Using VDM Within an Object-Oriented Framework".43Inspec Abstract No. 4647921, from Uhorchak et al., 1993, "An Object-Oriented Class Library for Creating Engineering Graphs Using PHIGS".44Inspec Abstract No. 4664213, "Maintaining Information about Persistent Replicated Objects in a Distributed System", 1993 IEEE Conference on Distributed Computing Systems.45Inspec Abstract No. B9409-6210M-025, from Hellmans et al., 1994, "An Object-Oriented Approach to Dynamic Service Descriptions".46Inspec Abstract No. B9412-6210Q-016, from Oingzhong et al., 1992, "An Object-Oriented Model for Ingelligent Networks".47Inspec Abstract No. B9503-8110B-023, from Mautref et al., 1995, "An Object-Oriented Framework for the Development of Interactive Decision Support Systems".48Inspec Abstract No. C9402-6150G-002, from Bruege et al., 1993, "A Framework for Dynamic Program Analyzers".49Inspec Abstract No. C9403-6180-027, 1991, "An Event-Object Recovery Model for Object-Oriented User Interfaces" from Proceedings of ACMSymposium on User Interface Software & Technology.50Inspec Abstract No. C9405-618G-031, from Woyak et al., 1993, "A Motif-Like Object-Oriented Interface Framework Using PHIGS".51Inspec Abstract No. C9406-0310F-011, 1993, "Cost-Benefit Analysis of Object-Oriented Technology".52Inspec Abstract No. C9406-61104-29, "A Comparison of Object-Oriented Analysis and Design Methods", Proceedings of C++ World 1993.53Inspec Abstract No. C9406-6110J-007, from J. D. Grimes, 1993, "Objects 101-An Implementation View", Proceedings of COMPCON 1994.54Inspec Abstract No. C9406-6115-048, 1993, "Constructing Multi-View Editing Environments Using MViews".55Inspec Abstract No. C9406-6150N-015, from Schmidt et al., 1994, "The Service Configurator Framework: An Extensible Architecture for Dynamically Configuring Concurrent, Multi-Service Network Daemons".56Inspec Abstract No. C9406-7490-012, "A Discrete-Event Object-Oriented Modeling Environment for Sawmill Simulation".57Inspec Abstract No. C9407-7420D-045, from Desai et al., "Controller Structure Definition Via Intelligent Process Control".58Inspec Abstract No. C9407D-014, from Satoh et al., 1994, Semantics for a Real-Time Object-Oriented Programming Language.59Inspec Abstract No. C9408-7420-021, from Pirkbauer et al., 1994, "Object-Oriented Process Control Software".60Inspec Abstract No. C9408J-011, from Gyu-Chung et al., 1993, "System Methodologies of Object-Oriented Programs".61Inspec Abstract No. C9409-6180-059, from Wang et al., 1993, "A Framework for User Customization".62Inspec Abstract No. C9410-6180G-015, from Eichelberg et al., 1993, "Integrating Interactive 3D-Graphics into an Object-Oriented Application Framework".63Inspec Abstract No. C9411-6115-035, from Mili et al., 1991, "SoftClass: An Object-Oriented Tool for Software Reuse".64Inspec Abstract No. C9411-61308B-108, from Mili et al., 1992, "Building a Graphical Interface for a Reuse-Oriented CASE Tool".65Inspec Abstract No. C9411-6160J-011, from Odberg et al., 1992, "A Framework for Managing Schema Versioning in Object-Oriented Databases".66Inspec Abstract No. C9411-7100-029, from C. Le Pape, 1994, "Implementation of Resource Constraints in ILOG Schedule: A Library for the Development of Constraint-Based Scheduling Systems".67Inspec Abstract No. C9412-6110B-221, Berghel et al., 1992, "A Generic Object-Oriented Concurrency Mechanism for Extensibility and Reuse of Synchronization Components".68Inspec Abstract No. C9412-6110J-006, from Lau et al., 1993, "Using SOM for Tool Integration".69Inspec Abstract No. C9412-6110J-014 from Griss et al., 1994, "Object-Oriented Reuse".70Inspec Abstract No. C9412-6160J-025 from J. Livari, 1994, "Object-Oriented Information Systems Analysis: A Comparsion of Six Object-Oriented Analysis Methods".71Inspec Abstract No. C9412-7330-186, from Righter et al., 1994, "An Object-Oriented Characterization of Spatial Ecosystem Information".72Inspec Abstract No. C9412-7810-003, from Jung et al., 1993, "Development of an Object-Oriented Anthropometric Database for an Ergonomic Man Model".73Inspec Abstract No. C9501-6115-039, from Elia et al., 1993, "G++: An Object Oriented Environment for Developing Distributed Applications".74Inspec Abstract No. C9501-6140D-005, S. Vinoski, 1994, "Mapping CORBA IDL Into C++".75Inspec Abstract No. C9501-7160-020, C. Le Pape, 1993, "The Cost of Genericity: Experiments With Constraint-Based Representations of Time-Tables".76Inspec Abstract No. C9501-7330-007, Salminen et al., 1994, "Modeling trees Using an Object-Oriented Scheme".77Inspec Abstract No. C9502-6130G-006, "Support for Enterprise Modelling in CSCW", P. Hennessy et al., 1994.78Inspec Abstract No. C9502-7160-026, from Menga et al., 1995, "An Object-Oriented Framework for Enterprise Modelling".79Inspec Abstract No. C9502-7810C-058, from Lin et al., 1995, "Can CAL Software Be More Like Computer Games?".80Inspec Abstract No. C9503-6110B-045, from Rosiene et al., 1995, "A Data Modeling Framework for Queueing Network Models".81Inspec Abstract No. C9503-6140D-045, Satoh et al, 1995, "Process Algebra Semantics for a Real Time Object Oriented Programming Language".82Inspec Abstract No. C9504-6130B-049, from A. van Dam, 1995, "VR as a Forcing Function: Software Implications of a New Paradigm".83Inspec Abstract No. C9504-6140D-024, from Sheffler et al., 1995, "An Object-Oriented Approach to Nested Data Parallelism".84Inspec Abstract No. C9504-7460-042, Coleman et al., 1995, "An End-to-End Simulation of A Surveillance System Employing Architecture Independence, Variable Fidelity Components and Software Reuse".85Inspec Abstract No. C9504-7460-043, Sells et al., 1995, "Implementation of the Architecture for a Time-Domain Dynamical System Simulation in a Very High-Level Pictorial Object-Oriented".86 *search.sun.com/query.html search of "framework", printed out at PTO on Jun. 2000, dating the "forest" document from Sun.87 *search.sun.com/query.html search of "framework", printed out at PTO on Jun. 2000, dating the "NetApps" document from Sun.88Text of IBM Technical Disclosure Bulletin, Allard et al., Feb. 1990, "Object-Oriented Programming in C-the Linnaeus System", pp. 437-439.89Text of IBM Technical Disclosure Bulletin, Baker et al., Jun. 1991, "Distribution List Class", p. 159.90Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, "Model View Schema", pp. 321-322.91Text of IBM Technical Disclosure Bulletin, Baker et al., Oct. 1991, "Office Container Class", pp. 309-310.92Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jul. 1991, "Icon Pane Class", pp. 118-119.93Text of IBM Technical Disclosure Bulletin, Cavendish et al., Jun. 1991, "Object-Oriented Documentation Tool", pp. 50-51.94Text of IBM Technical Disclosure Bulletin, vol. 36, Coskun, N., Jun. 1993, "Persistent Framework Independent Record/Playback Framework", pp. 261-264.95Text of IBM Technical Disclosure Bulletin, vol. 37, DeBinder et al., Feb. 1994, "Results Folder Framework", pp. 431-432.96Text of IBM Technical Disclosure Bulletin, vol. 37, No. 11, Nov. 1994, pp. 71-72, Behrs et al., "Device Support Framework to Support ISO DPA 10175 and POSIX 1387.4".97Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 19-20, Al-Kami et al, "Events Set for Event Tracing in Distributed Object-Oriented Systems".98Text of IBM Technical Disclosure Bulletin, vol. 37, No. 12, Dec. 1994, pp. 375-378, Acker et al., "Automatically Generating Formatted Documentation for Object-Oriented Class Libraries".99Text of IBM Technical Disclosure Bulletin, vol. 37, No. 6B, Jun. 1994, pp. 553-556, Gest et al., "Portable Object-Oriented Event Manager".100Text of IBM Technical Disclosure Bulletin, vol. 37, No. 7, Jul. 1994, pp. 145-146, Banda et al., "Exception Management Algorithm for Multi-Threaded Method Invocation".101Text of IBM Technical Disclosure Bulletin, vol. 38, No. 1, Jan. 1995, pp. 411-414, J. Knapman, "Generating Specific Server Programs in Distributed Object-Oriented Customer Information Control System".102 *www.java.sun.com/javaone/javaone96/pres/NetApps.pdf, May 1996.103 *www.java.sun.com/research/forest/COM.Sun.Labs.Forest.docts.coots_95.paper_pdf.pdf, last updated Sep. 9, 1996, printed out at PTO on Jun. 2000.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7275057 *Jan 22, 2003Sep 25, 2007Hitachi, Ltd.Method for reducing communication data amount in business to business electronic commerceUS7424492 *Sep 30, 2005Sep 9, 2008Science Applications International CorporationDatabase management systemUS7487191 *Jun 10, 2005Feb 3, 2009International Business Machines CorporationMethod and system for model-based replication of dataUS8108338Oct 31, 2008Jan 31, 2012International Business Machines CorporationMethod and system for model-based replication of dataUS20060026196 *Sep 30, 2005Feb 2, 2006Science Applications International CorporationDatabase management systemUS20060282482 *Jun 10, 2005Dec 14, 2006International Business Machines CorporationMethod and system for model-based replication of dataUS20090055430 *Oct 31, 2008Feb 26, 2009International Business Machines CorporationMethod and system for model-based replication of data* Cited by examinerClassifications U.S. Classification707/792, 712/E09.084, 719/315, 707/955, 707/999.103, 707/999.008, 707/999.01International ClassificationG06F9/42Cooperative ClassificationY10S707/99938, Y10S707/99944, Y10S707/955, G06F9/443European ClassificationG06F9/44F2ALegal EventsDateCodeEventDescriptionJun 29, 1998ASAssignmentOwner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW YFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MISHESKI, DAVID JOSEPH;NOCK, CLIFTON MALCOLM;REEL/FRAME:009295/0747Effective date: 19960927Nov 1, 2005CCCertificate of correctionDec 29, 2008REMIMaintenance fee reminder mailedJun 21, 2009LAPSLapse for failure to pay maintenance feesAug 11, 2009FPExpired due to failure to pay maintenance feeEffective date: 20090621RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services