CTNF 18/721,143 CTNF 75500 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1-5, 7-12 and 14-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinski et al US 12,500,887 in view of Sur et al US 10,795,743 . Regarding claims 1, 8 and 16 Pinski et al teaches searching every method subordinate to a process file for a first method that meets preset rules (column 4, line 65, to start using webhooks in an event bus, clients can use a management console, a command line interface, a software development kit, or a template. To receive events from a web service, clients can create a new webhook path for their event bus, and specify the validation type, enabling them to verify that the events coming to the event bus web address are from an authorized source. To send an event to a web service, clients can create a new rule. Clients might also select a “Generic API” option as the target. Clients can then specify the web address to which the event bus service will send the event, and optionally configure authentication specific to the web service. For example, clients can, in some embodiments, access the console for the event bus service, and create a new webhook path for their event bus. Clients can also configure web addresses as targets for their rules. The clients can specify, in these embodiments, multiple paths for an event bus, allowing them to share it across several services, configure authentication parameters for destinations, as well as set validation rules that will ensure that the incoming events were received from an authorized source. In short, some embodiments allow clients to just configure a path or target API, specify the validation or authentication method, and be instantly ready to receive and send events); determining a target corresponding to the first method based on information of the first method, and generating display information (column 9, line 46, a rule management service can manage the rules in which the event bus service (100) receives and routes authenticated events (113) via defined rules to event targets (120a, 120b). The target events (122a, 122b) result from the event bus applying rules to route the appropriate events to the appropriate event target 120. In various embodiments, rules may be conditions that inform the event bus service how to match incoming events to event targets and route them accordingly (e.g., as discussed in detail below with regard to FIGS. 2 and 3). A single rule can route an event to multiple targets, in some embodiments. Rules may be specified or sent to the rule management service via an interface for event bus 100 and published in various data formats similar to events such as JSON, BJSON, XML, YAML, etc. Rules may be used by the rule management service to process events in parallel and need not be processed in a particular order. A rule management service may include instructions to modify the event to be sent to by the event bus system to the event targets such as passing certain portions of the event or overwriting certain portions of the event with a predefined value); response to the type of a method searched being send, or in response to the information of the method searched comprising annotation information of the receiving target, determining that the method searched meets the preset rules (column 14, line 46, in some embodiments, the rule management service 220 stores rules which are conditions that inform the event ingestion and routing 214 how to match incoming events to event targets and route them to event target(s) 320 accordingly. Rule may comprise event source attribute that describes the source from which the event was generated such as the entity of the event source or the category of event sources. Rule may also comprise event destination attribute that describes the event target 320, in some embodiments. Event destination attribute may include any number of event target attributes such as an entity of the event target, the category of event target, or the location of the event target. Rules may be used by the rule management service 220 to process events in parallel and need not be processed in a particular order. In some embodiments, the rule management service 220 may receive changes to the rules. In some embodiments, the rule management service 220 may determine that changes to rules have been made with respect to rules having a specific event source attribute). Pinski et al teaches event bus but doesn’t teach explicitly the target comprises a receiving target and a sending target, the information of the first method comprises one or more of a type of the first method or annotation information of the first method, however Sur et al teaches (column 1, line 30, the present disclosure concerns the management of notifications that are sent to a user concerning a computing device. An exemplary computer system may communicate with a plurality of embedded devices, including a particular embedded device that sends an indication to the computer system about an exception condition that previously occurred, is currently occurring, or will/is expected to occur at that device. The computer system performs steps that are part of a response to the exception condition, including a plurality of steps that are performed using data objects stored on the computer system. The computer system may run software referred to as a “notification choreographer module” that receives notifications as a result of these steps being performed using data objects, and publishes events corresponding to at least some of the received notifications to an event bus). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate sending target the information. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into event driven monitoring system where the behavior can be achieved with the help of an event bus-a piece of software that is responsible for routing events from one service to another in order to facilitate the complex traffic of events, the event bus system may be used to mediate the events being sent and received and thereby further decouple the various microservices. Regarding claims 2, 9 and 18 Pinski et al teaches in response to the type of the first method being send, determining that a caller of the first method is the sending target corresponding to the first method information, and generating the display information (see figs 2 and 13, column 4, line 51, for example, upon receiving a payload, the client was may hash the payload themselves with their own secret using the same schema, and compare against the signature to validate the caller, then proceed with handling the published event. Offering this as a managed solution for an event bus service means letting a client create an event bus-specific HTTP endpoint, and then specifying: 1) a secret and authorization scheme for validation, and 2) static values or JSON paths to map a given event payload to an event source/detail-type, so the event bus service can map it to a valid call to add/put events. The event bus service then can hash the payload with its received secret using its received schema, compare against the signature to validate the caller, and then proceed with handling the published event). The feature of providing caller and display… would be obvious for the reasons set forth in the rejection of claim 1. Regarding claims 3, 10 and 19 Pinski et al teaches in response to the information of the first method comprising annotation information of the receiving target, determining that a caller of the first method is the receiving target corresponding to the first method, and generating the display information (see figs 2 and 13, column 4, line 51, for example, upon receiving a payload, the client was may hash the payload themselves with their own secret using the same schema, and compare against the signature to validate the caller, then proceed with handling the published event. Offering this as a managed solution for an event bus service means letting a client create an event bus-specific HTTP endpoint, and then specifying: 1) a secret and authorization scheme for validation, and 2) static values or JSON paths to map a given event payload to an event source/detail-type, so the event bus service can map it to a valid call to add/put events. The event bus service then can hash the payload with its received secret using its received schema, compare against the signature to validate the caller, and then proceed with handling the published event). The feature of providing caller and display… would be obvious for the reasons set forth in the rejection of claim 1. Regarding claims 4, 11 and 20 Pinski et al teaches in response to the type of the first method being send and the information of the first method comprising the annotation information of the receiving target, outputting the display (column 6, line 17, when events occur on third-party services, for example, the third-party service will send an event to the event bus address. After the service sends the event to the event bus service, its integrity and origin will be verified by, for example, validating the originating IP address, basic user credentials, payload signature, or API key. Clients can also configure HTTPS endpoints to only accept events from specific IP addresses or range of addresses, in addition to verifying the integrity of the event through signatures and API keys, in some embodiments. If the event passes verification, the event bus service will process the event and send it to configured targets. If the verification fails, the event bus service will discard the event. The event bus service also allows clients to create rules and input transformations to events received from webhooks, in some embodiments). The feature of providing send and display… would be obvious for the reasons set forth in the rejection of claim 1. Regarding claims 5 and 21 Pinski et al teaches in response to determining that the process file is in a preset whitelist, not searching any methods subordinate to the process file for the first method that meets the preset rules and in response to the process file not being in a preset whitelist, searching every method subordinate to the process file for the first method that meets the preset rules (column 16, line 52, the authorization schemes might be API key based, in some embodiments. The event-driven compute service authorizer (503) can check for authentication information, such as for example a specific key, given by the customer on an incoming request header specified by the 3rd party SaaS providers (510). Presence of that authentication information (e.g., key) in the specified header indicates requests coming from the right source, which is that 3rd party SaaS provider (510). In some embodiments, the event-driven compute service authorizer (503) can use the authentication information (e.g., a secret) provided by the customer to create a HMAC-SHA1/SHA256. The event-driven compute service authorizer (503) can hash the request payload, and compare it with the signature provided in the incoming header specified by the 3rd party SaaS providers (510), in some embodiments. A positive match of that signature in the specified header indicates requests are coming from the right source, which is that 3rd party SaaS provider. In some embodiments, the event bus service automated authorization verification component (502) can also provide IP filtering, such as, for example, to only allow requests received from IPs that are on an IP whitelist. Once events are authenticated, they can be provided to an event bus in an event bus service account (508). The feature of providing whitelist and rules… would be obvious for the reasons set forth in the rejection of claim 1. Regarding claims 7, 12 and 14 Pinkski et al teaches in response to determining that the process file is in a preset whitelist, not searching all methods subordinate to the process file for the methods that meet the preset rules and in response to the process file not being in the preset whitelist, searching every method subordinate to the process file for the methods that meet the preset rules (column 16, line 52, the authorization schemes might be API key based, in some embodiments. The event-driven compute service authorizer (503) can check for authentication information, such as for example a specific key, given by the customer on an incoming request header specified by the 3rd party SaaS providers (510). Presence of that authentication information (e.g., key) in the specified header indicates requests coming from the right source, which is that 3rd party SaaS provider (510). In some embodiments, the event-driven compute service authorizer (503) can use the authentication information (e.g., a secret) provided by the customer to create a HMAC-SHA1/SHA256. The event-driven compute service authorizer (503) can hash the request payload, and compare it with the signature provided in the incoming header specified by the 3rd party SaaS providers (510), in some embodiments. A positive match of that signature in the specified header indicates requests are coming from the right source, which is that 3rd party SaaS provider. In some embodiments, the event bus service automated authorization verification component (502) can also provide IP filtering, such as, for example, to only allow requests received from IPs that are on an IP whitelist. Once events are authenticated, they can be provided to an event bus in an event bus service account (508). The feature of providing whitelist and rules… would be obvious for the reasons set forth in the rejection of claim 1 . Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 Claim s 6 and 13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Relevant Prior Art US 12099519 B1 Baldawa et al teaches Replicated Events In A Multi-region Network US 11755698 B2 Isaacs teaches Systems, Methods, And Devices For Automation And Integration Of Credentialing And Authentication In Workflows Associated With Computing Platforms US 9811434 B1 Wagner teaches Predictive Management Of On-demand Code Execution Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anil Khatri whose telephone number is (571)272-3725. The examiner can normally be reached M-F 8:30-5:00. 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, Wei Zhen can be reached at 571-272-3708. 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. /ANIL KHATRI/Primary Examiner, Art Unit 2191 Application/Control Number: 18/721,143 Page 2 Art Unit: 2191 Application/Control Number: 18/721,143 Page 3 Art Unit: 2191 Application/Control Number: 18/721,143 Page 4 Art Unit: 2191 Application/Control Number: 18/721,143 Page 5 Art Unit: 2191 Application/Control Number: 18/721,143 Page 6 Art Unit: 2191 Application/Control Number: 18/721,143 Page 7 Art Unit: 2191 Application/Control Number: 18/721,143 Page 8 Art Unit: 2191 Application/Control Number: 18/721,143 Page 9 Art Unit: 2191 Application/Control Number: 18/721,143 Page 10 Art Unit: 2191 Application/Control Number: 18/721,143 Page 11 Art Unit: 2191
Prosecution Insights