Example #1

Defect And Source Change Tracker for easy Regression testing

Disclosed is a software product feature that is unique from others in that specific lines of code are linked with a software defect report. Previous disclosures identify files changed to fix a reported defect, but not specific lines of code. Subsequent changes to specific code alerts defect author that regression testing of that code may be required. Defect And Source Change Tracker (DASCT) can be used to implement tight integration between defects and the code changed to resolve them. Using DASCT, when a developer starts fixing a defect, there is a link created between the defect and the lines of source code that changed. Thus it is indirectly creating a relation between the source code controller and bug tracker for the lines of code changed for each defect. When a developer modifies source used to fix another defect, this integration will warn them about breaking the defect already fixed. The responsible quality engineer can also be notified that code has been modified and that they might need to revalidate one or more related defects. There is also a link between the source code and the defect, so if the defect reappears in the future; it is easy for the developer the see the code he changed to fix this defect.

To implement Defect And Source Change Tracker (DASCT), it is necessary to establish a link/bridge between the source code control (change management) solution and defect-tracking tool. When the developer fixes a defect, they need to reference what source code that is changing in source code control. Once the source code is changed, using DASCT, the defect tracker will store the lines changed to fix this defect. The next time a developer touches the same code, DASCT will warn that the same code resolves another defect. Developers can still do the changes, (some cases it may be necessary), but the quality engineer responsible for the defect will be notified of the source code modification. The quality engineer can validate the defect again and can decide to keep the latest source code for future reference if the defect is not broken. Even if a developer changes the same code, it does not mean the previous defect will be broken. So, when both the developer and QE agree the new fix does not affect the current defect fix, the new code will used to compare future changes.

The quality engineer will no longer need to regress defects previously submitted until notified by DASCT about a change, which saves time. For developers, if the quality engineer re-submits the defect (this will happen only if developer did the fix ignoring DASCT), he can easily figure out the lines changed. DASCT may be referencing multiple defects with multiple lines of code if same source code changes are used to fix multiple defects. In this case, all the defect submitters will receive notification when the source code is changed. DASCT can be implemented between any change management or source code control solution and any defect tracking tool.

The following diagram explains how DASCT keeps track of the source code changes mentioned above. Here, DASCT is acting as a central engine, which can talk to both the defect tracker and source code control software. DASCT can convey messages to both the defect tracker and source code control for changes and capable of notifying users, both developers and quality engineers, about the change



Example #2

Automated Software Product Inventory Control

Described is a mechanism to manage software products across environments via a set of common tools/structures. Software is a composite of many different entities.  These entities can exist across environments associated with the development, delivery, and usage of the software.  The characteristics of software entities may themselves be different. For example, a program in the development environment may be a source part while a program in the production environment may be an external object or load module.  The owner of these entities is usually the same in these environments.  Software entities may also be part of a software product which exists at some maintenance level.  It becomes very important to correlate software product control information for a product across these environments such that development activities, maintenance activities, and problem determination activities can be done with some order and control.

The problem today is that there is no good mechanism to manage software products across environments via a set of common tools/structures.  For example, an IBM development tool provides a mechanism for developing source parts for a product but the tool manages source parts in a totally different manner than the way the production environment handles its corresponding objects in the Licensed Program (LP) production environment.

The objective of this disclosure is to increase software
management process efficiencies by defining common processes and structures for software.  These common processes and structures allow information obtained during LP Library Control System Setup to be used throughout the LP's life cycle to manage the software.

Another objective of this disclosure to define how LP packaging
information defined during the development cycle may be propagated to environments in which software may exist.  These environments consist of the following:
  o  Development environment - This is the environment in which
      software is developed.  It contains the source entities from
      which LP objects are formed.
  o  Intermediate production environment - This is the environment in which released software may exist prior to being installed.
  o  Production environment - This is the environment in which
      software is installed within an operating system.  Software
      packaged as LPs provide some well defined set of functions.

Product control information is defined during the development
phase.  This information provides a mechanism to:
  1. Declare up-front the data needed to manage software in the
       development environment.
  2. Manage the transition of software in the development
       to the production environments
  3.  Insure the consistency and completeness of information across all environments.

The Figure illustrates:
  1. The software environments
  2. The transitional flows between the environments
  3. The functions this disclosure claims for the development




Example #3:

Efficient Gathering of Computer Audit Data Before and During Attack


1. Meaningful, reliable audit/log traces useful for forensic analysis in computer security are basically a necessity for any security analysis, but can quickly get very large (e.g. in the order of 100Mb/hour, see [1]), adding a significant performance hit onto computer systems. Therefore in practice only a low level of audit data is gathered, which is not allowing a detailed forensic analysis in case of an intrusion (attempt).


