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 § 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 –
(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-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by THOMAS (U.S. Publication 2024/0195675).
The applied reference has a common assignee / joint inventor with the instant application. Based upon the earlier effectively filed date of the reference, it constitutes prior art under 35 U.S.C. 102(a)(2). This rejection under 35 U.S.C. 102(a)(2) might be overcome by: (1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C. 102(b)(2)(A); (2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B) if the same invention is not being claimed; or (3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed in the reference and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement.
As to claim 1, THOMAS teaches a method comprising:
receiving, from a consumer application, an event request indicating a requested network event from among a plurality of network events hosted by a network event data streaming platform (par. 0017, “As just mentioned, the event bus system can utilize a network event data streaming platform for distributing network event data to requesting components or third-party systems. For example, the event bus system receives an event request from a network component or a third-party system and provides network event data based on the event request. Along these lines, rather than requiring developer curation of network event data to locate and collect data for a received event request, the event bus system can instead make network event data available in a self-service fashion. More specifically, the event bus system can utilize a network event data streaming platform that readily provides network events to requesting network components/systems from respective event platform sources where they are housed for distribution. Thus, in response to receiving a self-service event request, the event bus system can identify the event platform source for the requested event and can provide the requested event from the identified source. In some cases, the event bus system can further make network events discoverable throughout the network event data streaming platform (e.g., at their respective sources) such that requesting network components/systems can view or otherwise identify network events available for request.; par. 0076-0079, “As further illustrated in FIG. 3, the network event data streaming platform includes an event fanning platform 316. Indeed, as mentioned above, the event bus system 106 utilizes the event fanning platform 316 to generate low-latency fanned data streams to broadcast network events to requesting network components or third-party systems. For example, the event bus system 106 receives a network event request and determines a latency requirement for the request. Based on determining that the latency requirement is below a latency threshold, the event bus system 106 further determines that using the data lake 314 is not a viable option to provide the requested network event at the required speed (or in the required time) indicated by the latency of the request. Accordingly, the event bus system 106 utilizes the event fanning platform 316 to generate a fanned data stream for the requested event for access by the requesting component/system.
[0077] In some embodiments, the event fanning platform 316 fans out network events to consumer application data streams (e.g., low-latency fanned data streams), such as the consumer application data stream 322 on the consumer application server 320. For instance, the event fanning platform 316 includes a processor that reads from a single data stream (e.g., the global event data stream 310) and writes to multiple streams based on a set of declarative configurations dictating what events need to be written to which consumer application data stream (or consumer application server).
[0078] To elaborate, based on receiving a network event request, the event bus system 106 determines or identifies an event fanning configuration (as defined by the request or a previous/initial request) that indicates a configuration for one or more requested network events. Specifically, an event fanning configuration indicates a destination data stream (and its streaming protocol or stream type, such as Kineses or Kafka) along with network events to provide to the destination data stream. In one or more embodiments, the event fanning platform 316 can update an event fanning configuration dynamically based on a new or updated event request, based on permissions associated with a requesting component/system, and/or according to throughput metrics and server capacity…[0079] Based on an event fanning configuration indicating one or more short-retention network events, the event fanning platform 316 generates a corresponding low-latency fanned data stream for the requested short-retention network events. The event fanning platform 316 further provides or broadcasts the low-latency fanned data stream to a requesting component, such as the consumer application server 320 or a third-party data server from among the third-party data servers 326. For instance, the event fanning platform 316 provides or broadcasts the fanned data stream to the consumer application data stream 322 on the consumer application server 320. Indeed, the consumer application server 320 generates and provides the event request including an event fanning configuration, whereupon the event fanning platform 316 fans out the relevant events to the appropriate consumer application data stream 322.”);
determining a request volume within the network event data streaming platform (par. 0095, “[0095] If the event bus system 106 determines that the requested network event cannot be performed in batch mode (e.g., because the latency exceeds a batch mode threshold), the event bus system 106 performs an act 412 to determine a network event volume for the event request. In particular, the event bus system 106 determines (or receives an indication of) a volume or a number of network events (e.g., of the type indicated by the requested event) that the network event data streaming platform has available within the data lake 314 and/or within fanned data streams. Thus, event bus system 106 determines busy and/or available resources for provisioning new events if necessary. In some cases, the event bus system 106 determines a volume or a number of network events requested by the received self-service transaction request as part of the resource determination. Additionally, the event bus system 106 performs an act 414 to orchestrate creation of a Kinesis stream and a corresponding configuration for the stream using the event fanning platform 316 based on the volume(s). Indeed, as mentioned the event bus system 106 determines the event fanning configuration from the request as indicated by a requesting component/system (e.g., the consumer application server 320 or one of the third-party data servers 326).”; 0099, “[0099] In addition, the event data catalog 506 passes the information for the event(s) to a data stream orchestration engine 508 to determine a volume of network events streamed (or made available) by the network event data streaming platform (e.g., via low-latency fanned data streams). In response, the data stream orchestration engine 508 identifies the volume of network events within the network event data streaming platform that match the requested event (e.g., 3000 events per second). The data stream orchestration engine 508 passes the event volume information to the event transformation engine 504 to determine a number of server shards to use/dedicate for the network events of the self-service event request.”;
generating, using an event fanning platform in response to determining the request volume, a consumer application data stream specific to the requested network event and tied to a lifecycle of the consumer application by allocating resources from the network event data streaming platform to the consumer application data stream according to the request volume ( “[0095] If the event bus system 106 determines that the requested network event cannot be performed in batch mode (e.g., because the latency exceeds a batch mode threshold), the event bus system 106 performs an act 412 to determine a network event volume for the event request. In particular, the event bus system 106 determines (or receives an indication of) a volume or a number of network events (e.g., of the type indicated by the requested event) that the network event data streaming platform has available within the data lake 314 and/or within fanned data streams. Thus, event bus system 106 determines busy and/or available resources for provisioning new events if necessary. In some cases, the event bus system 106 determines a volume or a number of network events requested by the received self-service transaction request as part of the resource determination. Additionally, the event bus system 106 performs an act 414 to orchestrate creation of a Kinesis stream and a corresponding configuration for the stream using the event fanning platform 316 based on the volume(s). Indeed, as mentioned the event bus system 106 determines the event fanning configuration from the request as indicated by a requesting component/system (e.g., the consumer application server 320 or one of the third-party data servers 326).”; 0099, “[0099] In addition, the event data catalog 506 passes the information for the event(s) to a data stream orchestration engine 508 to determine a volume of network events streamed (or made available) by the network event data streaming platform (e.g., via low-latency fanned data streams). In response, the data stream orchestration engine 508 identifies the volume of network events within the network event data streaming platform that match the requested event (e.g., 3000 events per second). The data stream orchestration engine 508 passes the event volume information to the event transformation engine 504 to determine a number of server shards to use/dedicate for the network events of the self-service event request.; [0084] The consumer application server 320 thus executes a consumer application using data within the consumer application data stream 322. Consumer applications include applications for tracking device interactions, reporting on network stability/data loss, identifying login attempts, generating financial reports, executing asset transfers, checking account credit, or performing some other transaction. The event bus system 106 maintains the life cycle of the consumer application data stream 322 based on the life cycle of the corresponding consumer application. In response to detecting that the consumer application is deprecated, the event bus system 106 further removes or deprecates the consumer application data stream 322 as well.”);
providing, using the event fanning platform, the requested network event to the consumer application via the consumer application data stream ([0095] If the event bus system 106 determines that the requested network event cannot be performed in batch mode (e.g., because the latency exceeds a batch mode threshold), the event bus system 106 performs an act 412 to determine a network event volume for the event request. In particular, the event bus system 106 determines (or receives an indication of) a volume or a number of network events (e.g., of the type indicated by the requested event) that the network event data streaming platform has available within the data lake 314 and/or within fanned data streams. Thus, event bus system 106 determines busy and/or available resources for provisioning new events if necessary. In some cases, the event bus system 106 determines a volume or a number of network events requested by the received self-service transaction request as part of the resource determination. Additionally, the event bus system 106 performs an act 414 to orchestrate creation of a Kinesis stream and a corresponding configuration for the stream using the event fanning platform 316 based on the volume(s). Indeed, as mentioned the event bus system 106 determines the event fanning configuration from the request as indicated by a requesting component/system (e.g., the consumer application server 320 or one of the third-party data servers 326).”; 0099, “[0099] In addition, the event data catalog 506 passes the information for the event(s) to a data stream orchestration engine 508 to determine a volume of network events streamed (or made available) by the network event data streaming platform (e.g., via low-latency fanned data streams). In response, the data stream orchestration engine 508 identifies the volume of network events within the network event data streaming platform that match the requested event (e.g., 3000 events per second). The data stream orchestration engine 508 passes the event volume information to the event transformation engine 504 to determine a number of server shards to use/dedicate for the network events of the self-service event request.; [0084] The consumer application server 320 thus executes a consumer application using data within the consumer application data stream 322. Consumer applications include applications for tracking device interactions, reporting on network stability/data loss, identifying login attempts, generating financial reports, executing asset transfers, checking account credit, or performing some other transaction. The event bus system 106 maintains the life cycle of the consumer application data stream 322 based on the life cycle of the corresponding consumer application. In response to detecting that the consumer application is deprecated, the event bus system 106 further removes or deprecates the consumer application data stream 322 as well.”); and
in response to detecting a deprecation of the consumer application, deprecating the consumer application data stream within the event fanning platform ([0084] The consumer application server 320 thus executes a consumer application using data within the consumer application data stream 322. Consumer applications include applications for tracking device interactions, reporting on network stability/data loss, identifying login attempts, generating financial reports, executing asset transfers, checking account credit, or performing some other transaction. The event bus system 106 maintains the life cycle of the consumer application data stream 322 based on the life cycle of the corresponding consumer application. In response to detecting that the consumer application is deprecated, the event bus system 106 further removes or deprecates the consumer application data stream 322 as well.”).
As to claim 2, THOMAS teaches receiving the event request indicating the requested network event by:
receiving an application configuration file defining the consumer application; and
detecting, within the application configuration file, a code segment defining the requested network event ([0078] To elaborate, based on receiving a network event request, the event bus system 106 determines or identifies an event fanning configuration (as defined by the request or a previous/initial request) that indicates a configuration for one or more requested network events. Specifically, an event fanning configuration indicates a destination data stream (and its streaming protocol or stream type, such as Kineses or Kafka) along with network events to provide to the destination data stream. In one or more embodiments, the event fanning platform 316 can update an event fanning configuration dynamically based on a new or updated event request, based on permissions associated with a requesting component/system, and/or according to throughput metrics and server capacity. In some cases, an event fanning configuration has the following format:
TABLE-US-00002 [ { stream: “arn:aws:kinesis:us-east-1:802476504392:stream/de-segmentatom-alerts- login-prod”. events: [ { name: “chime.risk.v1.UserEnrollmenEvent”, query: “SELECT * FROM chime.risk.v1.UserEnrollmenEvent WHERE location IS ‘SF’ OR location IS ‘NYC’” } ] };
[0079] Based on an event fanning configuration indicating one or more short-retention network events, the event fanning platform 316 generates a corresponding low-latency fanned data stream for the requested short-retention network events. The event fanning platform 316 further provides or broadcasts the low-latency fanned data stream to a requesting component, such as the consumer application server 320 or a third-party data server from among the third-party data servers 326. For instance, the event fanning platform 316 provides or broadcasts the fanned data stream to the consumer application data stream 322 on the consumer application server 320. Indeed, the consumer application server 320 generates and provides the event request including an event fanning configuration, whereupon the event fanning platform 316 fans out the relevant events to the appropriate consumer application data stream 322.).
As to claim 3, THOMAS teaches generating the consumer application data stream by using the event fanning platform to generate a data stream configuration file defining the consumer application data stream to include the requested network event (par. 0017, “As just mentioned, the event bus system can utilize a network event data streaming platform for distributing network event data to requesting components or third-party systems. For example, the event bus system receives an event request from a network component or a third-party system and provides network event data based on the event request. Along these lines, rather than requiring developer curation of network event data to locate and collect data for a received event request, the event bus system can instead make network event data available in a self-service fashion. More specifically, the event bus system can utilize a network event data streaming platform that readily provides network events to requesting network components/systems from respective event platform sources where they are housed for distribution. Thus, in response to receiving a self-service event request, the event bus system can identify the event platform source for the requested event and can provide the requested event from the identified source. In some cases, the event bus system can further make network events discoverable throughout the network event data streaming platform (e.g., at their respective sources) such that requesting network components/systems can view or otherwise identify network events available for request.; par. 0076-0079, “As further illustrated in FIG. 3, the network event data streaming platform includes an event fanning platform 316. Indeed, as mentioned above, the event bus system 106 utilizes the event fanning platform 316 to generate low-latency fanned data streams to broadcast network events to requesting network components or third-party systems. For example, the event bus system 106 receives a network event request and determines a latency requirement for the request. Based on determining that the latency requirement is below a latency threshold, the event bus system 106 further determines that using the data lake 314 is not a viable option to provide the requested network event at the required speed (or in the required time) indicated by the latency of the request. Accordingly, the event bus system 106 utilizes the event fanning platform 316 to generate a fanned data stream for the requested event for access by the requesting component/system.
[0077] In some embodiments, the event fanning platform 316 fans out network events to consumer application data streams (e.g., low-latency fanned data streams), such as the consumer application data stream 322 on the consumer application server 320. For instance, the event fanning platform 316 includes a processor that reads from a single data stream (e.g., the global event data stream 310) and writes to multiple streams based on a set of declarative configurations dictating what events need to be written to which consumer application data stream (or consumer application server).
[0078] To elaborate, based on receiving a network event request, the event bus system 106 determines or identifies an event fanning configuration (as defined by the request or a previous/initial request) that indicates a configuration for one or more requested network events. Specifically, an event fanning configuration indicates a destination data stream (and its streaming protocol or stream type, such as Kineses or Kafka) along with network events to provide to the destination data stream. In one or more embodiments, the event fanning platform 316 can update an event fanning configuration dynamically based on a new or updated event request, based on permissions associated with a requesting component/system, and/or according to throughput metrics and server capacity…[0079] Based on an event fanning configuration indicating one or more short-retention network events, the event fanning platform 316 generates a corresponding low-latency fanned data stream for the requested short-retention network events. The event fanning platform 316 further provides or broadcasts the low-latency fanned data stream to a requesting component, such as the consumer application server 320 or a third-party data server from among the third-party data servers 326. For instance, the event fanning platform 316 provides or broadcasts the fanned data stream to the consumer application data stream 322 on the consumer application server 320. Indeed, the consumer application server 320 generates and provides the event request including an event fanning configuration, whereupon the event fanning platform 316 fans out the relevant events to the appropriate consumer application data stream 322.”);
.
As to claim 4, THOMAS teaches receiving, from an additional consumer application, an additional event request indicating the requested network event; and
generating, using the event fanning platform, an additional consumer application data stream including the requested network event for the additional consumer application (par. 0017, “As just mentioned, the event bus system can utilize a network event data streaming platform for distributing network event data to requesting components or third-party systems. For example, the event bus system receives an event request from a network component or a third-party system and provides network event data based on the event request. Along these lines, rather than requiring developer curation of network event data to locate and collect data for a received event request, the event bus system can instead make network event data available in a self-service fashion. More specifically, the event bus system can utilize a network event data streaming platform that readily provides network events to requesting network components/systems from respective event platform sources where they are housed for distribution. Thus, in response to receiving a self-service event request, the event bus system can identify the event platform source for the requested event and can provide the requested event from the identified source. In some cases, the event bus system can further make network events discoverable throughout the network event data streaming platform (e.g., at their respective sources) such that requesting network components/systems can view or otherwise identify network events available for request.; par. 0076-0079, “As further illustrated in FIG. 3, the network event data streaming platform includes an event fanning platform 316. Indeed, as mentioned above, the event bus system 106 utilizes the event fanning platform 316 to generate low-latency fanned data streams to broadcast network events to requesting network components or third-party systems. For example, the event bus system 106 receives a network event request and determines a latency requirement for the request. Based on determining that the latency requirement is below a latency threshold, the event bus system 106 further determines that using the data lake 314 is not a viable option to provide the requested network event at the required speed (or in the required time) indicated by the latency of the request. Accordingly, the event bus system 106 utilizes the event fanning platform 316 to generate a fanned data stream for the requested event for access by the requesting component/system.
[0077] In some embodiments, the event fanning platform 316 fans out network events to consumer application data streams (e.g., low-latency fanned data streams), such as the consumer application data stream 322 on the consumer application server 320. For instance, the event fanning platform 316 includes a processor that reads from a single data stream (e.g., the global event data stream 310) and writes to multiple streams based on a set of declarative configurations dictating what events need to be written to which consumer application data stream (or consumer application server).
[0078] To elaborate, based on receiving a network event request, the event bus system 106 determines or identifies an event fanning configuration (as defined by the request or a previous/initial request) that indicates a configuration for one or more requested network events. Specifically, an event fanning configuration indicates a destination data stream (and its streaming protocol or stream type, such as Kineses or Kafka) along with network events to provide to the destination data stream. In one or more embodiments, the event fanning platform 316 can update an event fanning configuration dynamically based on a new or updated event request, based on permissions associated with a requesting component/system, and/or according to throughput metrics and server capacity…[0079] Based on an event fanning configuration indicating one or more short-retention network events, the event fanning platform 316 generates a corresponding low-latency fanned data stream for the requested short-retention network events. The event fanning platform 316 further provides or broadcasts the low-latency fanned data stream to a requesting component, such as the consumer application server 320 or a third-party data server from among the third-party data servers 326. For instance, the event fanning platform 316 provides or broadcasts the fanned data stream to the consumer application data stream 322 on the consumer application server 320. Indeed, the consumer application server 320 generates and provides the event request including an event fanning configuration, whereupon the event fanning platform 316 fans out the relevant events to the appropriate consumer application data stream 322.”);
.
As to claim 5, THOMAS teaches determining a network event environment for deploying the consumer application; and
generating the consumer application data stream specific to the network event environment of the consumer application (par. 0017, “As just mentioned, the event bus system can utilize a network event data streaming platform for distributing network event data to requesting components or third-party systems. For example, the event bus system receives an event request from a network component or a third-party system and provides network event data based on the event request. Along these lines, rather than requiring developer curation of network event data to locate and collect data for a received event request, the event bus system can instead make network event data available in a self-service fashion. More specifically, the event bus system can utilize a network event data streaming platform that readily provides network events to requesting network components/systems from respective event platform sources where they are housed for distribution. Thus, in response to receiving a self-service event request, the event bus system can identify the event platform source for the requested event and can provide the requested event from the identified source. In some cases, the event bus system can further make network events discoverable throughout the network event data streaming platform (e.g., at their respective sources) such that requesting network components/systems can view or otherwise identify network events available for request.; par. 0076-0079, “As further illustrated in FIG. 3, the network event data streaming platform includes an event fanning platform 316. Indeed, as mentioned above, the event bus system 106 utilizes the event fanning platform 316 to generate low-latency fanned data streams to broadcast network events to requesting network components or third-party systems. For example, the event bus system 106 receives a network event request and determines a latency requirement for the request. Based on determining that the latency requirement is below a latency threshold, the event bus system 106 further determines that using the data lake 314 is not a viable option to provide the requested network event at the required speed (or in the required time) indicated by the latency of the request. Accordingly, the event bus system 106 utilizes the event fanning platform 316 to generate a fanned data stream for the requested event for access by the requesting component/system.
[0077] In some embodiments, the event fanning platform 316 fans out network events to consumer application data streams (e.g., low-latency fanned data streams), such as the consumer application data stream 322 on the consumer application server 320. For instance, the event fanning platform 316 includes a processor that reads from a single data stream (e.g., the global event data stream 310) and writes to multiple streams based on a set of declarative configurations dictating what events need to be written to which consumer application data stream (or consumer application server).
[0078] To elaborate, based on receiving a network event request, the event bus system 106 determines or identifies an event fanning configuration (as defined by the request or a previous/initial request) that indicates a configuration for one or more requested network events. Specifically, an event fanning configuration indicates a destination data stream (and its streaming protocol or stream type, such as Kineses or Kafka) along with network events to provide to the destination data stream. In one or more embodiments, the event fanning platform 316 can update an event fanning configuration dynamically based on a new or updated event request, based on permissions associated with a requesting component/system, and/or according to throughput metrics and server capacity…[0079] Based on an event fanning configuration indicating one or more short-retention network events, the event fanning platform 316 generates a corresponding low-latency fanned data stream for the requested short-retention network events. The event fanning platform 316 further provides or broadcasts the low-latency fanned data stream to a requesting component, such as the consumer application server 320 or a third-party data server from among the third-party data servers 326. For instance, the event fanning platform 316 provides or broadcasts the fanned data stream to the consumer application data stream 322 on the consumer application server 320. Indeed, the consumer application server 320 generates and provides the event request including an event fanning configuration, whereupon the event fanning platform 316 fans out the relevant events to the appropriate consumer application data stream 322.”).
As to claim 6, THOMAS teaches detecting a deprecation of the consumer application by detecting a user interaction deleting the consumer application from the network event data streaming platform; and
deprecating the consumer application data stream by automatically unbinding server resources allocated to the consumer application data stream in response to detecting the deprecation of the consumer application ([0084] The consumer application server 320 thus executes a consumer application using data within the consumer application data stream 322. Consumer applications include applications for tracking device interactions, reporting on network stability/data loss, identifying login attempts, generating financial reports, executing asset transfers, checking account credit, or performing some other transaction. The event bus system 106 maintains the life cycle of the consumer application data stream 322 based on the life cycle of the corresponding consumer application. In response to detecting that the consumer application is deprecated, the event bus system 106 further removes or deprecates the consumer application data stream 322 as well.”).
As to claim 7, THOMAS teaches detecting a modification to the event request indicating an additional requested network event from among the plurality of network events hosted by the network event data streaming platform; and
based on the modification to the event request, generating an updated consumer application data stream using the event fanning platform indicating the requested network event and the additional requested network event ([0116] Additionally, the series of acts 600 can include an act of generating a consumer application data stream for the self-service event request by: in response to receiving the self-service event request, generating an event fanning configuration indicating one or more short-retention network events to provide to a consumer application server associated with the consumer application data stream and generating a low-latency fanned data stream broadcasting the one or more short-retention network events to the consumer application server according to the event fanning configuration. The series of acts 600 can also include an act of generating the plurality of network events for the global data stream by: receiving network events indicating modifications to network data associated with an inter-network facilitation system from one or more event logging servers and generating schematized versions of the network events from the one or more event logging servers. The series of acts 600 can also include an act of broadcasting the schematized versions of the network events via the global data stream.).
As to claims 8-14, reference is made to a system that corresponds to the method of claims 1-7 and is therefore met by the rejection of claims 1-7 above.
As to claims 15-20, reference is made to a computer program product that corresponds to the method of claims 1-6 and is therefore met by the rejection of claims 1-6 above.
Claim(s) 1-5, 7-12 and 14-19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by KOLODZIESKI (2018/0165139).
As to claim 1, KOLODZIESKI teaches a method comprising:
receiving, from a consumer application (event subscriber), an event request indicating a requested network event from among a plurality of network events hosted by a network event data streaming platform ([0070] Pub/sub is a message-oriented interaction paradigm based on indirect addressing. Subscribers (e.g., cluster manager device 104, ESP cluster device 1000, event subscribing device 500) specify their interest in receiving information from ESPE 400 by subscribing to specific classes of events, while information sources (event publishing device 200, cluster manager device 104, ESP cluster device 1000) publish events to ESPE 400 without directly addressing the data recipients. Stream processing system 100 includes ESPE manager 400m that receives events from event publishing application 222 executing on event publishing device 200 of event publishing system 102 and that publishes processed events to ESPE A 400a of ESP cluster device 1000 of ESP cluster system 106. ESPE A 400a of ESP cluster device 1000 of ESP cluster system 106 receives events from ESPE manager 400m and publishes further processed events to event subscribing application 522 of event subscribing device 500 of event subscribing system 108.
[0071] In an operation 306, a connection is made between event publishing application 222 and ESPE 400, such as ESPE manager 400m executing on cluster manager device 104, for each source window of the source windows 406 to which any measurement data value is published. To make the connection, the pointer to the created publishing client may be passed to a “Connect” function. If event publishing application 222 is publishing to more than one source window of ESPE 400, a connection may be made to each started window using the pointer returned for the respective “Start” function call.);
determining a request volume within the network event data streaming platform ([0073] In an operation 310, the created event block object is published to ESPE 400, for example, using the pointer returned for the respective “Start” function call to the appropriate source window. Event publishing application 222 passes the created event block object to the created publishing client, where the unique ID field in the event block object has been set by event publishing application 222 possibly after being requested from the created publishing client. In an illustrative embodiment, event publishing application 222 may wait to begin publishing until a “Ready” callback has been received from the created publishing client. The event block object is injected into the source window, continuous query, and project associated with the started publishing client.
[0074] In an operation 312, a determination is made concerning whether or not processing is stopped. If processing is not stopped, processing continues in operation 308 to continue creating and publishing event block objects that include measurement data values. If processing is stopped, processing continues in an operation 314.
[0075] In operation 314, the connection made between event publishing application 222 and ESPE 400 through the created publishing client is disconnected, and each started publishing client is stopped…
[0080] In an operation 602, subscription services are initialized.
[0081] In an operation 604, the initialized subscription services are started, which may create a subscribing client on behalf of event subscribing application 512 at event subscribing device 500. The subscribing client performs the various pub/sub activities for event subscribing application 512. For example, a URL to ESPE 400, such as ESPE A 400a of ESP cluster device 1000 of ESP cluster system 106, may be passed to a “Start” function. The “Start” function may validate and retain the connection parameters for a specific subscribing client connection and return a pointer to the subscribing client. For illustration, the URL may be formatted as “dfESP://<host>:<port>/<project name>/<continuous query name>/<window name>”.
[0082] In an operation 606, a connection may be made between event subscribing application 512 executing on event subscribing device 500 and ESPE A 400a through the created subscribing client. To make the connection, the pointer to the created subscribing client may be passed to a “Connect” function and a mostly non-busy wait loop created to wait for receipt of event block objects. For example, the connection may be made to one or more computing devices of ESP cluster system 106.
[0083] In an operation 608, an event block object is received by event subscribing application 512 executing on event subscribing device 500.
[0084] In an operation 610, the received event block object is processed based on the operational functionality provided by event subscribing application 512. For example, event subscribing application 512 may extract data from the received event block object and store the extracted data in a database. In addition, or in the alternative, event subscribing application 512 may extract data from the received event block object and send the extracted data to a system control operator display system, an automatic control system, a notification device, an analytic device, etc. In addition, or in the alternative, event subscribing application 512 may extract data from the received event block object and send the extracted data to a post-incident analysis device to further analyze the data. Event subscribing application 512 may perform any number of different types of actions as a result of extracting data from the received event block object. The action may involve presenting information on a second display 516 or a second printer 520, presenting information using a second speaker 518, storing data in second computer-readable medium 522, sending information to another device using second communication interface 506, etc. A user may further interact with presented information using a second mouse 514 and/or a second keyboard 512.
[0085] In an operation 612, a determination is made concerning whether or not processing is stopped. If processing is not stopped, processing continues in operation 608 to continue receiving and processing event block objects. If processing is stopped, processing continues in an operation 614.
[0133] Manager application 712 may provide the REST API layer for a user to query for information described in manager configuration file 714, remote ESP model 716, manager ESP model 718, and router configuration file 720 and to query a status of ESPE manager 400m and/or of ESPE A 400a. For example, using the REST API, the user can create, delete, modify, and/or retrieve information related to the one or more projects 402, the one or more continuous queries 404, the one or more source windows 406, and/or the one or more derived windows 408 of ESPE manager 400m and/or of ESPE A 400a. The user can further start and stop a project of the one or more projects 402. The user still further may inject events into and retrieve events from ESPE manager 400m and/or of ESPE A 400a.
[0134] Manager application 712 provides a mapping of sources from edge devices (event publishing system 102) to ESPE A 400a of ESP cluster system 106 that may include cloud devices. By managing a mapping between connectors and ESPE A 400a, manager application 712 facilitates an elastic deployment of ESP in the cloud and makes large scale deployment easier. For example, manager application 712 supports deployment of SAS® Event Stream Processing as a service to a cloud platform that creates and manages hardware resources in the cloud.
[0135] ESPE A 400a may be provisioned on virtual machines of ESP cluster system 106. ESPE A 400a may each run remote engine 722a with their administrative and pub/sub ports open (also referred to as factory servers), for example, using a command such as “$DFESP_HOME/bin/dfesp_xml_server-pubsub 5575-http-pubsub 5577-http-admin 5576”. ESPE A 400a can receive and respond to HTTP requests from ESPE manager 400m using the port number port specified for the “-http-admin” input parameter. A port for pub/sub commands to an HTTP server executing on ESP cluster system 106 is defined using the port number port specified for the “-http-pubsub” input parameter. In alternative embodiments, the port for admin commands and the port for pub/sub commands may use the same port. The “-http-admin” input parameter and the “-http-pubsub” input parameter are associated with HTTP server elements <http-servers>. A port for pub/sub commands to ESPE A 400a is defined using the port number port specified for the “-pubsub” input parameter. In alternative embodiments, the command line parameters may be defined by default, input by a user through a user interface, etc.
[0136] After provisioning ESPE A 400a as factory servers, manager application 712 can be controlled to: [0137] deploy projects to ESPE A 400a through an administrative REST API to the HTTP server; [0138] start one or more data sources of event publishing system 102 in an orchestrated fashion; [0139] stream events for processing and analyzing through the pub/sub API of ESPE manager 400m; and [0140] dynamically add or remove ESPE A 400a of ESP cluster system 106.
[0141] Referring to FIG. 8, example operations associated with manager application 712 are described. Manager application 712 defines how incoming event streams from event publishing system 102 are transformed into meaningful outgoing event streams consumed by ESP cluster system 106 and ultimately event subscribing system 108. Additional, fewer, or different operations may be performed depending on the embodiment. The order of presentation of the operations of FIG. 8 is not intended to be limiting
[0165] The “esp-maps” element of the “esp-cluster-manager” element defines how event publishing sources defined by the <raw-sources> element, such as event publishing device 200 of event publishing system 102, are mapped to the one or more source windows 406 of a project of the one or more projects 402 of ESPE A 400a. The “esp-maps” element may be defined in manager configuration file 714 based on:
TABLE-US-00026 element esp-maps { element esp-map { attribute name { name_t }, attribute cluster-ref { name_t }, attribute model-ref { name_t }, element map { ... }+ element orchestration { ... }? }+ }
[0166] The “name” attribute specifies a name of the ESP cluster map. The “cluster-ref” attribute specifies a name of the ESP cluster that matches a “name” attribute field specified for an “esp-cluster” element. The “model-ref” attribute specifies a name of the ESP project that matches a “name” attribute field specified for a “project” element. The “map” element maps the source to the ESPE source window of ESPE A 400a. The “orchestration” element defines an order for starting connectors between data sources and ESPE manager 400m.
[0167] The “map” element of the “esp-map” element may be defined in manager configuration file 714 based on:
TABLE-US-00027 element map { attribute name { name_t }, element from { attribute source { name_t } }, element multicast-destination { ... }*, element roundrobin-destination { ... }*, element hash-destination { ... }*, }+
[0168] The “name” attribute specifies a name of the map. The “from” element specifies a name of the data source that matches a “name” attribute field specified for a “raw-source” element. One of “multicast-destination”, “roundrobin-destination”, or “hash-destination” is used to define how a specific ESPE A 400a of ESP cluster system 106 is selected as a recipient of an event block object from the data source. Selection of “multicast-destination” indicates that the event is sent to each ESPE A 400a. For illustration, the “multicast-destination” element of the “map” element may be defined based on:
TABLE-US-00028 element multicast-destination { attribute name { name_t }, attribute opcode { ‘insert’ | ‘upsert’ | ‘update’ | ‘delete’ }?, element publish-target { element project-func { xsd:string [code] }, element contquery-func { xsd:string [code] }, element window-func { xsd:string [code] } } }
[0175] The “orchestration” element of the “esp-map” element defines an order in which connectors between event publishing sources defined by the <raw-sources> element and ESPE manager 400m are started. To stream data into ESPE manager 400m, a connector is used. Connectors use the pub/sub API to interface with a variety of communication fabrics, drivers, and clients. Connectors are C++ classes that are instantiated in the same process space as ESPE manager 400m. By default, connectors may be started automatically when a project of the one or more projects 402 of ESPE manager 400m is started so that the connectors and project run concurrently.).
[0228] In an operation 1114, a connection request is received from ESPE manager 400m executing on cluster manager device 104 for a source window to which data will be published. A connection request further is received from a computing device of event subscribing system 108, for example, from event subscribing device 500.
[0229] In an operation 1116, an event block object is received from ESPE manager 400m. An event block object containing one or more event objects is injected into a source window of the one or more source windows 406 defined from remote ESP model A 716a.
[0230] In an operation 1118, the received event block object is processed through the one or more continuous queries 404. For example, illustrative processing details are described referring to FIG. 9. The unique ID assigned to the event block object by event publishing device 200 is maintained as the event block object is passed through ESPE manager 400m and between the one or more source windows 406 and/or the one or more derived windows 408 of ESPE A 400a. A unique embedded transaction ID further may be embedded in the event block object as the event block object is processed by a continuous query. ESPE A 400a maintains the event block containership aspect of the received event blocks from when the event block is published into a source window and works its way through the directed graph defined by the one or more continuous queries 404 with the various event translations before being output to event subscribing system 108.
[0231] In an operation 1120, the processed event block object is output to one or more subscribing devices of event subscribing system 108 such as event subscribing device 500. Subscribing devices can correlate a group of subscribed event block objects back to a group of published event block objects by comparing the unique ID of the event block object that a publisher, such as event publishing device 200, attached to the event block object with the event block ID received by a subscribed, such as event subscribing device 500. The received event block objects further may be stored, for example, in a RAM or cache type memory of fourth computer-readable medium 1008.);
generating, using an event fanning platform in response to determining the request volume, a consumer application data stream (ESPE) specific to the requested network event and tied to a lifecycle of the consumer application (event subscriber) by allocating resources from the network event data streaming platform to the consumer application data stream according to the request volume ([0073-0075, 0080-0085, 0133-0136, 0141, 0165-0168, 0175, 0228-0231);
providing, using the event fanning platform, the requested network event to the consumer application (event subscriber) via the consumer application data stream (ESPE) ([0073-0075, 0080-0085, 0133-0136, 0141, 0165-0168, 0175, 0228-0231); and
in response to detecting a deprecation of the consumer application, deprecating the consumer application data stream within the event fanning platform ([0073-0075, 0080-0085, 0133-0136, 0141, 0165-0168, 0175, 0228-0231; [0232] In an operation 1122, a determination is made concerning whether or not processing is stopped. If processing is not stopped, processing continues in operation 1116 to continue receiving the one or more event streams containing event block objects from ESPE manager 400m. If processing is stopped, processing continues in an operation 1124.
[0233] In operation 1124, the started projects are stopped.
[0234] In operation 1126, ESPE A 400a is shutdown.).
As to claim 2, KOLODZIESKI teaches receiving the event request indicating the requested network event by:
receiving an application configuration file defining the consumer application; and
detecting, within the application configuration file, a code segment defining the requested network event ([0187] Referring to FIG. 9, a graphical representation of the XML model captured in the sample remote ESP model 716 is shown. The graphical model indicates that the one or more source windows 406 include a source window (SW) 1 900a for illustration named “restrictedInput”, a SW 2 900b for illustration named “venuesInput”, a SW 3 900c for illustration named “brokersInput”, and a SW 4 900d for illustration named “tradesInput”. SW 2 900b provides input to a derived window (DW) 1 902a for illustration named “venueData”. SW 3 900c provides input to a DW 2 902b for illustration named “rate”. SW 4 900d provides input to DW 2 902b, to DW 3 902c for illustration named “counter”, and to DW 4 902d for illustration named “largeTrades”. DW 2 902b, DW 3 902c, and DW 4 902d provide input to a DW 5 902e for illustration named “addBrokerData”. DW 1 902a and DW 5 902e provide input to a DW 6 902f for illustration named “addVenueData”. SW 1 900a and DW 6 902f provide input to a DW 7 902g for illustration named “addRestrictedData”. DW 7 902g provides input to a DW 8 902h for illustration named “transform”. DW 8 902h provides input to a DW 9 902i for illustration named “frontRunningSell”, to a DW 10 902j for illustration named “frontRunningBuy”, to a DW 11 902k for illustration named “closeMarking”, to a DW 12 902l for illustration named “openMarking”, and to a DW 13 902m for illustration named “restrictedTrade”. DW 9 902i, DW 10 902j, DW 11 902k, DW 12 902l, and DW 13 902m provide input to a DW 14 902n for illustration named “violations” and to a DW 15 902o for illustration named “brokerAlerts”. DW 14 902n provides input to a DW 16 902p for illustration named “violationCounts”. DW 15 902o provides input to a DW 17 902q for illustration named “brokerAlertsAggr”.
[0188] For illustration, the remote ESP model 716 is designed to search for the following violations: [0189] A front running buy where a broker buys a stock for himself, then buys the same stock for a client, then sells the stock for a profit. [0190] A front running sell where a broker sells a stock for himself, then sells the same stock for a client. [0191] A restricted trade where a trade was made of a stock that was restricted at a certain venue. [0192] An open marking where a trade was made within 60 seconds of venue open and the quantity is more than 30,000. [0193] A close marking where a trade was made within 60 seconds of venue close and the quantity is more than 70,000.
[0194] Several dimensional windows are used to join the trade data injected into SW 4 900d with broker information injected into SW 3 900c, with trading venue information injected into SW 2 900b, and with information on what stocks are not allowed to be traded from what venues that is injected into SW 1 900a. The violation counts and broker alerts are output to event subscribing device 500 of event subscribing system 108 based on the subscription selected by event subscribing application 522.
[0195] Referring again to FIG. 8, in an operation 808, manager ESP model 718 consisting of source windows and input publishing connectors corresponding to the defined raw sources is created from manager configuration file 714. Typically, manager ESP model 718 includes one project that has one or more source windows that are constructed as follows. The schema of the window is inferred from remote ESP model 716. The source window also includes connectors that are constructed based on raw sources defined in ESP model 718. The raw sources' orchestration information provided in ESP model 718 is used to construct the project-connectors section in the created model.
[0196] Manager ESP model 718 includes a definition of an ESP model to execute at cluster manager device 104 using ESPE manager 400m. For illustration, a sample manager ESP model 718 created based on the sample manager configuration file 714 and the sample remote ESP model 716 above may recite:
TABLE-US-00034 <engine> <project name=‘esp_map10’ pubsub=‘auto’ threads=‘10’> <contqueries> <contquery name=‘query’> <windows> <window-source name=‘tradesInput’> <schema-string>id*:int64,symbol:string,currency:int32,time:int64, msecs:int32,price:double,quant:int32,venue:int32,broker:int32, buyer:int32,seller:int32,buysellflg:int32 </schema-string> <connectors> <connector class=‘fs’ name=‘connector’> <properties> <property name=‘type’>pub</property> <property name=‘fstype’>csv</property> <property name=‘fsname’> trades.csv</property> </properties> </connector> </connectors> </window-source> <window-source insert-only=‘true’ name=‘brokersInput’> <schema> <fields> <field name=‘broker’ type=‘int32’ key=‘true’/> <field name=‘brokerName’ type=‘string’/> <field name=‘brokerage’ type=‘string’/> <field name=‘brokerAddress’ type=‘string’/> <field name=‘brokerEmail’ type=‘string’/> <field name=‘brokerPhone’ type=‘string’/> <field name=‘brokerSms’ type=‘string’/> <field name=‘brokerMms’ type=‘string’/> </fields> </schema> <connectors> <connector class=‘fs’ name=‘connector’> <properties> <property name=‘type’>pub</property> <property name=‘fstype’>csv</property> <property name=‘fsname’> brokers.csv</property> </properties> </connector> </connectors> </window-source> <window-source insert-only=‘true’ name=‘venuesInput’> <schema-string> venue*:int32,openTimeGMT:string, closeTimeGMT:string</schema-string> <connectors> <connector class=‘fs’ name=‘connector’> <properties> <property name=‘type’>pub</property> <property name=‘fstype’>csv</property> <property name=‘fsname’> venues.csv</property> </properties> </connector> </connectors> </window-source> <window-source insert-only=‘true’ name=‘restrictedInput’> <schema-string>symbol*:string,venue*:int32, restricted:int32</schema-string> <connectors> <connector class=‘fs’ name=‘connector’> <properties> <property name=‘type’>pub</property> <property name=‘fstype’>csv</property> <property name=‘fsname’> restricted.csv</property> </properties> </connector> </connectors> </window-source> </windows> </contquery> </contqueries> <project-connectors> <connector-groups> <connector-group name=‘G1’> <connector-entry connector=‘query/brokersInput/connector’ state=‘finished’/> <connector-entry connector=‘query/venuesInput/connector’ state=‘finished’/> <connector-entry connector=‘query/restrictedInput/connector’ state=‘finished’/> </connector-group> <connector-group name=‘G2’> <connector-entry connector=‘query/tradesInput/connector’ state=‘finished’/> </connector-group> </connector-groups> <edges> <edge source=‘G1’ target=‘G2’/> </edges> </project-connectors> </project> </engine>
[0197] In the illustrative embodiment, “esp-map10” is internally used as the project name in the generated model. It comes from the esp-map name defined in manager ESP model 718, i.e., each esp-map in manager ESP model 718 corresponds to a project in the generated model. The “schema-string” attribute is defined from the “window-source” “schema” fields attribute defined in remote ESP model 716 for the source window. For example, the string “id*:int64,symbol:string,currency:int32,time:int64,msecs:int32, price:double,quant:int32,venue:int32,broker:int32,buyer:int32,seller:int32, buysellflg:int32 defined for the “schema-string” defined for the “schema-string” attribute of the source window named “tradesInput” in manager ESP model 718 is defined from the “fields” “field” attributes of the “schema” for the source window named “tradesInput” read from remote ESP model 716. The full set of inputs read from remote ESP model 716 and summarized above is shown below for illustration:
TABLE-US-00035 <window-source name=‘tradesInput’ insert-only=‘true’ index=‘pi_EMPTY’> <schema> <fields> <field name=‘id’ type=‘int64’ key=‘true’/> <field name=‘symbol’ type=‘string’/> <field name=‘currency’ type=‘int32’/> <field name=‘time’ type=‘int64’/> <field name=‘msecs’ type=‘int32’/> <field name=‘price’ type=‘double’/> <field name=‘quant’ type=‘int32’/> <field name=‘venue’ type=‘int32’/> <field name=‘broker’ type=‘int32’/> <field name=‘buyer’ type=‘int32’/> <field name=‘seller’ type=‘int32’/> <field name=‘buysellflg’ type=‘int32’/> <field name=‘tradetime’ type=‘stamp’/> </fields> </schema> </window-source>
[0198] In an operation 810, ESPE manager 400m is instantiated at cluster manager device 104 by executing manager ESP model 718 by manager engine 722.
[0199] In an operation 812, the engine container is created. For illustration, ESPE manager 400m may be instantiated using a function call that specifies the engine container as a manager for the model. The function call may include the engine name for ESPE manager 400m that may be unique to ESPE manager 400m.
[0200] In an operation 814, the one or more projects 402 defined by manager ESP model 718 are instantiated by ESPE manager 400m as a model. Instantiating the one or more projects 402 also instantiates the one or more continuous queries 404, the one or more source windows 406, and the one or more derived windows 408 defined from manager ESP model 718. The one or more continuous queries 404 may be instantiated with a dedicated thread pool or pools that generate updates as new event block objects stream through ESPE manager 400m.
[0201] In an operation 816, the pub/sub capability is initialized for ESPE manager 400m. In an illustrative embodiment, the pub/sub capability is initialized for each project of the one or more projects 402 defined by manager ESP model 718. To initialize and enable pub/sub capability for ESPE manager 400m, a host name and a port number are provided. The port number may be provided from the command line “pubsub” parameter “port” value.
[0202] In an operation 818, the one or more projects 402 defined in manager ESP model 718 are started. The one or more started projects may run in the background on cluster manager device 104. An illustrative command may be “dfesp_xml_client-url ‘http://localhost:46001/SASESP/projects/project/state?value=running’-put”.
[0203] In an operation 820, router configuration file 720 is created and a routing table is configured with policies read from manager configuration file 714. When router engine 724 receives an event, it checks the routing table, an internal data structure, to decide where to send it of the remote ESPE A 400a. The routing table either statically defines the mapping from a source to a destination or dynamically defines a policy that can be used to decide the destination of an event. For example, a hash policy may be defined so that events are hashed, and the hash values are used to decide the destination.
[0204] An ESP router is a mechanism whereby ESP engines can be integrated as described above. For example, ESPE manager 400m can be integrated with ESPE A 400a by defining an ESP router. For illustration, a sample router configuration file 720 created based on values extracted from the sample manager configuration file 714 and the sample remote ESP model 716 above using the illustrative XML file schema for an ESP router configuration may recite:
TABLE-US-00036 <engine> <esp-routers> <esp-router name=‘esp_map10’> <esp-engines> <esp-engine name=‘esp1’ host=‘localhost’ port=‘41003’ ha_port=‘41001’/> <esp-engine name=‘esp2’ host=‘localhost’ port=‘41006’ ha_port=‘41004’/> <esp-engine name=‘esp3’ host=‘localhost’ port=‘41009’ ha_port=‘41007’/> <esp-engine name=‘esp_local’ host=127.0.0.1’ port=‘22346’/> </esp-engines> <esp-destinations> <multicast-destination name=‘brokersMap_dest5′ opcode=‘insert’> <publish-target> <project-func>project</project-func> <contquery-func>query</contquery-func> <window-func>brokersInput</window-func> <engine-func>esp1,esp2,esp3,</engine-func> </publish-target> </multicast-destination> <multicast-destination name=‘venuesMap_dest2’ opcode=‘insert’> <publish-target> <project-func>project</project-func> <contquery-func>query</contquery-func> <window-func>venuesInput</window-func> <engine-func>esp1,esp2,esp3,</engine-func> </publish-target> </multicast-destination> <multicast-destination name=‘restrictedMap_dest3’ opcode=‘insert’> <publish-target> <project-func>project</project-func> <contquery-func>query</contquery-func> <window-func>restrictedInput</window-func> <engine-func>esp1,esp2,esp3,</engine-func> </publish-target> </multicast-destination> <multicast-destination name=‘tradesMap_dest4’ opcode=‘insert’> <publish-target> <project-func>project</project-func> <contquery-func>query</contquery-func> <window-func>tradesInput</window-func> <engine-func>esp1,esp2,esp3,</engine-func> </publish-target> </multicast-destination> </esp-destinations> <esp-routes> <esp-route name=‘brokersMap’ to=‘brokersMap_dest5’> <engine-expr>esp_local</engine-expr> <project-expr>esp_map10</project-expr> <query-expr>query</query-expr> <window-expr>brokersSource</window-expr> </esp-route> <esp-route name=‘venuesMap’ to=‘venuesMap_dest2’> <engine-expr>esp_local</engine-expr> <project-expr>esp_map10</project-expr> <query-expr>query</query-expr> <window-expr>venuesSource</window-expr> </esp-route> <esp-route name=‘restrictedMap’ to=‘restrictedMap_dest3’> <engine-expr>esp_local</engine-expr> <project-expr>esp_map10</project-expr> <query-expr>query</query-expr> <window-expr>restrictedSource</window-expr> </esp-route> <esp-route name=‘tradesMap’ to=‘tradesMap_dest4’> <engine-expr>esp_local</engine-expr> <project-expr>esp_map10</project-expr> <query-expr>query</query-expr> <window-expr>trades</window-expr> </esp-route> </esp-routes> </esp-router> </esp-routers> </engine>
[0205] “Esp_local” specifies ESPE manager 400m. “Esp_local” is automatically generated using hostname ‘127.0.0.1’, which is equivalent to localhost, and the pubsub port specified on the command line using the -pubsub parameter. Router engine 724 subscribes from esp_local and publishes to esp1, esp2 and esp3 based on the esp-route defined.
[0206] In an operation 822, router engine 724 is instantiated. For example, router engine 724 can be instantiated by executing a PUT request such as $DFESP_HOME/bin/dfesp_xml_client-url “http://host:port/SASESP/routerEngines/router3/esp4”-put file://pRouter3engine.xml, where “pRouter3engine.xml” is a reference to the created router configuration file 720. The XML defined in “file://pRouter3engine.xml” is read from the HTTP request, used to instantiate router engine 724 by manager engine 722. Using the ESP pub/sub API, router engine 724 streams events to ESPE A 400a for processing.
[0207] In an operation 826, the one or more connectors defined in manager ESP model 718 are started, for example, by calling an associated “start” function. The started publisher connectors read event data from the specified source and inject that event data into a specific source window of ESPE manager 400m.
[0238] Stream processing system 100 provides a dynamic process by which data can be streamed from event publishers to event subscribers using manager configuration file 714 and remote ESP model 716. After starting remote ESPE A 400a at each ESP cluster device 1000 using remote ESP model A 716a created from remote ESP model 716, manager application 712 can be controlled to: [0239] deploy projects to ESPE A 400a through an administrative REST API to the HTTP server; [0240] start one or more data sources of event publishing system 102 in an orchestrated fashion; [0241] stream events for processing and analyzing through the pub/sub API of ESPE manager 400m; and [0242] dynamically add or remove ESPE A 400a of ESP cluster system 106 using manager configuration file 714.).
As to claim 3, KOLODZIESKI teaches generating the consumer application data stream by using the event fanning platform to generate a data stream configuration file defining the consumer application data stream to include the requested network event ([0181 – 0207, 0238).
As to claim 4, KOLODZIESKI teaches a plurality of event subscribers and thereby inherently receiving, from an additional consumer application (event subscribers), an additional event request indicating the requested network event; and
generating, using the event fanning platform, an additional consumer application data stream including the requested network event for the additional consumer application ([0073-0075, 0080-0085, 0133-0136, 0141, 0165-0168, 0175, 0228-0231).
As to claim 5, KOLODZIESKI teaches determining a network event environment for deploying the consumer application; and
generating the consumer application data stream specific to the network event environment of the consumer application ([0172] Selection of “hash-destination” indicates that the event is streamed to one remote ESPE A 400a, where the remote ESPE A 400a is selected based on a hash value computed from a specified field in the event block object. The hash value is an integer between zero and the number of ESPE A 400a minus one. For example, the field value of the specified field may be converted to an integer, divided by the number of remote ESPE A 400a, and a remainder of the division used as the hash value. The hash value computed from a value of the specified field of the event block object is used to determine to which ESPE A 400a the event block object is sent. Various hash functions may be used. For example, the hash function may be a plug-in to facilitate easy replacement of the hash function used with the specified hash value. For illustration, the “hash-destination” element of the “map” element may be defined based on:
TABLE-US-00030 element hash-destination { attribute name { name_t }, attribute durable { xsd:boolean }?, attribute opcode { ‘insert’ | ‘upsert’ | ‘update’ | ‘delete’ }?, element publish-target { element project-func { xsd:string [code]}, element contquery-func { xsd:string [code]}, element window-func { xsd:string [code]} }, element fields { element field { attribute name { name_t } }+ }? }
[0173] The “name” attribute specifies a name of the hash destination. The “durable” attribute specifies whether or not the hash is durable. When the “durable” attribute indicates the hash is durable, the streamed event block object can be split when a new remote ESPE A 400a of the spare remote ESPE A 400a is added. When a spare remote ESPE A 400a is added, it will be the recipient of a subspace of the hash values that is previously owned by another remote ESPE A 400a. In other words, another remote ESPE A 400a that is previously the recipient of a set of hash values delegates a subset of the set of hash values to the new remote ESPE A 400a as the new recipient. Other remote ESPE A 400a are not affected by the addition of the new remote ESPE A 400a.
[0238] Stream processing system 100 provides a dynamic process by which data can be streamed from event publishers to event subscribers using manager configuration file 714 and remote ESP model 716. After starting remote ESPE A 400a at each ESP cluster device 1000 using remote ESP model A 716a created from remote ESP model 716, manager application 712 can be controlled to: [0239] deploy projects to ESPE A 400a through an administrative REST API to the HTTP server; [0240] start one or more data sources of event publishing system 102 in an orchestrated fashion; [0241] stream events for processing and analyzing through the pub/sub API of ESPE manager 400m; and [0242] dynamically add or remove ESPE A 400a of ESP cluster system 106 using manager configuration file 714.).
As to claim 7, KOLODZIESKI teaches a plurality of event subscribers subscribing for event objects and thereby, inherently, detecting a modification to the event request indicating an additional requested network event from among the plurality of network events hosted by the network event data streaming platform; and
based on the modification to the event request, generating an updated consumer application data stream using the event fanning platform indicating the requested network event and the additional requested network event ([0073-0075, 0080-0085, 0133-0136, 0141, 0165-0168, 0175, 0228-0231).
As to claims 8-12 and 14, reference is made to a system that corresponds to the method of claims 1-5 and 7 and is therefore met by the rejection of claims 1-5 and 7 above.
As to claims 15-19, reference is made to a computer program product that corresponds to the method of claims 1-5 and is therefore met by the rejection of claims 1-5 above.
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.
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.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over KOLODZIESKI (Publication 2018/0165139).
As to claim 6, KOLODZIESKI teaches detecting a deprecation of the consumer application; and
deprecating the consumer application data stream by automatically unbinding server resources allocated to the consumer application data stream in response to detecting the deprecation of the consumer application ([0232] In an operation 1122, a determination is made concerning whether or not processing is stopped. If processing is not stopped, processing continues in operation 1116 to continue receiving the one or more event streams containing event block objects from ESPE manager 400m. If processing is stopped, processing continues in an operation 1124.
[0233] In operation 1124, the started projects are stopped.
[0234] In operation 1126, ESPE A 400a is shutdown.).
However, KOLODZIESKI does not teach that the deprecation includes deleting the consumer application. Official Notice is taken in that terminating a consumer application for removing event registration is well known and that it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention that applying this concept to KOLODZIESKI would remove the ESPE processing when the well-known concept is applied as it would constitute a not processing operation.
As to claim 13, reference is made to a system that corresponds to the method of claim 6 and is therefore met by the rejection of claim 6 above.
As to claim 20, reference is made to a computer program product that corresponds to the method of claim 6 and is therefore met by the rejection of claim 6 above.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LEWIS ALEXANDER BULLOCK JR whose telephone number is (571)272-3759. The examiner can normally be reached Monday-Friday, 9:00-5:00 pm.
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, Cordelia Zecher can be reached at 571-272-7771. 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.
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights