Browse Prior Art Database

System and methods put togther to increase users productivity by extended usage of Rules to manage Contacts better. Disclosure Number: IPCOM000238863D
Publication Date: 2014-Sep-23
Document File: 3 page(s) / 61K

Publishing Venue

The Prior Art Database


Disclosed is a proposal that emphasizes on assisting user to understand and utilize the power of Email Rules which at times remains unnoticed. Due to this, user spends lot of time to move messages from Inbox to the required personal folder. Moving the the messages manually is a cumbersome task. Numerous publications and prior arts emphasize on factors like automatic creation of rules based on usage patterns, priorities etc. The disclosed proposal encourages user to create email rules after creating folders and contacts if there is match found.

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

Page 01 of 3

System and methods put togther to increase users productivity by extended usage of Rules to manage Contacts better .

Email rules is it the area whose power remains hidden and disclosed is the way to help user to make aware of it's power. The proposal facilitates user by analyzing the recently created folder name with the Contacts database entries and further proposingComparison with existing systems
Though there are existing systems that track code flow, the methods used by them are more elaborate.

Coverage tracking tools like Emma provide API coverage across the application. These tools are not designed for distributed systems. Though they provide coverage information, they do not give information on dynamic flow of code across a complete lifecycle of execution. Another aspect that most existing code flow tracking tools cannot perform is providing the code flow events for a scenario when multiple scenarios are executed concurrently.

Other code flow tracking tools monitor and report the execution detail on a per thread basis. Though these tools are primarily designed to tracking the execution of code and report API level metrics, they do not however bring in the notion of a scenario and as such cannot co-relate execution metrics across multiple threads (and or systems) to the scenario (use case or test case) under which they were executed. The system disclosed here can perform all these operations easily because execution is tracked against a scenario and the system propagates the scenario identity across threads and systems. Therefore data is generated in an inherently co-related manner.

With respect to the fault detection and prevention, the type of faults that the disclosed system can find is more application specific than existing systems. While there are many existing systems that can detect faults in a system, the faults detected are for a thread of execution or for an isolated API. The existing systems do not track the scenario and application context and hence do not consider them when raising faults. So, the faults raised by these systems are isolated and difficult to analyze further. The disclosed system uses the scenario and the application context to identify patterns in the application usage that leads...