Reusable JSP code snippets are defined and instrumented for website testing and production. A user may define tile definitions in a markup language file for a number of JSP code snippets to be included in a store page. Upon receiving store inputs comprising tile definitions and jar files for the features, tables may be generated that map features to stores and features dependencies to features. Based on the tables, the store inputs may be validated. If no error occurs, run time files may be generated and JSP code snippets may be instrumented to the appropriate location for website testing and production.
|
1. A method in a data processing system for defining and instrumenting reusable code snippets, the method comprising:
defining a set of features for a website in a first markup language file;
defining at least one code snippet to be included in each feature within the set of features in the first markup file;
generating at least one mapping table in response to receiving a user request comprising store inputs;
validating the store inputs using the at least one mapping table; and
deploying at least one run time file for the website, wherein
the store inputs comprise the first markup language file in which the set of features for the website is defined and a jar file for each feature within the set of features defined in the first markup language file,
the first markup language file comprises a file directory on the data processing system representing a store directory, and a store identifier for the website,
the jar file comprises a second markup language file, at least one Java server page file, and at least one properties file, for each feature within the set of features defined,
the generating at least one mapping table in response to receiving a user request comprising store inputs comprises:
generating a first table that maps the set of features to at least one website; and
generating a second table that maps at least one feature dependency to at least one feature of the set of features, wherein the at least one feature dependency is a feature which the at least one feature depends on.
3. A computer storage medium for defining and instrumenting reusable code snippets, the computer storage medium having stored therein computer readable program instructions, which when executed, cause a data processing system to perform the operations comprising:
defining a set of features for a website in a first markup language file;
defining at least one code snippet to be included in each feature within the set of features in the first markup file;
generating at least one mapping table in response to receiving a user request comprising store inputs;
validating the store inputs using the at least one mapping table; and
deploying at least one run time file for the website, wherein
the store inputs comprise the first markup language file in which the set of features for the website is defined and a jar file for each feature within the set of features defined in the first markup language file,
the first markup language file comprises a file directory on the data processing system representing a store directory, and a store identifier for the website,
the jar file comprises a second markup language file, at least one Java server page file, and at least one properties file, for each feature within the set of features defined,
the generating at least one mapping table in response to receiving a user request comprising store inputs comprises:
generating a first table that maps the set of features to at least one website; and
generating a second table that maps at least one feature dependency to at least one feature of the set of features, wherein the at least one feature dependency is a feature which the at least one feature depends on.
2. A data processing system comprising:
a bus;
a memory operably connected to the bus;
a processor unit operably connected to the bus;
a computer storage medium for defining and instrumenting reusable code snippets, the computer storage medium having stored therein computer readable program instructions, which when executed, cause the data processing system to perform the operations comprising:
defining a set of features for a website in a first markup language file; and
defining at least one code snippet to be included in each feature within the set of features in the first markup file;
generating at least one mapping table in response to receiving a user request comprising store inputs;
validating the store inputs using the at least one mapping table; and
deploying at least one run time file for the website, wherein the store inputs comprise the first markup language file in which the set of features for the website is defined and a jar file for each feature within the set of features defined in the first markup language file,
the first markup language file comprises a file directory _on the data processing system representing a store directory, and a store identifier for the website,
the jar file comprises a second markup language file, at least one Java server page file, and at least one properties file, for each feature within the set of features defined,
the generating at least one mapping table in response to receiving a user request comprising store inputs comprises:
generating a first table that maps the set of features to at least one website; and
generating a second table that maps at least one feature dependency to at least one feature of the set of features, wherein the at least one feature dependency is a feature which the at least one feature depends on.
|
|||||||||||||||||||||||||
1. Technical Field
The present invention relates to an improved data processing system. In particular, the present invention relates to Java™ server pages in a data processing system. Still more particularly, the present invention relates to defining and instrumenting Java server pages code snippets for website testing and production in a data processing system.
2. Description of Related Art
In a typical electronic business cycle, Website production involves multiple development groups, including page designers and Java developers. Page designers design individual Web pages for the Website, while Java developers develop application logic behind the Web pages. Both groups execute test cases or scenarios using Web pages from the page designers and application logic from the Java developers before deploying the Website into production.
When developing Web pages, page designers often require references to other types of resources. These resources include J2EE enterprise JavaBeans™ and Java application programming interface (API) developed by the Java developers (Java and all Java-related marks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both). J2EE enterprise JavaBeans are reusable components that perform specific business functions. Java APIs are interfaces that are developed using the Java programming language of Java 2 Standard Edition. J2EE enterprise JavaBeans and Java APIs provide application logic behind Web pages that are developed by the page designers.
On the other hand, Java developers also need certain Web pages created by the page designers in order to verify their application logic. However, not all of the application features provided by the Java developers are needed by the page designers to create Web pages. Some features may be needed by one store, while other features may be needed by another store. In addition, when Java developers test their application logic, they create many alternatives and exception conditions in the test environment that may not be necessary in the Website, depending on the requirements. Thus, the page designers and Java developers each have their own set of test requirements for the Website.
The present invention provides a method, apparatus, and computer program product for defining and instrumenting Java Server Page code snippets for Website testing and production. A user may define tile definitions of desirable JSP code snippets to be included in a skeleton of store pages in a markup language file. Upon receiving store inputs comprising tile definitions and jar files, tables are generated that map features for each store and feature dependencies for each feature. The jar file includes a set of definitions and required snippets for each feature that is defined.
A number of validations may be performed to determine if all the required JSP files are included in the jar file, if selected features conflict with each other, if all dependent features are included in the stores, and if the store identifiers and store directories have conflicts. If any of the validations fails, the present invention logs the error. Otherwise, runtime files may be generated and the JSP code snippets may be deployed to the appropriate location.
As will be appreciated by one of skill in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.
Any suitable computer readable medium may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java7, Smalltalk or C++. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
With reference now to the figures,
In the depicted example, server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 are connected to network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Network data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
Referring to
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients 108-112 in
Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI local buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in
Those of ordinary skill in the art will appreciate that the hardware in
As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interfaces. As a further example, data processing system 300 may be a personal digital assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.
The depicted example in
A method, apparatus, and computer program product for defining and instrumenting reusable Java Server pages code snippets for Website testing and production is provided. Reusable Java server pages code snippets in a markup language file are defined and the defined code snippets are instrumented into a skeleton of store pages, such that functionalities of a Website may be implemented in a pluggable manner for testing and production.
A Java server page (JSP) is a dynamic Web page that includes a set of functionalities. A Java server page code snippet is a fragment of the JSP that provides a subset of the functionalities or a feature, such as, a promotion feature of an online retail store. In an aspect of the present invention, a searchable library of functions as a set of JSP code snippets is provided. Page designers and Java developers may assemble a set of JSP codes snippets in the searchable library as building blocks for constructing a Web site. Thus, page designers and Java developers may add different functionalities to the Web site using different JSP code snippet.
A way to plug in desirable JSP code snippets into a skeleton of a basic business flow is provided. A skeleton includes a number of store pages that form a business flow for the Website. For example, a retail store skeleton may include a category display page, which allows customers to choose a list of products; a product display page, which lists each of the products; and a shopping cart page, which allows a customer to check out the chosen products.
In order to accommodate a variety of functional testing requirements and a need of different features for different business models, a set of JSP code snippets are instrumented into the skeleton. Each JSP code snippet is self sufficient, and does not rely on other setup or variables defined in the skeleton store pages. Instrumentation of JSP code snippets to the store pages with standard JSP syntax may be allowed. Since the JSP code snippets are fragments of a JSP page, the JSP code snippets do not include certain HTML tags, for example, the head tag and the body tag.
In an aspect of the present invention, a store definition file is taken as an input for a Website or a store, which defines a set of feature definitions desired by the user. For each feature, a jar file is included. The jar file includes a set of definitions and required snippets for the feature that is defined.
Once the inputs are received, a table is generated that maps features that are defined in the input file to the corresponding store. In addition to a mapping of features and stores, a tables of features and feature dependencies is also generated. Feature dependencies are other features that a feature depends, for example, a bundle feature may depend on a category browsing feature in order to display a list of products to the on-line shopper.
After the mapping tables are generated, all the inputs are validated. The validations include checking the jar file to see if it contains all the JSP files as defined in feature definitions, checking if the features conflict with one another, checking if a store includes all the dependent features, and checking if the store directories have conflicts. If an error is found in any one of the validations, a text report is generated for any failure that occurs to a log directory.
Once the validations are performed, run time files that are necessary for the store are generated, for example, struts-config.xml file, and the run time files including the JSP code snippets to the appropriate location are deployed. At the same time, other required Web assets, such as layout files, are also deployed. Thus, after the run time files are deployed, the JSP code snippets are now instrumented.
At run time, an on-line shopper may click on a link or a button of a JSP code snippet displayed in a store page. The system either displays another skeleton store page, which in turn may include another JSP code snippet, or displays another store page in which the main content is obtained from a JSP code snippet.
Since users may pick and choose reusable JSP code snippets to be included in store pages, efforts required to develop store pages are minimized and overall development costs are reduced. Also, a user may pick and choose desirable features based on the business model by instrumenting desired JSP code snippets.
Turning now to
In a first scenario, Java developers instrumented JSP code snippets 404 in store page 405. Store page 405 may be one of the Web pages designed by the page designer. At run time, since JSP code snippet 404 is included in skeleton store page 405, the displayed store page is composed of both the skeleton and the snippet. In this case, JSP code snippets 404 include application logic developed by Java developers that are used for testing purposes or provide a specific feature. After a shopper clicks a button or a link in store page 405, the system displays another skeleton store page 406, which in turn may include another set of JSP code snippets.
In a second scenario, Java developers instrumented JSP code snippets 408 in store page 409. The store page displays the content of both skeleton store page 409 and JSP code snippet 408. At run time, when a shopper clicks on a button or link in the snippet 408, the shopper is directed to another JSP code snippet 410, which are not included in any skeleton store page 409. In this case, the snippet itself becomes the store page and the main content of the page is obtained from a JSP code snippet. This scenario occurs usually when skeleton pages do not provide the features in JSP codes snippets 408 and 410. When JSP code snippets 408 and 410 are displayed, some of the links or buttons in JSP code snippets 408 and 410 direct the shopper to the next store page 411.
Turning now to
In this example implementation, new category JSP code snippet 506 with bundle support is appended to the bottom of skeleton store page category display 508 in order to add functionality to the store. When a shopper clicks on a bundle link in category JSP code snippet 506, the bundle display JSP code snippet 504 is displayed. If a shopper selects an ‘Add to Order’ button in bundle display JSP code snippet 504, the shopper is directed to shopping cart skeleton store page 510.
In addition to selecting JSP code snippets from a searchable library, page designers and Java developers may be allowed to instrument JSP code snippets using extensible Markup Language (XML) tile definitions. As a person of ordinary skill in the art would appreciate, content of a JSP page may be divided into a number of tiles. Each tile represents a specific functionality and presentation for the JSP page. XML tile definition is a way of defining each tile of a JSP page in XML configuration file. By using XML tile definitions, developers may insert different content to a JSP file.
In order to compose a store using a set of JSP code snippets, a XML tile definition configuration file may be used to include the new snippets. In addition, a flexible snippet inclusion may be provided by preparing a number of templates to adapt different JSP code snippets.
Turning now to
In order to include JSP code snippet in skeleton page of the test store, such as SkeletonPage.jsp 606, the definition of TestStoreSnippet1Definition 608 and TestStore.SkeletonPage1 610 extends the TestStoreSnippet1Definition 608 using the “extends” attribute 612 and specifies the location of the JSP file for the JSP code snippet using “snippet1” attribute 614. In this example, the location of JSP code snippet is “/Snippets/Components1/Feature1/JSPCodeSnippet1.jsp” 616.
TestStoreSnippet1Definition 608 is a parent definition that uses TestStoreSnippet1Layout.jsp 618 to insert a body page and JSPCodeSnippet1 616, which was previously defined in “snippet1” attribute 620. Any store page that needs to include one snippet may extend from TestStoreSnippet1Definition 608.
Similarly, TestStoreSnippet2Definition 622 uses TestStoreSnippet2Layout.jsp 624 to include two JSP code snippets to the TestStore.SkeletonPage2 626. An extension of the tile definition is defined from TestStoreSnippet2Definition 622 and specifies the location of the two JSP files for the JSP code snippets by using “snippet1” 628 and “snippet2” 630 attributes. The location of JSP code snippet for “snippet1” is “/Snippets/Component1/Feature1/JSPCodeSnippet1.jsp” 632 and the location of snippet2 is “/Snippets/Component1/Feature1/JSPCodeSnippet2.jsp” 634. Thus, developers may explicitly define one or more JSP code snippets to be included in a store page in the XML tile definition configuration file. In addition, the same layout page may be used for more than one definition.
Turning now to
Turning now to
In this example, CatalogBrowsing feature 802 depends on one Checkout feature 804. CatalogBrowsing feature 802 has three main forwards: TopCategoriesDisplay 812, CategoriesDisplay 814, and ProductDisplay 808. A main forward is used to define a JSP page to be displayed responsive to an action received in a user request. Typically, main forwards are used to help generate a Struts configuration file, which determines the routing of a business flow. More information regarding the manner by which main forwards are used in the context of a Struts framework may be obtained from the Struts project, version 1.2.6, available from the Apache Software Foundation, which is hereby incorporated by reference.
While tiles definitions ProductDisplay 808, TopCategoriesDisplay 812 and CategoryDisplay 814 are all included in the same template, regular_template.jsp 810, the content of ProductDisplay 808 feature, TopCategoriesDisplay 812, and CategoryDisplay 814 are located in ProductDisplay.jsp 816, TopCategoriesDisplay.jsp 818, and CategoryDisplay.jsp 820, respectively.
Turning now to
Also similar to CatalogBrowsing feature 802 in
Turning now to
Bundle feature 1002 includes a forward feature of BundleDisplay 1010, which provides a display of details for each product in the bundle. JSP code snippet section 1008 defines where to include the JSP code snippet to a page. The inclusion definition entry 1014 defines that the JSP code snippet should be included in CategoryDisplay page of the Catalog Browsing feature 802 in
Turning now to
Store inputs are store definition files, such as TestStore1 702 in
Next, a table is generated that maps a number of stores to a number of features (step 1102). The table provides an interpretation of what features are available for which store. In addition, a table is generated that maps a number of features to a number of feature dependencies (step 1104). [0066] For example, in
Once the tables are generated, the inputs are validated to determine errors. The first validation is to determine if the jar file received includes all the JSP files that are listed in the feature definition file (step 1106). If the jar file does not include all the JSP files listed in the feature tile definition file, the process continues to step 1108.
Otherwise, the second validation is performed to determine if features that are listed in the feature definition file conflict with each other (step 1110). This step includes determining if two jar files may have the same feature names, which means the features conflict with each other. If the features conflict with each other, the process continues to step 1108.
If the features do not conflict with each other, the third validation is performed to determine if dependent features are included in requested stores (step 1112). This step is performed based on the table of features and features dependencies generated in step 1106. This step includes determining if the stores include all of their dependencies, since the stores should not have any broken link. If the dependent features are not included in the stores, the process continues to step 1108.
If the dependent features are included in the stores, a fourth validation is performed to determine if the store identifiers and the store directories from the mapping tables or environment have conflicts (step 1114). This step is performed to ensure that two stores may not have the same store directory or store identifier. If the store identifiers and the store directories have conflicts, the process continues to step 1108. At step 1108, a text report of the failure that occurred to a log directory is generated, and the process terminates thereafter.
If the store identifiers and the store directories do not have conflicts, necessary run time files (step 1116) for the Website are generated, including struts-config.xml file, which describes routing of the business flow for the Website. All JSP code snippets to the appropriate location (step 1118) are then deployed by copying the JSP code snippets and their corresponding properties files from the jar files.
In addition, other required Web assets are also deployed to the appropriate location (step 1120). These Web assets include the layout JSP files and cascade style sheet files that describe the page layout. If necessary, extension points are also provided to support additional processing for customization (step 1122). Once the stores are generated, the process terminates thereafter.
In summary, a method and apparatus is provided to instrument reusable JSP code snippets into a skeleton of store pages, such that functionalities of a Website may be implemented in a pluggable manner for testing and production. In addition, existing Struts and Tiles technologies is leveraged and a method for defining tiles definitions for different features of a store is provided.
The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Ng, Walfrey, Fong, James Leonard Timothy, Tin, Ramiah Kwok-fai, Yuen, KimPing
| Patent | Priority | Assignee | Title |
| 10042658, | Sep 27 2007 | Veritas Technologies LLC | Automatically adding bytecode to a software application to determine network communication information |
| 7793268, | Aug 28 2006 | LinkedIn Corporation | Method, system, and program product for composing a virtualized computing environment |
| 8176114, | Feb 28 2008 | Oracle International Corporation | Distributed cross-application server deployment |
| 8458670, | Sep 27 2007 | Veritas Technologies LLC | Automatically adding bytecode to a software application to determine network communication information |
| 8578339, | Sep 26 2007 | Veritas Technologies LLC | Automatically adding bytecode to a software application to determine database access information |
| 8595691, | Jun 05 2009 | MAYXMISER LTD | Method of website optimisation |
| 8887141, | Sep 28 2007 | Veritas Technologies LLC | Automatically modifying a native code module accessed from virtual machine bytecode to determine execution information |
| 9489178, | Jun 05 2009 | Method of website optimisation | |
| 9800585, | Oct 21 2015 | Red Hat, Inc. | Restricting access by services deployed on an application server |
| 9854064, | Jun 05 2009 | Oracle International Corporation | Method of website optimisation |
| Patent | Priority | Assignee | Title |
| 5724589, | Oct 13 1995 | CODEGEAR LLC | Development system with a property-method-event programming model for developing context-free reusable software components |
| 6002871, | Oct 27 1997 | Unisys Corporation | Multi-user application program testing tool |
| 6226792, | Oct 14 1998 | Unisys Corporation | Object management system supporting the use of application domain knowledge mapped to technology domain knowledge |
| 6473894, | Jan 29 1999 | International Business Machines Corporation | Dynamic runtime and test architecture for Java applets |
| 6631408, | Oct 12 1998 | MICRO FOCUS LLC | Testing web sites |
| 6697849, | Aug 13 1999 | Oracle America, Inc | System and method for caching JavaServer Pages™ responses |
| 7210097, | May 22 2002 | Pitney Bowes Inc | Method for loading large XML documents on demand |
| 20020138582, | |||
| 20030018832, | |||
| 20030159131, | |||
| 20030200533, | |||
| 20030233631, | |||
| 20040010776, | |||
| 20040059809, | |||
| 20040261017, | |||
| 20050268238, | |||
| 20070198919, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Dec 03 2004 | International Business Machines Corporation | (assignment on the face of the patent) | / | |||
| Dec 15 2004 | TIN, RAMIAH KWOK-FAI | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015480 | /0722 | |
| Dec 17 2004 | FONG, JAMES LEONARD TIMOTHY | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015480 | /0722 | |
| Dec 20 2004 | NG, WALFREY | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015480 | /0722 |
| Date | Maintenance Fee Events |
| Jan 27 2009 | ASPN: Payor Number Assigned. |
| Jun 29 2012 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Aug 19 2016 | REM: Maintenance Fee Reminder Mailed. |
| Jan 06 2017 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Jan 06 2012 | 4 years fee payment window open |
| Jul 06 2012 | 6 months grace period start (w surcharge) |
| Jan 06 2013 | patent expiry (for year 4) |
| Jan 06 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jan 06 2016 | 8 years fee payment window open |
| Jul 06 2016 | 6 months grace period start (w surcharge) |
| Jan 06 2017 | patent expiry (for year 8) |
| Jan 06 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jan 06 2020 | 12 years fee payment window open |
| Jul 06 2020 | 6 months grace period start (w surcharge) |
| Jan 06 2021 | patent expiry (for year 12) |
| Jan 06 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |