IP Library Granted Patent US 9,659,324
Granted Patent B1
US 9,659,324 · App. 14/183,431 · Granted May 23, 2017

System, method, and computer program for aggregating fallouts in an ordering system

View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 9,659,324
App. No.
14/183,431
Granted
May 23, 2017
Kind
B1
Abstract

A system, method, and computer program product are provided for aggregating fallouts in an ordering system. In use, a repository of fallout errors associated with an ordering system is maintained. Further, one or more fallout events associated with the ordering system are automatically detected. Additionally, it is determined that the one or more detected fallout events are associated with at least one fallout error associated with processing an order in the ordering system. Furthermore, it may be determined whether the at least one fallout error corresponds to one of a plurality of stored fallout errors stored in the repository of fallout errors, in response to determining that the one or more detected fallout events are associated with the at least one fallout error from processing an order in the ordering system.

Claims (49)

1. A computer program product embodied on a non-transitory computer readable medium, comprising computer code for:

in an ordering system associated with a consumer telecommunications network that includes a plurality of resources including at least a business support system (BSS) and an operation support system (OSS), processing orders for one or more services using the resources;

executing software agents installed on the resources to monitor the resources to automatically detect, by the ordering system, a plurality of fallout events occurring on the resources and each capable of causing a fallout error within the ordering system which prevents one of the orders from being completed, the monitoring including:

monitoring transactions, in real time, executing in the ordering system to detect the fallout events,

utilizing one or more log files and error files associated with the ordering system to detect the fallout events,

searching across a plurality of database tables associated with the ordering system to identify one or more predetermined scenarios from which the fallout events are deduced, and

performing periodic testing of the ordering system to detect the fallout events;

processing, by the ordering system, the detected fallout events including for each of the detected fallout events:

(a) determining, by the ordering system, whether the detected fallout event caused an actual fallout error within the ordering system which prevented one of the orders from being completed,

(b) responsive to determining that the detected fallout event caused an actual fallout error within the ordering system:

(1) determining whether the fallout error, which was detected by the ordering system from a first one of the resources as a result of the fallout event, is a duplicate of a fallout error that has already been stored in a fallout repository responsive to another fallout event being detected by the ordering system from a second one of the resources,

(2) responsive to determining that the fallout error is a duplicate of a fallout error that has already been stored in the fallout repository, storing with the fallout error already stored in the fallout repository any attributes received with the fallout event detected from the first one of the resources that are not already stored with the fallout error in the fallout repository,

(3) responsive to determining that the fallout error is not a duplicate of a fallout error that has already been stored in the fallout repository, storing the fallout error in the fallout repository with the attributes received with the fallout event detected from the first one of the resources,

(c) responsive to determining that the detected fallout event did not cause an actual fallout error within the ordering system, the ordering system identifies the fallout event as an informational message and ignores the fallout event; and

after processing the detected fallout events, sending, by the ordering system, a request to resolve fallout errors stored in the fallout repository.

2. The computer program product of claim 1 , wherein the monitoring the resources to automatically detect, by the ordering system, the plurality of fallout events further includes:

invoking one or more APIs for querying information to automatically detect the fallout events.

3. A method, comprising:

in an ordering system associated with a consumer telecommunications network that includes a plurality of resources including at least a business support system (BSS) and an operation support system (OSS), processing orders for one or more services using the resources;

executing software agents installed on the resources to monitor the resources to automatically detect, by the ordering system, a plurality of fallout events occurring on the resources and each capable of causing a fallout error within the ordering system which prevents one of the orders from being completed, the monitoring including:

monitoring transactions, in real time, executing in the ordering system to detect the fallout events,

utilizing one or more log files and error files associated with the ordering system to detect the fallout events,

searching across a plurality of database tables associated with the ordering system to identify one or more predetermined scenarios from which the fallout events are deduced, and

performing periodic testing of the ordering system to detect the fallout events;

processing, by the ordering system, the detected fallout events including for each of the detected fallout events:

(a) determining, by the ordering system, whether the detected fallout event caused an actual fallout error within the ordering system which prevented one of the orders from being completed,

(b) responsive to determining that the detected fallout event caused an actual fallout error within the ordering system:

(1) determining whether the fallout error, which was detected by the ordering system from a first one of the resources as a result of the fallout event, is a duplicate of a fallout error that has already been stored in a fallout repository responsive to another fallout event being detected by the ordering system from a second one of the resources,

(2) responsive to determining that the fallout error is a duplicate of a fallout error that has already been stored in the fallout repository, storing with the fallout error already stored in the fallout repository any attributes received with the fallout event detected from the first one of the resources that are not already stored with the fallout error in the fallout repository,

(3) responsive to determining that the fallout error is not a duplicate of a fallout error that has already been stored in the fallout repository, storing the fallout error in the fallout repository with the attributes received with the fallout event detected from the first one of the resources,

(c) responsive to determining that the detected fallout event did not cause an actual fallout error within the ordering system, the ordering system identifies the fallout event as an informational message and ignores the fallout event; and

after processing the detected fallout events, sending, by the ordering system, a request to resolve fallout errors stored in the fallout repository.

4. A fallout aggregation system comprising:

a memory system of an ordering system associated with a consumer telecommunications network that includes a plurality of resources including at least a business support system (BSS) and an operation support system (OSS); and

one or more processing cores of the ordering system coupled to the memory system and that are each configured for:

processing orders, in the ordering system, for one or more services using the resources;

executing software agents installed on the resources to monitor the resources to automatically detect, by the ordering system, a plurality of fallout events occurring on the resources and each capable of causing a fallout error within the ordering system which prevents one of the orders from being completed, the monitoring including:

monitoring transactions, in real time, executing in the ordering system to detect the fallout events,

utilizing one or more log files and error files associated with the ordering system to detect the fallout events,

searching across a plurality of database tables associated with the ordering system to identify one or more predetermined scenarios from which the fallout events are deduced, and

performing periodic testing of the ordering system to detect the fallout events;

processing, by the ordering system, the detected fallout events including for each of the detected fallout events:

(a) determining, by the ordering system, whether the detected fallout event caused an actual fallout error within the ordering system which prevented one of the orders from being completed,

(b) responsive to determining that the detected fallout event caused an actual fallout error within the ordering system:

(1) determining whether the fallout error, which was detected by the ordering system from a first one of the resources as a result of the fallout event, is a duplicate of a fallout error that has already been stored in a fallout repository responsive to another fallout event being detected by the ordering system from a second one of the resources,

(2) responsive to determining that the fallout error is a duplicate of a fallout error that has already been stored in the fallout repository, storing with the fallout error already stored in the fallout repository any attributes received with the fallout event detected from the first one of the resources that are not already stored with the fallout error in the fallout repository,

(3) responsive to determining that the fallout error is not a duplicate of a fallout error that has already been stored in the fallout repository, storing the fallout error in the fallout repository with the attributes received with the fallout event detected from the first one of the resources,

(c) responsive to determining that the detected fallout event did not cause an actual fallout error within the ordering system, the ordering system identifies the fallout event as an informational message and ignores the fallout event; and

after processing the detected fallout events, sending, by the ordering system, a request to resolve fallout errors stored in the fallout repository.

Assignments (2)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Aug 4, 2016
From: AMDOCS SOFTWARE SYSTEMS LIMITED
To: AMDOCS DEVELOPMENT LIMITED; AMDOCS SOFTWARE SYSTEMS LIMITED
Reel/Frame 039695/0965 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 23, 2015
From: GUEZ, YOAV; EINI, YAKOV; SADAN, TOMER
To: AMDOCS SOFTWARE SYSTEMS LIMITED
Reel/Frame 036161/0853 →