System and method for determining software object migration sequences

BACKGROUND OF THE INVENTION

[0001] 1. Technical Field

[0002] The present invention relates in general to a system and method for determining software object migration sequences. More particularly, the present invention relates to a system and method for selecting decision factors and calculating a migration score for use in constructing a migration sequence.

[0003] 2. Description of the Related Art

[0004] In today's complex information systems (IS) environments, IS departments are challenged with generating appropriate methodologies for numerous actions. One of the more complicated processes that an IS department faces is the planning of large-scale migrations of applications between hardware platforms. One reason an IS department migrates applications between hardware platforms is to achieve performance increases. For example, the IS department may decide that upgrading an existing server system to a different vendor's server system significantly increases data transfer rates which will increase customer satisfaction.

[0005] Another reason IS departments migrate hardware platforms is for cost cutting measures. For example, large-scale computer systems are sometimes constructed in stages. Each stage may have a separate server system in order for the stage to quickly achieve operational status. When the large-scale computer system is fully implemented, the computer system may include many server systems which are not fully utilized. The IS department may choose to migrate objects from a first server system to a second server system in order to re-sell the first server system.

[0006] A challenge found with migrating software objects, such as applications, databases, and data structures, is scheduling a migration sequence based upon dependencies between the objects. For example, a database installation and configuration should be migrated prior to an application that sets atop the database. This may be obvious when migrating a few applications, but the migration sequence becomes more challenging when migrating hundreds of applications and databases.

[0007] Furthermore, each application may have a different number of users at different status levels within the organization. For example, a first application may have hundreds of users while a second application may have less than ten users. The ten users, however, may be the top management in the organization. A challenge found with scheduling software migration sequences is objectively weighing who the users are with other factors, such as the importance of what the users are performing with the application.

[0008] What is needed, therefore, is a way to schedule largescale migrations using an objective, systematic approach.

SUMMARY

[0009] It has been discovered that decision factors and object grading may be used to generate an objective migration schedule. A customer determines which objects to migrate and if the objects have associated dependencies. The customer then assigns decision factor criteria and weighting which is used in conjunction with an object identifier grade to generate a migration score. The migration score is analyzed in combination with object dependencies to generate a migration plan.

[0010] The customer requires object migrations from one hardware platform to another hardware platform which may be based upon cost cutting measures or system performance enhancements. As those skilled in the art can appreciate, objects may include applications, databases, data structures, and files. The customer selects the objects for migration and assigns an object identifier (i.e. the object name). The customer also determines object dependencies upon another object. For example, an application that sets atop a database may be dependent upon the database being migrated prior to the application.

[0011] The customer assigns decision factors and corresponding weightings for use in determining an object migration sequence. A decision factor weighting is a positive or negative number used to show how important each particular decision factor is compared to the other decision factors in determining the migration order of an object.

[0012] The customer reviews each decision factor corresponding to each object identifier and assigns a corresponding object identifier grade. In one embodiment, a high grade indicates that the decision factor is high for the particular object. For example, an object that generates billing statements would have a high grade for an “Importance” decision factor.

[0013] Each object identifier grade is multiplied with the corresponding decision factor weighting which results in a decision factor score. After each decision factor score is calculated corresponding to each decision factor and object identifier grade, the decision factor scores corresponding to an object identifier are added together which results in a migration score for the object identifier.

[0014] A migration order is generated based upon migration scores. Object dependencies are analyzed and, if appropriate, the migration order is adjusted accordingly. For example, an application that sets atop a database is dependent upon the database to migrate prior to the application. The database is moved ahead of the application in the migration order regardless of its corresponding migration score relative to the applications corresponding migration score.

[0015] The migration order is imported into a project planner to generate a migration schedule. Information Systems (IS) staff input may also be input into the project planner, such as resource availability, to create a realistic migration schedule. The migration schedule is sent to the IS department for implementation.

[0016] The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

[0018]FIG. 1 is a diagram showing customer inputs used to compute migration scores and generate a migration schedule;

[0019]FIG. 2A is a spreadsheet example showing object identifier grades for various decision factors;

[0020]FIG. 2B is a spreadsheet showing object identifiers sorted based upon migration scores and corresponding dependencies;

[0021]FIG. 3 is a high-level flowchart showing steps taken in generating a software migration plan;

[0022]FIG. 4 is a flowchart assigning weightings to corresponding decision factors;

[0023]FIG. 5 is a flowchart showing a customer assigning object identifier grades to corresponding decision factors;

[0024]FIG. 6 is a flowchart showing steps taken in computing migration scores for use in generating a migration order;

[0025]FIG. 7 is a flowchart showing steps taken in generating a migration order based upon migration scores and object identifier dependencies; and

[0026]FIG. 8 is a block diagram of an information handling system capable of implementing the present invention.

DETAILED DESCRIPTION

[0027] The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention which is defined in the claims following the description.

[0028]FIG. 1 is a diagram showing customer inputs used to compute migration scores and generate a migration schedule. Customer <b>100</b> requires object migrations from one platform to another platform. The migration may be based upon cost cutting measures or system performance enhancements. The objects may include applications, databases, data structures, and files. Customer <b>100</b> selects the objects for migration and assigns an object identifier (i.e. the object name) to each object. Customer <b>100</b> also determines if an object has dependencies upon another object. For example, an application that sets atop a database may be dependent upon the database being migrated prior to the application. Object identifiers <b>110</b> includes a list of object identifiers and corresponding dependencies.

[0029] Customer <b>100</b> assigns decision factors and corresponding weightings (decision factors and weightings <b>120</b>) for use in determining an object migration sequence. A decision factor weighting is a positive or negative number used to quantify the importance of a particular decision factor compared to the other decision factors in determining the migration order of an object.

[0030] A positive decision factor weighting indicates that the decision factor contributes to early migration while a negative decision factor indicates that the decision factor contributes to late migration. A small number indicates that the decision factor is less important, and may serve as a “tie breaker” for two applications with very similar assessments. A large number indicates that the decision factor is more important and is critical in determining how early objects will migrate.

[0031] Customer <b>100</b> reviews each decision factor corresponding to each object identifier and assigns a corresponding grade. In one embodiment, a high grade indicates that the decision factor is high for the particular object. For example, an object that generates billing statements would have a high object identifier grade for an “Importance” decision factor. Object identifier grading <b>130</b> includes object identifier grades corresponding to each decision factor reviewed with each object identifier.

[0032] Object identifiers <b>110</b>, object identifier grading <b>130</b>, and decision factor and weighting <b>120</b> are input to compute engine <b>140</b>. Compute engine <b>140</b> determines a migration score for each object identifier based upon decision factor weightings and object identifier grades (see FIG. 6 for further details regarding migration score calculations).

[0033] Compute engine <b>140</b> generates migration order <b>150</b> which includes a sorted list of object identifiers based upon corresponding migration scores and dependencies of each object identifier (see FIG. 7 for further details regarding object identifier migration order generation). Migration order <b>150</b> is imported into project planner <b>160</b> to generate a migration schedule (migration schedule <b>170</b>). Project planner <b>160</b> may be a software program, such as Microsoft Project, capable of generating project plans. Information Systems (IS) staff input may be input into project planner <b>160</b>, such as resource availability, to create a realistic migration schedule. Migration schedule <b>170</b> is sent to IS staff <b>180</b> for implementation.

[0034]FIG. 2A is a spreadsheet example showing object identifier grades for various decision factors. Column <b>200</b> includes an item number corresponding to each object identifier for use in indicating object identifier dependencies (described below). Column <b>205</b> includes a list of object identifiers that correspond to selected objects for migration. The objects may include applications, databases, and data structures. Column <b>210</b> includes item numbers corresponding to object identifier dependencies. Meaning, if “object A” requires “object B” to migrate first, “object A” is dependent upon “object B”. For example, box <b>245</b> indicates that “Internet ELMA” depends upon item <b>1</b>, or “Remote Kiosk DB”. Therefore, “Remote Kiosk DB” needs to migrate prior to “Internet ELMA”.

[0035] Columns <b>215</b> through <b>240</b> are decision factors in which the customer selects. Column <b>215</b> includes “Importance” object identifier grades for corresponding object identifiers. The “Importance” object identifier grade may be based on the business need of the corresponding object. For example, if an object is used to issue billing statements, the corresponding “Importance” object identifier grade may be high. On the other hand, if the object is used to store historical information, the corresponding “Importance” object identifier grade may be low.

[0036] Column <b>220</b> includes “Complexity” object identifier grades for corresponding object identifiers. Grading the complexity of the object may include analyzing the corresponding system's performance, the corresponding application's tier level, the number of supporting systems or servers, whether the corresponding systems are clustered, and the number of interfaces. In this example, column <b>225</b> includes “Object Tier” grades for corresponding object identifiers. The customer may consider it more desirable to accelerate the migration of objects associated with three-tier applications before those associated with two-tier applications.

[0037] Column <b>230</b> includes “Resale Value” object identifier grades for corresponding object identifiers. The resale value corresponds to the resale value of the platform in which the corresponding object is using to operate. For example, an application may be operating on a new server which is able to be re-sold for a high dollar amount. In this example, the “resale value” object identifier grade corresponding to the application is high.

[0038] Column <b>235</b> includes “Growth” object identifier grades for corresponding object identifiers. Objects may be graded according to how fast they are growing. For example, a customer may request to migrate objects from old systems to new systems that are growing exponentially before the growing objects exhaust the old system's resources, such as disk space, memory, or processing power.

[0039] Column <b>240</b> includes “Visibility” object identifier grades for corresponding object identifiers. Grading the object visibility may include analyzing the relative end use of the application, the number of users, and the importance of users. For example, if top management frequently uses an object for strategic projects, the corresponding “visibility” object identifier grade will be high.

[0040]FIG. 2B is a spreadsheet showing object identifiers sorted based upon migration scores and corresponding dependencies. Column <b>250</b> shows the migration order of object identifiers based upon their corresponding migration score and dependencies (described below). Row <b>260</b> includes decision factor weightings for corresponding decision factors. A decision factor weighting is a positive or negative number used to show how important each particular decision factor is compared to the other decision factors in determining the migration order of an object.

[0041] A positive decision factor weighting indicates that the decision factor contributes to early migration while a negative decision factor indicates that the decision factor contributes to late migration. A small number indicates that the decision factor is less important, and may serve as a “tie breaker” for two applications with very similar assessments. A large number indicates that the decision factor is more important and is critical in determining early object migration. For example, on a scale from one to ten, box <b>265</b> indicates that the “complexity” decision factor has a weighting of “7” which indicates that “complexity” is critical in determining the migration order of objects.

[0042] Column <b>270</b> shows migration scores for corresponding object identifiers (see FIG. 6 for further details regarding migration score calculations). The migration scores are sorted in descending order. However, box <b>280</b> (migration score=131) is above box <b>290</b> (migration score=198) because object identifier “Internet ELMA” is dependent upon object identifier “Remote Kiosk DB”. Therefore, “Remote Kiosk DB” is moved in front of “Internet ELMA” in migration order.

[0043]FIG. 3 is a high-level flowchart showing steps taken in generating a software migration plan. Processing commences at <b>300</b>, whereupon staff is identified from IS organization <b>305</b> (step <b>310</b>). The staff is responsible for overseeing and implementing the software migration plan. Customer <b>315</b> selects objects for migration and provides an object identifier (i.e. object name) for each object which is stored in object identifier store <b>325</b> (step <b>320</b>). Object identifier store <b>325</b> may be stored on a non-volatile storage area, such as a computer hard drive. Objects may include applications, databases, data structures, and files. For example, if a server is being removed from a computer system, then each object (i.e. applications, databases, data structures, and files) on the server is selected for migration.

[0044] Customer <b>315</b> identifies decision factors which are stored in decision factor store <b>335</b> at step <b>330</b>. Decision factors may include the importance of an object, the complexity of moving the object, and the number of tier in the object (see FIG. 2A for further details regarding decision factors). Decision factor store <b>335</b> may be stored on a non-volatile storage area, such as a computer hard drive. A decision factor weighting is assigned to each decision factor (pre-defined process block <b>340</b>, see FIG. 4 for further details). For example, a weighting scale may be from one to ten wherein a ten corresponds to a decision factor with high importance and a one corresponds to a decision factor with low importance.

[0045] Customer <b>315</b> assigns an object identifier grade for each decision factor corresponding to each object identifier (pre-defined process block <b>350</b>, see FIG. 5 for further details). The object identifier grades are stored in grading store <b>355</b>. Grading store <b>355</b> may be stored on a non-volatile storage area, such as a computer hard drive. Processing computes a migration order using customer grading information located in grading store <b>355</b> and stores the migration order in migration order store <b>365</b>. The migration order may be stored in spreadsheet format for easier importing into a project planning software for schedule generation. Migration order store <b>365</b> may be stored on a non-volatile storage area, such as a computer hard drive.

[0046] Processing generates a migration plan using the migration order in migration order store <b>365</b> and stores the migration plan in migration plan store <b>375</b>. Migration plan store <b>375</b> may be stored on a non-volatile storage area, such as a computer hard drive. The migration schedule may be generated with project planning software, such as Microsoft Project. An Information System (IS) staff member may also provide information to the project planning software, such as available resources, to assist in generating a realistic migration plan. Processing ends at <b>380</b>.

[0047]FIG. 4 is a flowchart assigning weightings to corresponding decision factors. Processing commences at <b>400</b>, whereupon a first decision factor is retrieved from decision factor store <b>405</b> (step <b>410</b>). Decision factor store <b>405</b> may be stored on a non-volatile storage area, such as a computer hard drive. Customer <b>425</b> reviews the decision factor and assigns a weighting at step <b>420</b>. The decision factor is stored in temp store <b>435</b> in order of weighting and may be displayed at step <b>430</b>. Customer <b>425</b> may review the recent decision factor weighting assignment relative to other decision factor weightings and make a determination as to whether to make changes to the recent decision factor weighting (decision <b>440</b>). If the customer wants to make changes, decision <b>440</b> branches to “Yes” branch <b>442</b> which loops back to process the new weighting assignment. This looping continues until there are no more changes to make regarding the decision factor weighting, at which point decision <b>440</b> branches to “No” branch <b>448</b>.

[0048] A determination is made as to whether there are more decision factors to assign weightings (decision <b>450</b>). If there are more decision factors to assign weightings, decision <b>450</b> branches to “Yes” branch <b>452</b> which loops back to retrieve (step <b>460</b>) and process the next decision factor. This looping continues until there are no more decision factors, at which point decision <b>450</b> branches to “No” branch <b>458</b>. Final decision factor weightings are stored with their corresponding decision factors in decision factor store <b>405</b> (step <b>470</b>). Processing ends at <b>480</b>.

[0049]FIG. 5 is a flowchart showing a customer assigning object identifier grades to corresponding decision factors. Processing commences at <b>500</b>, whereupon a first object identifier is retrieved from object identifier store <b>505</b> (step <b>510</b>). The object identifier corresponds to an object which will be migrated. Object identifier store <b>505</b> may be stored on a non-volatile storage area, such as a computer hard drive. A first decision factor is retrieved from decision factor store <b>525</b> at step <b>520</b>. Decision factor store <b>525</b> may be stored on a non-volatile storage area, such as a computer hard drive.