2. In case of a successful intrusion on a computer system, the attacker can in most cases change audit/log traces, thereby making an analysis of the intrusion very hard resp. destroying the evidence and consequences and repercussions of an intrusion. Current solutions:

¥       usually in security conscious organizations a compromise is taken: a manageable size of log data (restricted in detail and number of machines - see e.g. [1], [2]) is taken to a central server (to avoid tampering of an attacker) and stored for a time, which allows for discovery of a intrusion (attempt) and analysis of the logs, before removal of the log data.

¥       alternatively, cryptographic methods are used to make available logs tamper resistant and destroying of log data at least detectable [3]


This compromise is unsatisfactory from an intrusion detection standpoint for security & forensic analysis, therefore an additional solution is proposed here. In normal operation, the monitored computing systems (1) keep extensive audit logs locally (2) or remotely by sending log data to a central logging server (3), but to keep log files manageable, data is only kept for a very limited time, say x minutes (where x is in the order of about 10 minutes, which should correspond to the worst case reaction time of the deployed intrusion detection system (4)). If an attack against the monitored computing system (1) is detected by some intrusion detection sensor (4), the extensive audit trail from x minutes before the attack is immediately fetched via a secure connection either from the monitored computing system itself in case of local logging (5), or from the central log server in case of remote logging (6).

Additionally (and optionally) the intrusion detection sensor (4) can change the logging behavior on the attacked, and now suspicious, computing system (7), e.g. to switch to 2 an even more detailed level of logging, or remote instead of local logging. A possible embodiment could be done with open-source tools: 􀁺 Secure Auditing for Linux [2] can be used as source of a detailed audit trail, in their architecture using a central remote collection point for the logs 􀁺 Snort [4] can be used as intrusion detection sensor (4). Snort can be customized to react with arbitrary scripts to intrusion alarms (by extension of the 'react' method of the 'flexibly response' module). 􀁺 ssh [5] can provide a secure channel to gather the log data in (5)/(6).


Example #4

System for Upgrading Software and Related Data Files On a Need Basis Without Querying a Database


Problem or Opportunity

Applications and data files that are frequently run or accessed need to be as up-to-date as possible to ensure the most efficient system processing. The process for such an upgrade must be fast, accurate, and most of all, secure.

Currently, the process for updating an application is based on two factors: periodicity and an online database search. For instance, the user computer is set to query an online database whenever a certain period of time elapses: daily, weekly, or monthly. The database is available at a specific website that the applicationÕs vendor maintains. The process searches and queries the database for an entry indicating that a newer version of the application is available. If an upgrade is found, the user computer is notified. When the notification is accepted (with the simple click of a ÔYesÕ button, and unsecured process), the upgrade is downloaded and installed on the user computer.

Sometimes, this upgrade process can be set to occur when the user computer starts up or shuts down. More often, however, this upgrade process happens in real time during the work day while the user computer is processing and, as a result, can interrupt work flow.

The process for updating a data file is manual. The user computer must directly access a vendorÕs website and manually search the online database for new versions of specific data files. This process is labor intensive. It is also happenstance: the user must remember to regularly search for available updates. Oftentimes, the user finds that no such update is available and, as a result, wastes time and effort.

Both these processes—upgrading applications and updating data files—also depend on the integrity of the queried database. The database must accurately represent that upgrades and updates are available.

Detailed Description of Invention:

Applications must be upgraded and data files updated seamlessly, regularly, quickly, accurately, and securely. This invention accomplishes all these objectives.

As shown at a high level in Figure 1, the user computer checks for application upgrades and data file updates based on a specific number of uses (then a period of time as a backup position), directly searches for a newer executable or data file (rather than querying a database), and downloads and securely installs the new file when it is most efficient for the user computer and user.

Figure 2 depicts a detailed flowchart of the method involved in upgrading applications/updating data files (collectively referred to as upgrading for the sake of simplicity).

Method starts with step 1, where the user computer establishes the following settings:

¬    The number of times an application must run or a data file must be accessed, after which a search for a newer version is undertaken. For example, if the usage number is set to 5, then the user computer searches for a newer file after the application has run 5 times or after the data file has been accessed 5 times.

¬    An amount of time that must elapse, after which a search for a newer version is undertaken. This is a threshold setting. It is set so that the user computer can ensure that an application or data file is updated after a specific amount of time regardless of the number of times it has run. For example, the user computer searches for newer files after every 5 uses or every day, whichever is sooner. This setting is particularly useful for applications or data files that are rarely run or accessed.

¬    When the user computer should search for a newer file: at startup, at shutdown, at a specific time of day, or after the usage number has been attained. This setting enables the user computer to determine when a search for a newer file actually happens. The user has some control over system performance, when new files are installed, and how often.

Using these settings, the user computer determines when to search for a new file.

In step 2, the applications are running on user computer and data files are accessed as part of normal operation of user computer.

