DETAILED ACTION
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 .
This office action is responsive to communication filed on 05/14/2024.
Claim Objections
Claims 7 and 13 are objected to because of the following informalities: It is suggested to delete “in” (line 2, before unsuccessful) and insert --- is ---. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 8, and 15, the limitation of “receiving at least one data stream at an input module, a data stream of the at least one data stream comprising a plurality of network event data in real-time” is confusing. Does Applicant mean to recite “ receiving, at an input module, at least one data stream of a plurality of data streams” or “ receiving, at an input module, a data stream comprising a plurality of network event data in real-time”. It is kindly suggested to clarify such limitation.
Regarding claims 1, 8, and 15, the limitation of “transforming the network event data in accordance with the predetermined rule” is not clear. It is not clear to what exactly such network event data is transformed to. It is kindly suggested to clarify such limitation.
Claims 2 – 7, 9 – 14, and 16 – 20 are necessarily rejected as being dependent upon the rejection of claims 1, 8, and 15.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 – 5, 8 – 12, and 15 - 19 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Julio Navas (US 2010/0125584; hereinafter Navas).
Regarding claim 1, Navas discloses a system for network event data streaming and processing via modular network event data architecture abstract; fig. 5), the system comprising:
a processing device ();
a non-transitory storage device containing instructions when executed by the processing device (paragraphs [0120 – 0121], [0126 - 0127]), causes the processing device to perform the steps of:
receiving at least one data stream at an input module, a data stream of the at least one data stream comprising a plurality of network event data in real-time (610, fig. 6; paragraphs [0020 - 0021], [0034]; Navas discloses that the indexing is part of a system that handles access to real-time event data within an enterprise. Briefly, consider an enterprise system that includes multiple data sources. Real-time event data may be obtained from the data sources via query ));
determining, at the input module, a feature of at least one network event data of the plurality of network event data (602, fig. 6; paragraphs [0014 – 0015], [0092 - 0093]; Navas discloses a network node having an indexing engine for indexing and routing queries based on descriptive name identifiers)
labeling, at the input module, the at least one network event data with a label corresponding with the feature (612, fig. 6; paragraphs [0020 - 0021]; Navas discloses that the system that enables the routing of queries to the data sources coordinates data through indexing with descriptive labels or identifiers that indicate a location and contents of the data.);
retrieving, at the input module, a preconfigured routing path corresponding to the label from a path database (paragraphs [0111]; Navas discloses that with HSPF, each LE router has a routing table entry for each destination in the network. Each entry contains information on a destination's event and data content, IP address, and the shortest path to the destination. The destination for a message is defined as the event or data content that is sought);
routing, from the input module to a first processing module of a plurality of processing modules determined by the preconfigured routing path, the at least one network event data (paragraph [0111]; Navas discloses that when forwarding a message, an LE router uses its routing table information to determine the specific final destinations that contain that event or data content and then forwards the message on the shortest path to those destinations), wherein the first processing module comprises a microservice engine to implement a predetermined rule based on corresponding rule data from a rules data database, and wherein the first processing module is reusable for other preconfigured routing paths (paragraphs [0031], [0049]; Navas discloses that the event producer may internally filter events and determine which event should be notified externally through a determination algorithm. Such a determination algorithm could be rules-based as to event type, event significance, etc., will be considered information to share externally);
transforming the network event data in accordance with the predetermined rule (paragraphs [0035], [0045], [0058]; Navas discloses that the transformation or translation definitions provide a mapping of the local schema to the global schema. The transformation definitions may be implemented in the form of a lookup table, rules, or other logic. Consider the following tables); and
routing, from a final processing module of the plurality of processing modules to an output module, as determined by the preconfigured routing path (paragraph [0102]; Navas discloses that event query manager 772 may set up the paths down which the event query and results sets will flow).
Regarding claim 2, Navas discloses the system of claim 1, wherein the preconfigured routing path arranges the plurality of processing modules in series with one another such that a module output from the first processing module provides a module input to a second processing module (paragraphs [0032], [0044]; Navas discloses that each LE node 110, 120, 130, and 140 represents an event broker, and the interconnection/networking of the nodes can be considered an event bus. Each node is an LE node because there are components local to each node that enables the node to participate in the LE network, processing and routing real-time event data as described herein. The event broker can exist on a "platform," such as an enterprise system that is leveraged to exchange query information).
Regarding claim 3, Navas discloses the system of claim 1, wherein receiving at least one data stream at an input module comprises receiving at least one data stream of a first type and converting from the first type to a second type (paragraphs [0030], [0053]; Navas discloses that events include any type of transaction or system operation change, such as an inventory level dropping below a threshold, the occurrence of a threshold number of faults within a system, etc.). ), and wherein each of the plurality of processing modules is compatible with the second type (paragraph [0030]; Navas discloses that each data source 112, 122, 132, 142 generates event data as is conducted and transactions occur. In one embodiment, the event producer enriches situation-specific information (such as an inventory level drop) with metadata. The metadata could be attributes and contextual data related to the specific situation. By enriching such information, an event producer can create an instance of an event that can be independently processed by other entities in the enterprise, through other entities that can process query information as described herein ).
Regarding claim 4, Navas discloses the system of claim 1, wherein upon a condition where the at least one network event data is labeled as a priority event with a priority label corresponding with the feature (paragraphs [0049], [0055 – 0056]; Navas discloses that the event correlation module may inform the CEP of the event stream(s) to which it needs to subscribe and the EN will pass to the CEP the event correlation pattern that it wants to detect. In one embodiment, the EN sleeps or idles while it waits for the CEP to detect the event defined by the event pattern. When the CEP detects the specific event pattern, it will wake up the EN and pass the high-level event data that was detected to the EN (claimed priority event). When the EN is awake, it executes an action procedure associated with the event pattern ), the first processing module transforms the priority event prior to transforming network event data of other data streams (paragraphs [0049], [0055 – 0056]; Navas discloses that the procedure may use a database connection to, for example, a federated database engine to access data from one or multiple distributed sources through a single unified interface and data organization; 2) directly trigger another action, such as by directly connecting to a backend server (e.g., mySAP ERP) to cause an action to take place. The other action may simply change the value of a data item within the server or it may cause a corresponding process to execute; 3) publish one or more new events, such as generating one or more streams of data).
Regarding claim 5, Navas discloses the system of claim 1, wherein the predetermined rule is selected from the group consisting of an insertion rule, a correlating rule, and enriching rule, a transformation rule, a reconciliation rule, and an API rule (paragraphs [0045], [0049], [0056]; Navas discloses that the transformation definitions may be implemented in the form of a lookup table, rules).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Julio Navas (US 2010/0125584; hereinafter Navas) in view of HARRISON et al (US 2013/0254150; hereinafter HARRISON).
Regarding claim 6, Navas discloses the system of claim 1, wherein the corresponding rule data from the rules data database is amendable, and wherein upon a condition where the corresponding rule data is amended, any subsequent implementing of the corresponding rule data by the microservice engine implements the amended corresponding rule data.
HARRISON, in an analogous art, discloses wherein the corresponding rule data from the rules data database is amendable (abstract; paragraphs [0013], [0043]; HARRISON discloses that amending the first rule-set thus giving rise to a second rule-set comprising extra allowed traffic resulting from the amended), and wherein upon a condition where the corresponding rule data is amended, any subsequent implementing of the corresponding rule data by the microservice engine implements the amended corresponding rule data (abstract; paragraphs [0044]; HARRISON discloses that generate amendments to the initial rule-set, and to provide the generated amendments to respective security gateway (and/or security management block) via a security gateway interface 23. Likewise, the generated amendments may be provided to another device involved in policy management or to an administrator.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Navas by showing that the corresponding rule data from the rules data database is amendable, and wherein upon a condition where the corresponding rule data is amended, any subsequent implementing of the corresponding rule data by the microservice engine implements the amended corresponding rule data as evidenced by HARRISON for the purpose of preventing undesired behavior of the enterprise and promote increased performance.
Claims 7 and 14are rejected under 35 U.S.C. 103 as being unpatentable over Julio Navas (US 2010/0125584; hereinafter Navas) in view of Balakrishnan et al (US 10,542,077; hereinafter Balakrishnan).
Regarding claim 7, Navas discloses all the limitations in claim 1, but fails to specifically disclose that wherein upon a condition when transforming the network event data in accordance with the predetermined rule in unsuccessful, the network event data is rerouted through the first processing module a predetermined number of times.
Balakrishnan, in an analogous art, discloses that wherein upon a condition when transforming the network event data in accordance with the predetermined rule in unsuccessful (col. 17, lines 35 - 42; Balakrishnan discloses that controller 2008 may refer to subscriber system repository 2030 and rule repository 2040 to determine the re-routing rules corresponding to the router failure and subscriber customer systems interconnected to the failed router, respectively. For instance, controller 2008 may determine from device failures 2046 registry in rule repository 2040 that the network device report message 2010 is a router failure ), the network event data is rerouted through the first processing module a predetermined number of times (col. 13, line 48 through col. 14, line 10, col. 17, lines 29 - 50; Balakrishnan discloses that in response to receiving a network device report message 2010, controller 2008 of network event unit 124 may refer to rule repository 2040 to determine re-routing rules corresponding to the network event. Rule repository 2040 may include events 2042, device threshold 2044, and device failures 2046 registries).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Navas by showing that upon a condition when transforming the network event data in accordance with the predetermined rule in unsuccessful, the network event data is rerouted through the first processing module a predetermined number of times as evidenced by Balakrishnan for the purpose of reducing the computing resource and network load on both the customer systems and on the interconnection platform; thereby improving customer system responsiveness to network events.
Claims 8 – 12 and 15 – 19 incorporate substantively all the limitations of claims 1 – 7, 13 – 14, and 20. The reasons for rejecting claims 1 – 7, 13 – 14, and 20 apply in claims 8 – 12 and 15 – 19. Therefore, claims 8 – 12 and 15 – 19 are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wilson et al (US 2022/0303188) discloses a managing telecommunication network event data.
Jiang et al (US 2023/0283541) discloses a communication method and system applied to metro transport network MTN or slicing packet network SPN.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YVES DALENCOURT whose telephone number is (571)272-3998. The examiner can normally be reached M-F 8AM-5:30PM.
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, Ario Etienne can be reached at 571-272-4001. 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.
/YVES DALENCOURT/Primary Examiner, Art Unit 2457