Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The 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.
Claim(s) 1-8, 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over KUNZ (US PUBLICATION 20240184652) in view of VO (US PUBLICATION 20240152414).
As to claim 1, KUNZ teaches a system for generating notifications with customized event architectures, the system comprising:
a processor; a communications module coupled to the processor; and a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the processor to:
provide one or more applications, each application for processing a respective workflow with one or more services;
provide, for each service associated with the one or more applications, a database;
configure each of the one or more services to write events to respective databases, each database having a dedicated outbox table of events for that service;
with an event platform: configure a connector for consuming events to process events in the dedicated outbox tables;
determine one or more subscription topics associated with the processed events;
based on the one or more determined subscription topics, generate and transmit one or more notifications; and
post transmission of the one or more notifications to another topic, the other topic being associated with the determined one or more topics. [0047]-[0048] “at least one hardware processor; and [0048] a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations”
[0003] “Some microservices receive requests or commands from a user (such as via a user interface), and in response perform some sort of action on a database.”
[0017] “multiple microservice applications are utilized, where each microservice application has its own outbox table processor that can be connected to the same database and/or database container.”
[0025] “A user communicates with a user interface 102, which generates one or more action requests to one or more microservice applications 104A, 104B. The user interface 102 may be, for example, a dedicated client application running on a device of the user, or may be a web page running in a browser on the device of the user. Each of these action requests may request some sort of action (e.g., create, update, delete) involving one or more database data structures (such as database tables).”
[0026] “Each microservice application 104A, 104B then takes these action requests and generates one or more database statements (such as SQL statements) to a database 106 to perform the corresponding actions.”
[0033] “The microservice application 204 here may be a cloud application that may maintain a plurality of different microservice application instances 206A, 206B, each running a full version of the microservice application 204,”
[0025] “Each of these action requests may request some sort of action (e.g., create, update, delete) involving one or more database data structures (such as database tables).”
[0030] “As mentioned earlier, when a database action is performed by the microservice application 104B, it generates a SQL or similar database statement to perform an action on one or more of the data structures in the corresponding container.”
[0014] “When a database action is performed by the microservice application, that database action is written into the outbox table in the corresponding container in the database. Furthermore, whenever the outbox table processor determines that the state of the database has changed in a way that leads to an emit, it then reads the actions in the outbox table, issues an emit to notify one or more external systems of the actions, and deletes those actions from the outbox table.”
[0017] “multiple microservice applications are utilized, where each microservice application has its own outbox table processor that can be connected to the same database and/or database container.”
[0030] “when a database action is performed by the microservice application 104B, it generates a SQL or similar database statement to perform an action on one or more of the data structures in the corresponding container (here, that would be item table 110 and/or supplier table 112 of container 108B). Additionally, when this database statement is sent to the container 108B, another database statement is generated by the microservice application 104B and sent to the container 108B to write an entry corresponding to the database change in the outbox table 116B.”
[0029] “The outbox table processor 114A, 114B acts to write to and read from an outbox table (or similar data structure) 116A, 116B on a corresponding container 108A, 108B.”
[0031] “whenever the outbox table processor 114B determines that the state of the database has changed in a way that leads to an emit, it then reads the entries in the outbox table 116B and generates an emit to notify one or more external systems of the actions, and then also deletes the corresponding entries from the outbox table 116B.”
[0040] “once it is determined that the database transaction is committed, the outbox table is processed asynchronously.”
[0032] “these notifications are sent to message broker 118, which itself is an external system that generates and sends asynchronous communications to additional external systems 120A, 120B. A message broker is software that enables applications, systems, and services to communicate with each other and exchange information. Message brokers can be used for asynchronous communication using a publish/subscribe model. In this message distribution pattern, the source of each message publishes the message to a topic at the message broker, and multiple message consumers subscribe to topics from which they want to receive messages. All messages published to a topic are distributed to all the applications subscribed to it.”
[0033] “A user communicates with a user interface 202, which generates one or more action requests to microservice application 204.
However, KUNZ does not teach posting transmission of the one or more notifications to another topic, the other topic being associated with the determined one or more topics.
VO teaches posting transmission of the one or more notifications to another topic, the other topic being associated with the determined one or more topics. [0008] “According to another aspect of the present disclosure, the event received by the outbox transport processor is streamed to the target in a sequential manner.”
[0100] “The transporter 531 may sequentially receive or obtain events from the event store 525, and stream the received events to one or more targets included in the group of targets 540.”
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of VO to the teachings of KUNZ in order to stream received events to one or more targets included in the group of targets (0100).
As to claim 2, KUNZ teaches the instructions cause the processor to: query a database storing data associated with expiring events to determine whether expired events satisfy one or more criteria; generate a new notification event in response to the one or more criteria being satisfied; and process the new notification event to generate the one or more notifications with the event platform. [0023] “however, there is some criterion that is used to limit the entries read out. For example, it may only read out entries that correspond to particular types of database transactions, or which were requested by particular users, or that were added in a particular time period, etc.”
[0031] “whenever the outbox table processor 114B determines that the state of the database has changed in a way that leads to an emit, it then reads the entries in the outbox table 116B and generates an emit to notify one or more external systems of the actions”
As to claim 3, KUNZ teaches the database for generating events related to expiry is located on a cloud computing server separate from the event platform. [0033] “The microservice application 204 here may be a cloud application that may maintain a plurality of different microservice application instances 206A, 206B, each running a full version of the microservice application 204, but potentially located on a different physical server.
As to claim 4, KUNZ teaches to generate and transmit the one or more notifications, the instructions cause the processor to: determine whether one or more notification criteria are satisfied; and generate the one or more notifications in response to the notification criteria being satisfied. [0031] “This determination may be based on two criteria: (1) the outbox processor has sent a database statement for processing; and (1) the database statement changes the state of the database in a way that the change leads to an emit.”
As to claim 5, KUNZ teaches the instructions cause the processor to: determine that at least some existing events associated of at least one of the one or more applications requires retrofitting; and generate new events for the determined at least some existing events and post the new events to the respective outbox table for processing. [0031] “While the emit will often include a notification of the database action that the microservice application 104B just performed on the database container 108B, it can also include prior database actions that the microservice application 104B performed on the database container 108B but that were not part of a prior emit, possibly due to a failure of some type.”
As to claim 6, KUNZ teaches at least two of the plurality of services generate events based on a single application of the one or more applications. [0017] “multiple microservice applications are utilized, where each microservice application has its own outbox table processor that can be connected to the same database and/or database container.”
As to claim 7, KUNZ teaches the generated notification is generated by a notification service separate from the event platform. [0032] “these notifications are sent to message broker 118, which itself is an external system that generates and sends asynchronous communications to additional external systems 120A, 120B.”
As to claim 8, KUNZ teaches each of the one or more services is configured to independently post to the dedicated outbox table. [0017] “multiple microservice applications are utilized, where each microservice application has its own outbox table processor that can be connected to the same database and/or database container.”
[0029] “each microservice application 104A, 104B additionally contains an outbox table processor 114A, 114B. The outbox table processor 114A, 114B acts to write to and read from an outbox table (or similar data structure) 116A, 116B on a corresponding container 108A, 108B.”
As to claims 11-19, reference is made to a process that corresponds to the system of claims 1-8 and is therefore met by the rejection of claims 1-8 above. Claim 11 further details a method.
As to claim 20, reference is made to a non-transitory computer readable medium that corresponds to the system of claim 1 and is therefore met with the rejection above.
Claim(s) 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over KUNZ in view of VO as applied to claim 1 above, and further in view of CELESTINE (US PATENT 11228656)
As to claim 9, KUNZ and VO does not explicitly teach querying an enterprise database
CELESTINE teaches the instructions cause the processor to: with an event service associated with the determined subscription topic: query an enterprise database for notification information; and populate the one or more notifications with responses to the query. (Column 11, Line 55 – Column 12, line 19) The subscriber (micro)service uses the event information to identify the location of the publisher (micro)service and makes a direct connection to the publisher (micro)service (using, for example, a representational state transfer (“REST”) connection). In the example embodiment, the publisher (micro)service and subscriber (micro)service have their own APIs and the connection is made using such APIs. The subscriber (micro)service then requests the payload associated with the event or message by providing access information. (Column 9, Lines 30-36) “Downstream consumers (subscribers), like upstream consumers (publishers), enroll to set a communications protocol with the events platform and the message broker service. Accordingly, downstream consumers (subscribers) implement a service to receive events from the events platform via, for example, a subscriber API which receives events per the specific event rules for the event type” (Column 5, Lines 4-10) “the subscriber (micro)services. In such examples, the publisher (micro)service routes a message (or event) to the events platform which updates the message as necessary (including adding timestamps), updates a queue, and conveys the message to necessary subscribers. The event includes information to identify the publisher (micro)service to the subscriber (micro)service. The subscriber (micro)service uses the event information to identify the location of the publisher (micro)service and makes a direct connection to the publisher (micro)service”
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention to apply CELESTINE to the combination of KUNZ and VO in order to query an enterprise database with notifications.
As to claim 10 KUNZ teaches the event service is implemented on a remote computing environment, and the enterprise database is implemented on a private cloud of the enterprise. [0033] “The microservice application 204 here may be a cloud application that may maintain a plurality of different microservice application instances 206A, 206B, each running a full version of the microservice application 204, but potentially located on a different physical server.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELMAN MOHAMED ABDULLAHI whose telephone number is (571)272-8556. The examiner can normally be reached 7:30-5:00 (Fri alternating).
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, LEWIS BULLOCK can be reached at (571) 272-3759. 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.
/SELMAN MOHAMED ABDULLAHI/
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
.