In decision step 3, the user computer periodically checks to see if the criteria established in step 1 are met. If so, the method proceeds to step 4. If not, the method returns to step 2.

In step 4, user computer searches for a newer file, accessed from a cloud of online resource files[1] where software is available as a service. The user computer attempts to locate the actual file rather than querying a database (since maintaining a database first requires the newer file be available and then, second, requires that the database be accurately updated).

In decision step 5, user computer determines if the new file is newer by comparing to the versions currently available on the user computerÕs resident hard drive. The comparison can be based on the file name, the fileÕs date and time, or any other method that uniquely identifies a newer file. If so, the method proceeds to step 6. If not, the method returns to step 2.

In step 6, when a newer file is found, the user computer automatically downloads it in the background when system processing on the user computer is low so as not to adversely affect processing.

In step 7, after the file has successfully downloaded, the user computer notifies the user that an upgrade or update is available, lists the details of the downloaded file, and specifies if a restart is required following installation. (In general, installing executable files require a restart whereas installing data files does not.) This notification happens in accordance with the specified search-time criteria (described in the third bullet above), so the user is interrupted only when requested.

In decision step 8, the user or user computer makes a determination whether or not to install the update. If so, the method proceeds to step 9. If not, the method returns to step 2.

In step 9, to ensure the security of the user computer and that of the downloaded file, the user reviews the details of this file to ensure its accuracy and legitimacy and may enter a password to initiate the installation (rather than simply clicking a ÔYesÕ button). After installing the upgrade or update, the user computer automatically restarts (if required) or immediately returns processing to the user. Method ends.



Example #5

Method for Uninstalling an Unwanted Application Upgrade


Problem or Opportunity

            Upgrading the vast majority of applications is simple. At varying times, the application polls the appropriate web sites searching for an upgrade to the version currently running on the user computer. When one is found, the upgrade program notifies the user. In general, the user can then choose to upgrade immediately or put off the upgrade for a brief period of time (such as a day). Eventually, the user chooses to install the upgrade.

Sometimes, however, after an upgrade is installed, the user simply does not want it. This can happen for any number of reasons. The user:

¬    Discovers that the upgrade is incompatible with the operating system currently running on the user computer.

¬    Realizes that the upgrade fixes an incompatibility with another application which was not installed or even owned.

¬    Sees that the upgrade contains unwanted (oftentimes, even annoying) features.

¬    Simply does not want the upgrade.

When this occurs, the user has only one alternative: to reinstall the application from its initial version and then install whatever upgrades were available to bring the application back to the version that was running just before the most recent—and unwanted—upgrade was installed. In other words, the user must reinstall the application from the bottom up.

This invention allows the user to uninstall the most recent upgrade, a much quicker and more reliable process. In other words, arrive at the applicationÕs previous version from the top down.


Detailed Description of the Invention

Figure 1 shows the flowchart depicting the method for uninstalling an application upgrade. Following the flowchart is a more detailed explanation of each step


The method of uninstalling an unwanted upgrade starts with step 1. In this step, the user computer identifies an available upgrade, and notifies the user who then accepts the upgrade.

In decision step 2, the user computer asks if the user wants the ability to uninstall the upgrade. If yes, the method proceeds to step 3; if no, the method continues with step 5.

In step 3, the user computer creates an uninstall version of the application to be upgraded. The user computer copies the current version of the application and all its related files, and identifies the location of each of these files. The user computer basically creates a snapshot of its current structure in such a manner as to make uninstalling the upgrade simple, seamless, and error free.

In step 4, the user computer asks the user to specify a period of time to keep the uninstall version of the application being upgraded. The user enters the number of minutes, hours, or days to keep the uninstall version. This setting can be changed later as necessary by the user (see step 10).

In step 5, the user computer upgrades the application as required, requiring a password and restarting as necessary.

In decision step 6, after installing the upgrade, the user computer identifies if an uninstall version has been created. If no, the method proceed to the end and finishes; if yes, the method continues with step 7.

In decision step 7, after the specified period of time (set in step 4) elapses, the user computer asks if the user wants to uninstall the upgrade. If yes, the method continues to step 8; if no, the method proceeds to step 9.

In step 8, the user computer reverts to the previous version of the upgraded application by re-establishing the appropriate settings as saved in step 3, then deleting the files related to the upgrade. The method then ends.

In decision step 9, the user has decided not to uninstall the upgrade; in other words, to keep the upgraded version of the application. The user computer asks if the user still wants the ability to uninstall the upgrade at a later time. If yes, the method continues with step 10; if no, the method proceeds to step 11.

In step 10, the user either confirms the period of time specified in step 4 or sets a different period of time. The method returns to step 7.

In step 11, the user has decided to permanently keep the upgraded version of the application. The user computer then deletes the uninstall version created in step 3.

The method ends.