[0050] Customer <b>535</b> assigns an object identifier grade to the corresponding decision factor and the object identifier grade is stored in grading store <b>538</b> (step <b>530</b>). Customer <b>535</b> may use a scale from one to ten with ten being the highest grade. For example, if the retrieved decision factor was “importance” and the corresponding object identifier was the most important relative to the other object identifiers, the customer may assign an object identifier grade of “ten”.

[0051] A determination is made as to whether there are more decision factors (decision <b>540</b>). If there are more decision factors, decision <b>540</b> branches to “Yes” branch <b>542</b> which loops back to retrieve (step <b>550</b>) and process the next decision factor. This looping continues until there are no more decision factors to process for the object identifier, at which point decision <b>540</b> branches to “No” branch <b>548</b>.

[0052] A determination is made as to whether there are more object identifiers to process (decision <b>560</b>). If there are more object identifiers to process, decision <b>560</b> branches to “Yes” branch <b>562</b> which loops back to retrieve (step <b>570</b>) and process the next object identifier. This looping continues until there are no more object identifiers to process, at which point decision <b>560</b> branches to “No” branch <b>568</b>. Processing returns at <b>580</b>.

[0053]FIG. 6 is a flowchart showing steps taken in computing migration scores for use in generating a migration order. Processing commences at <b>600</b>, whereupon the first object identifier is retrieved from object identifier store <b>610</b>. Object identifier store <b>610</b> may be stored on a non-volatile storage area, such as a computer hard drive. A first decision factor and weighting are retrieved from decision factor store <b>620</b> at step <b>615</b>. For example, an “Importance” decision factor with a weighting of “7” may be retrieved. Decision factor store <b>620</b> may be stored on a non-volatile storage area, such as a computer hard drive.

[0054] An object identifier grade corresponding to the object identifier and decision factor is retrieved from grading store <b>630</b> at step <b>625</b> (see FIG. 5 for further details regarding object identifier grading). Using the example described above, the customer may have assigned an object identifier grade of “8” for an object identifier that has high “importance”.

[0055] The object identifier grade is multiplied with the decision factor weighting and the result (decision factor score) is stored in multiply store <b>640</b>. Using the example described above, multiplying a weighting of “7” and an object identifier grade of “8” results in a decision factor score of “56” which is stored in multiply store <b>640</b>. Multiply store <b>640</b> may be stored on a non-volatile storage area, such as a computer hard drive.

[0056] A determination is made as to whether there are more decision factors (decision <b>645</b>). If there are more decision factors, decision <b>645</b> branches to “Yes” branch <b>647</b> which loops back to select (step <b>650</b>) and process the next decision factor and corresponding weighting. This looping continues until there are no more decision factors to process for the identified object identifier, at which point decision <b>645</b> branches to “No” branch <b>649</b>.

[0057] The decision factor scores for the identified object identifier are added together at step <b>655</b>. Using the example described above, the decision factor score of “56” is added to the rest of the decision factor scores. The summation of the decision factor scores for a particular object identifier results in a migration score that is stored in migration score store <b>660</b> (step <b>655</b>). Migration score store <b>660</b> may be stored on a non-volatile storage area, such as a computer hard drive.

[0058] A determination is made as to whether there are more object identifiers to process (decision <b>665</b>). If there are more object identifiers to process, decision <b>665</b> branches to “Yes” branch <b>667</b> which loops back to identify (step <b>670</b>) and process the next object identifier. This looping continues until there are no more object identifiers to process, at which point decision <b>665</b> branches to “No” branch <b>669</b>.

[0059] The object identifiers are sorted based upon their corresponding migration score and object identifier dependencies (pre-defined process block <b>675</b>, see FIG. 7 for further details) . The sorted object identifiers are stored in migration order store <b>680</b>. Migration order store <b>680</b> may be stored on a non-volatile storage area, such as a computer hard drive. Processing returns at <b>690</b>.

[0060]FIG. 7 is a flowchart showing steps taken in generating a migration order based upon migration scores and object identifier dependencies. Processing commences at <b>700</b>, whereupon object identifiers and corresponding migration scores are retrieved from migration score store <b>720</b> and sorted in descending order based upon their corresponding migration score and stored in migration order store <b>730</b> (step <b>710</b>). Migration score store <b>720</b> may be stored on a non-volatile storage area, such as a computer hard drive. Migration order store <b>730</b> may be stored on a non-volatile storage area, such as a computer hard drive.

[0061] The first object identifier is retrieved at step <b>740</b>. Since the object identifiers have been sorted in descending order based upon corresponding migration scores, the first object identifier has the highest migration score. A determination is made as to whether the first object identifier has dependencies which are lower in migration order. For example, an application corresponding to the first object identifier may be dependent upon a database to migrate first whose object identifier is lower in migration order.

[0062] If the object identifier does not have dependencies lower in order, decision <b>750</b> branches to “No” branch <b>758</b> bypassing migration order changes. If the object identifier has dependencies lower in order, decision <b>750</b> branches to “Yes” branch <b>752</b>. The migration order of the object identifier dependency is moved in front of the object identifier in migration order store <b>730</b> (step <b>760</b>). Using the example described above, the database object identifier is moved in front of the application object identifier regarding migration order.

[0063] A determination is made as to whether there are more object identifiers to analyze (decision <b>770</b>). If there are more object identifiers to analyze, decision <b>770</b> branches to “Yes” branch <b>772</b> which loops back to retrieve (step <b>780</b>) and process the next object identifier. This looping continues until there are no more object identifiers to process, at which point decision <b>770</b> branches to “No” branch <b>778</b>. Processing returns at <b>790</b>.

[0064]FIG. 8 illustrates information handling system <b>801</b> which is a simplified example of a computer system capable of performing the server and client operations described herein. Computer system <b>801</b> includes processor <b>800</b> which is coupled to host bus <b>805</b>. A level two (L2) cache memory <b>810</b> is also coupled to the host bus <b>805</b>. Host-to-PCI bridge <b>815</b> is coupled to main memory <b>820</b>, includes cache memory and main memory control functions, and provides bus control to handle transfers among PCI bus <b>825</b>, processor <b>800</b>, L2 cache <b>810</b>, main memory <b>820</b>, and host bus <b>805</b>. PCI bus <b>825</b> provides an interface for a variety of devices including, for example, LAN card <b>830</b>. PCI-to-ISA bridge <b>835</b> provides bus control to handle transfers between PCI bus <b>825</b> and ISA bus <b>840</b>, universal serial bus (USB) functionality <b>845</b>, IDE device functionality <b>850</b>, power management functionality <b>855</b>, and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Peripheral devices and input/output (I/O) devices can be attached to various interfaces <b>860</b> (e.g., parallel interface <b>862</b>, serial interface <b>864</b>, infrared (IR) interface <b>866</b>, keyboard interface <b>868</b>, mouse interface <b>870</b>, and fixed disk (HDD) <b>872</b>) coupled to ISA bus <b>840</b>. Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus <b>840</b>.

[0065] BIOS <b>880</b> is coupled to ISA bus <b>840</b>, and incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions. BIOS <b>880</b> can be stored in any computer readable medium, including magnetic storage media, optical storage media, flash memory, random access memory, read only memory, and communications media conveying signals encoding the instructions (e.g., signals from a network). In order to attach computer system <b>801</b> to another computer system to copy objects over a network, LAN card <b>830</b> is coupled to PCI bus <b>825</b> and to PCI-to-ISA bridge <b>835</b>. Similarly, to connect computer system <b>801</b> to an ISP to connect to the Internet using a telephone line connection, modem <b>875</b> is connected to serial port <b>864</b> and PCI-to-ISA Bridge <b>835</b>.

[0066] While the computer system described in FIG. 8 is capable of executing the invention described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the invention described herein.

[0067] One of the preferred implementations of the invention is an application, namely, a set of instructions (program code) in a code module which may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, on a hard disk drive, or in removable storage such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.

[0068] While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For a non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.