DETAILED ACTION
Claims 1-17 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 6, 7, and 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Bessler et al. (US 8,060,396 B1) in view of Abalos (US 2017/0364549 A1).
Regarding claim 1, Bessler teaches the invention substantially as claimed including a method of monitoring a data processing system which is processing a transaction (Col. 1, line 24: method for monitoring an automated order entry system; Col. 2, lines 7-18: A method for monitoring order processing by an order processing system including applications operating on computer systems is also provided. The method comprises processing at least a portion of the orders by one or more of the applications, writing, by the applications, application data related to the applications processing of the orders to one or more log files, writing to the one or more log files hardware information related to the computer systems whereon the applications process the orders, and aggregating at least portions of the hardware information and application data to monitor the order processing.),
comprising steps of:
receiving event data from each of a plurality of data processing sub-systems making
up the data processing system, the event data corresponding to events taking place within the plurality of data processing sub-systems as the data processing system processes the
transaction (Background: Some enterprises depend upon a multitude of computer programs or applications which execute on several different computer systems to conduct their business. The applications may be developed using different programming languages and may have been developed at different times. The computer systems may be from different manufacturers and may employ different operating systems.; Col. 4, lines 20-36: FIG. 1, a business activity monitor (BAM) system 10 is depicted. Computer applications 12 and 14 execute on a first general purpose computer system 15. Computer application 16 executes on a second general purpose computer system 17…While three applications 12, 14, and 16 are depicted in FIG. 1, in some embodiments many more computer applications may be involved in providing the business process.; Col. 4, lines 37-58: Each of the applications 12, 14, and 16 occasionally generates reports, referred to hereinafter as logs, which they write out to a log file database 18. These logs may contain a time stamp indicating the date and time that the log was generated. The logs typically contain some textual information relating to the processing of the application 12, 14, or 16. The logs from the applications 12, 14, and 16 are written to separate log files in the log file database 18. For example, the logs from application 12 are written to an application 12 log file, the logs from application 14 are written to an application 14 log file, and the logs from application 16 are written to an application 16 log file. A BAM 20 is in communication with the log file database 18. The BAM 20 includes a first log adapter 22 which reads the application 12 log file, a second log adapter 24 which reads the application 14 log file, and a third log adapter 26 which reads the application 16 log file. In reading the log file, each log adapter 22, 24, or 26 filters through all logs and finds those log file entries which speak to the performance of the application 12, 14, or 16, parses the selected log file entries to extract the needed information, and stores this needed information for processing by the BAM 20.);
deriving address information from the received event data, wherein the address
information corresponds to a logical location in a corresponding sub-system where data
related to a corresponding event can be perceived as having been either processed by, stored in or, having held a state in (Col. 2, lines 9-15: The method comprises processing at least a portion of the orders by one or more of the applications, writing, by the applications, application data related to the applications processing of the orders to one or more log files, writing to the one or more log files hardware information related to the computer systems whereon the applications process the orders; Col. 7, line 64 through Col. 8, line 5: A software agent 512 creates derivative state objects, associated with the state objects stored in the workflow database, which it stores in a derivative database 514. In some embodiments the derivative state objects in the derivative database 514 may be created by database code in one of the databases 510 or 514, such as database triggers. An analysis tool 516 is in communication with the derivative database 514 and analyzes the derivate state objects to support order tracking and order reporting.; Col. 9, lines 5-6: The states include not started, in progress, completed, rejected, and not applicable.);
mapping the address information to corresponding process status indicator labels
(Col. 5, line 60 through Col. 6, line 22 The headings of the table 162 include order ID 164, order type 166, and various applications 168, 170, 172, 174, and 176. The information displayed in the columns for each application 168, 170, 172, 174, and 176 include the time and date of the entry of the order into the application and the time and date of the exit of the order from the application. The information boxes in the columns for each application 168, 170, 172, 174, and 176 is color coded in accordance with how long the application took to process the order based on the application's service level agreement. If the processing time is well within the service level agreement, the information box is color coded according to a first color.; Col. 8, line 65 through Col. 9 line 15: Turning now to FIG. 18, the component status GUI screen 630 is depicted to contain service order ID, component type, component ID, and a graphical representation of the milestones or states the order component must pass through to complete. The graphical representation, or graphical indicia, depicts alternate paths between states, indicating optional paths with a dotted line and indicating mandatory paths with a solid line. The states include not started, in progress, completed, rejected, and not applicable. The state of each milestone is depicted using color coding including a fourth color code, a fifth color code, a sixth color code, a seventh color code, and an eighth color code. The component status GUI screen 630 includes a view component status selector tab 632 which causes the component status GUI screen 630 to display and a milestone duration selector tab 634 which causes a component milestone duration GUI screen 650 to display which indicates how long it took for the component to complete each of the milestones.); and
displaying the process status indicator labels for review by a user (Col. 8, line 65
through Col. 9 line 15: Turning now to FIG. 18, the component status GUI screen 630 is depicted to contain service order ID, component type, component ID, and a graphical representation of the milestones or states the order component must pass through to complete. The graphical representation, or graphical indicia, depicts alternate paths between states, indicating optional paths with a dotted line and indicating mandatory paths with a solid line. The states include not started, in progress, completed, rejected, and not applicable.; Col. 9, lines 22-28: Turning now to FIG. 20, the order status GUI screen 670 is depicted to contain source system order ID, service order ID, order entry time, and a graphical representation of the milestones or states the order component must pass through to complete. The order status GUI screen 670 provides a visual representation of where the order currently resides in the workflow.; Col. 9, lines 40-49: One can imagine an operator, when handling a customer call, using this tool to find what the hold-up is in fulfilling the customer's order. The operator might bring up the order status GUI screen 670, visually traverse the order milestones while confirming "Green, green, red, ah ha! The order has been stuck in process Y for 114 days!" This functionality can save much time and will result in more customer understanding than the former process which may have required digging through unrelated and disparate information for several hours.).
Bessler teaches in the Background “Some enterprises depend upon a multitude of computer programs or applications which execute on several different computer systems to conduct their business. The applications may be developed using different programming languages and may have been developed at different times. The computer systems may be from different manufacturers and may employ different operating systems.” However, Bessler does not explicitly disclose the event data having a data structure format unique to the specific data processing sub-system from which the event data was received.
However, in a similar field of endeavor, Abalos teaches the event data having a data structure format unique to the specific data processing sub-system from which the event data was received ([0014] In one embodiment, the business layer of includes an enterprise service bus (ESB) operable to integrate data from multiple applications, systems, and platforms of a network. Notably, the ESB is configured to facilitate data integration for applications, systems, and platforms that may use different data formats, communications protocols, and the like. The ESB defines a software/hardware architecture for integrating the data associated with the systems over a bus-like infrastructure. In other words, the ESB integrates data from different systems of the network by implementing a central communication bus, such as a message bus, between the systems. By doing so, the ESB enables access to, sharing, and integration of data of the different systems using a single, unified framework.; [0039] In one specific example, and with reference to Table 1 below, a user of the user interface 130, shown in FIG. 1, may wish to determine whether data values for a particular order—order #1234—are consistent across two systems—System A and System B. For example, System A may correspond to an operational support system and System B may correspond to a business support system, each of which includes an entry corresponding to order #1234 that includes data replicated between System A and System B.; [0040] To the extent System A and System B function using different message formats, routing protocols, and the like, the ESB 110 performs any necessary conversion or transformation of data or messages to facilitate communication between the user interface 130, System A, and System B. For example, in certain implementations, the ESB 110 includes integration servers, data access components, or adapters corresponding to each of System A and System B such that messages or data from System A and System B are converted from system-specific formats or protocols to a common messaging format or protocol for transmission over the ESB 110.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Abalos of integrating data with different formats from multiple systems associated with a business process as taught by Bessler. The modification would have been motivated by the desire allowing customers to identify in real-time the status of a business order.
Regarding claim 2, Abalos teaches wherein the plurality of data processing sub-systems include at least one Enterprise Service Bus data processing sub-system ([0014] In one embodiment, the business layer of includes an enterprise service bus (ESB) operable to integrate data from multiple applications, systems, and platforms of a network. Notably, the ESB is configured to facilitate data integration for applications, systems, and platforms that may use different data formats, communications protocols, and the like.).
Regarding claim 6, Bessler teaches wherein the mapping step is carried out using a mapping table, mapping address information to process status indicator labels, where the mapping table is populated during a runtime phase of operation of the data processing system (Col. 6, line 60 through Col. 6, line 5).
Regarding claim 7, Bessler teaches wherein event handlers are deployed to a runtime
environment of the data processing system in order to receive event data from the data
processing system while the data processing system is in the runtime phase of operation (Col. 4, lines 50-67: The BAM 20 includes a first log adapter 22 which reads the application 12 log file, a second log adapter 24 which reads the application 14 log file, and a third log adapter 26 which reads the application 16 log file. In reading the log file, each log adapter 22, 24, or 26 filters through all logs and finds those log file entries which speak to the performance of the application 12, 14, or 16, parses the selected log file entries to extract the needed information, and stores this needed information for processing by the BAM 20. The BAM 20 may invoke each of the log file adapters 22, 24, and 26 on a periodic basis, for example every five minutes or at some other periodic rate. The log adapters 22, 24, 26 in some embodiments may be implemented as Perl scripts. The BAM 20 informs itself about the performance of the applications 12, 14, and 16 through the log adapters 22, 24, and 26. In some embodiments where there may be many more applications, there may be many more log adapters than those shown in FIG. 1.).
Regarding claim 11, Bessler teaches wherein the event data includes an identifying element of a document instance being processed by the data processing system (Abstract: The order processing monitor comprises an application to process a portion of an order and to write application data to a log file, the application data related to the processing of the order by the application).
Regarding claim 12, the combination teaches wherein the identifying element of a document instance includes a customer number and a purchase order number (Bessler’s Col. 3, lines 51-56: A key to maintaining customer satisfaction is the ability to query the real-time status of any order and identify its present state within the workflow, so that the status may be reported to the customer on demand. It is also desirable to be able to research all orders for a particular customer, across all processes within the workflow.; Abalos’ [0039] In one specific example, and with reference to Table 1 below, a user of the user interface 130, shown in FIG. 1, may wish to determine whether data values for a particular order—order #1234—are consistent across two systems—System A and System B. For example, System A may correspond to an operational support system and System B may correspond to a business support system, each of which includes an entry corresponding to order #1234 that includes data replicated between System A and System B.).
Regarding claim 13, Bessler teaches wherein the processing of the transaction includes the data processing system progressing through a plurality of waypoints, where a first group of the plurality of waypoints correspond to points in the transaction which relate to a status indicator label, and a second group of the plurality of waypoints correspond to points in the transaction which do not relate to a status indicator label (Col. 5, line 38 through Col. 6, line 24; Col. 8, line 65 through Col. 9, line 55).
Regarding claim 14, Bessler teaches wherein the displaying step displays the first group of the plurality of waypoints to a first group of users, and displays the first and second groups of the plurality of waypoints to a second group of users (Col. 5, lines 38-51: FIG. 2 depicts the operator tab 102 having been selected, and an operator view top-level GUI screen 108 is displayed. The operator view top-level GUI screen 108 provides a Ticket Information view selector 110, an Order History view selector 112, a Workflow Alarms view selector 114, and an Utilization Alarms view selector 116. Selecting the Ticket Information view selector 110 displays information on open trouble tickets which the BAM 20 extracts from the internal ticketing system. Selecting the Order History view selector 112 causes an Order History GUI screen 150 to display. Selecting the Workflow Alarms view selector 114 causes a Workflow Alarms GUI screen 200 to display. Selecting the Utilization Alarms view selector 116 causes a Utilization Alarms GUI screen 250 to display.).
Regarding claim 15, Bessler teaches wherein the second group of users are technical support
Users (Col. 9, lines 40-41: One can imagine an operator, when handling a customer call, using this tool to find what the hold-up is in fulfilling the customer's order.).
Regarding claim 16, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above. The additional limitations of “A system having a processor and a memory, where the memory stores instructions adapted for, when executed by the processor, carrying out a method” is taught by Bessler in at least Col. 11, lines 14-18: The processor 982 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 984), ROM 986, RAM 988, or the network connectivity devices 992.
Claims 3 is rejected under 35 U.S.C. 103 as being unpatentable over Bessler et al. (US 8,060,396 B1) in view of Abalos (US 2017/0364549 A1) in further view of Maes et al. (US 2009/0228584 A1).
Regarding claim 3, Bessler nor Abalos expressly teach wherein the address information for the Enterprise Service Bus data processing sub-system includes a process name, an event type, and a node identifier.
However, Maes teaches wherein the address information for the Enterprise Service Bus data processing sub-system includes a process name, an event type, and a node identifier ([0013]; [0087]; [0089] The system 1000 can also include a presence server 305 as described above and communicatively coupled with the ESB 1005. As noted, the presence service provided via the presence enabler 310 of the presence server 305 can maintain a set of presence profiles 325 for any number of principals participating in the service. For example, a presence profile 325 can be maintained for or related to the monitored device 345. The presence profile 325 can include a set of one or more presence attribute 326. The presence attributes 326 can include attributes identifying or related to presence information as noted above. However, the presence attributes 326 described herein are not limited to identifying or indicating presence information. Rather, embodiments of the present invention provide for using presence attributes 326 to identify or indicate any type of information related to the principal such as the monitored device 345. For example, such information can include but is not limited to a state or status, information collected or generated by an application or process, etc, as well as presence information. Additionally or alternatively, information indicated by the presence attributes can include other types of information. For example, information indicated by one or more presence attributes can include but is not limited to a multimedia document, a Uniform Resource Identifier (URI) to a document of stream, etc maintained by or provided via a media server 1010 communicatively coupled with the ESB 1005.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maes with the teachings of Bessler and Avalos to have the ESB handle different data pertaining to the source of the messages of a heterogeneous processing environment. The modification would have been motivated by the desire of combining known elements to yield predictable results.
Claims 4, 5, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Bessler et al. (US 8,060,396 B1) in view of Abalos (US 2017/0364549 A1) in further view of Lambert et al. (US 2015/0100386 A1).
Regarding claim 4, Bessler teaches wherein the mapping step is carried out using a mapping table, mapping address information to process status indicator labels, (Col. 6, line 60 through Col. 6, line 5: Turning now to FIG. 4, a second view of the Order History GUI screen 150 is depicted with order histories displayed in a table 162. This exemplary information might be displayed after activating the submit button 160, as discussed above. The headings of the table 162 include order ID 164, order type 166, and various applications 168, 170, 172, 174, and 176. The information displayed in the columns for each application 168, 170, 172, 174, and 176 include the time and date of the entry of the order into the application and the time and date of the exit of the order from the application. The information boxes in the columns for each application 168, 170, 172, 174, and 176 is color coded in accordance with how long the application took to process the order based on the application's service level agreement.).
Bessler nor Abalos expressly teach where the mapping table is pre-populated during a modelling phase, prior to a runtime phase of operation of the data processing system.
However, Lambert teaches where the mapping table is pre-populated during a modelling phase, prior to a runtime phase of operation of the data processing system ([0057] Relationship mapping between the component objects 205, 230, 232, 234 and 236 and business blocks 204 through 220, and permutations of target state models, enables users to quickly explore options during modeling and ideation phases).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lambert with the teachings of Bessler and Avalos to establish mapping relationship prior to runtime during modeling and ideation phases. The modification would have been motivated by the desire of combining known methods to yield predictable results.
Regarding claim 5, Lambert teaches wherein a regular expression is used during the modelling phase to create at least one entry in the mapping table ([0057]).
Regarding claim 8, Lambert teaches wherein event data received from the event handlers are input to a database, and the method further includes the step of displaying the event data onto a display screen, and receiving drag-and-drop input from a user whereby the user can drag specific event data and drop it into a category corresponding to a specific process status indicator label ([0055] Objects 205, 230, 232, 234 or 236 may also be added to the displayed business plan by dragging and dropping component objects 242 from a component block 240 in a graphical user interface (GUI) display of the canvas 202 directly into any of the nine blocks 204 through 220, wherein the dropped component object 242 will inherit the correct data elements of the receiving blocks 204 through 220 to capture the financial, impact, risk and probability variables and factors of that block…This capturing of details enables a user of the canvas 202 to ensure that they've considered the additional attributes impacting the business model displayed, and also provides a direct feed into risk and outcome probability simulations for execution by analytical engines of the canvas 202.; [0056] The canvas 202 thereby captures relevant variables for a future business direction, using the visualizers of the collaborative ideas all on one page, optionally with proper color coding and relationship mapping, while feeding input data into simulation analytical models to show risk and outcome probability and fast-track the innovation process while reducing the risk of making a wrong bet in changing business directions.).
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Bessler et al. (US 8,060,396 B1) in view of Abalos (US 2017/0364549 A1) in further view of Giebel et al. (US 2013/0166675 A1).
Regarding claim 9, Bessler nor Abalos expressly teach wherein the mapping step takes into account an address element hierarchy when performing the mapping.
However, Giebel teaches wherein the mapping step takes into account an address element hierarchy when performing the mapping (Fig. 4B shows a hierarchy of nodes in 440a and its corresponding description in 440b. In 440b it shows the address/node name for each of the elements in the hierarchy.; [0040] Specifically, a first parameter 400a "IN_BO_NODE_NAME" specifies the initial node of a business object from which hosted data is requested. For example, the business object node may be for sales order items or the like. A second parameter 400b "IN_NODE_IDS" specifies instances of this business object node. For example, the identifier may be for a specific sales order item node instance of the business object. The set of parameters 410, labeled "IN_REQUESTED_PATH", provides the definition of the sub-path starting from the node instances provided in the set of parameters 400. The first parameter 410a is a table definition of paths which refer to each other. Parameter 410b "LEVEL" and 410d "SOURCE_BO_NODE_NAME" define the tree structure of the paths.; [0041] The second parameter 410b "LEVEL" specifies the level of the path definition from which hosted data may be retrieved. Each level refers to an entry of the level above with the parameter 410d "SOURCE_BO_NODE_NAME". For the first level there is no level above and it refers to the node instances defined by the set of parameters 400.; [0042] FIG. 4B is a simplified schematic showing a hierarchy of nodes (e.g., tree structure) of a business object, for example of a sales order business object according to the sales order example being considered. The hierarchy of nodes is shown in FIG. 4 in both diagram format 440a and text 440b. Numerals 1-5 for the various nodes of the sales order business object are shown in the diagram 440a and the text 440b to indicate the same instances of the nodes of the sales order business object. The hierarchy of nodes of the example sales order business object may include a root node (e.g., a specific sales order), item nodes (e.g., specific items of the specific sales order), which are sub-nodes of the root node, and sub-sub-nodes of the root node, which according to the sales order example being considered may include schedule line nodes (e.g., schedule dates for delivery of items)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Giebel with the teachings of Bessler and Abalos to denote a hierarchy among business processes in a sales order. The modification would have been motivated by the desire of allowing users to understand the different operations that make up a sale order.
Regarding claim 10, Giebel teaches wherein the taking into account of the address element hierarchy includes mapping a parent node of the address information prior to mapping a child node of the address information (Fig. 4b elements 440a and 440b; [0040-42]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J Li can be reached at (571)272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights