Browse Prior Art Database

A method and system for recommending patches to customers Disclosure Number: IPCOM000248708D
Publication Date: 2016-Dec-28
Document File: 3 page(s) / 62K

Publishing Venue

The Prior Art Database


Disclosed herein is a system and method to analyze customers' user behavior of a software on source codes level and compare the "used" source codes with updated source codes in a new fixpack to determine whether to push the new fixpack to customers.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.


A method and system for recommending patches to customers

During the life cycle of software or system, software vendors usually provide fixes and updates for customer’s software, hardware, and operating system. A fix pack contains one or more fixes or updates for specific defects or features. Fix center usually pushes a notification to customer when a new fix pack is released, or the auto update feature will check whether there is any new fix pack periodically.

However, based on varies of usage, not all customer are interested in the new fix pack. If the fix pack contains fixes and updates on the features that a customer never uses, this fix pack may not make sense to this customer.

Customer may select to install all of the fix packs or download and read the release notes to decide whether to install the fix packs. This is time consuming and customer may not completely understand whether the fix packs is helpful for those features that he/she really cares about.

A system and method is provided here to help identifying whether to advise customer to install a new fix pack.

In brief, the method contains the following steps:

1. Assign a unique Id for each features or component. 2. Creating a map of relationships between: feature – component – file – method. 3. When customers use the software or system, record which item (feature, component, file or method) is touched. 4. When developers fix or update a defect or feature, record which files and methods are updated. 5. When the fix pack is released, fix center decides whether to push the fix pack to a customer by comparing the overlap of updated items and touched items.

Detailed descriptions are as below:

1. Divide the software assets into features or components and create a map of relationships between: feature – component – file – method.

2. An asynchronous daemon process is running in background.


3. When customer uses the system, the daemon process will record which Feature/Component/File/Method is accessed and generates an access history, e.g.:

Table 1: Accessed Map

Feature Component File Method Accessed Date

Basic Search BasicSearchEJB runBasicQuery 1 2016-09-01

Advanced Search

AdvancedSearchEJ B

AdvancedSearchEJBBean.jav a

runAdvQuery 0

Batch Delete BatchOperationEJB runBatchDelete 0

Delete ComponentCRUDEJ B

ComponentCRUDEJBBean.ja va

deleteComponent 1 2016-09-10

4. When software developer submits fix or up...