DETAILED ACTION
Notice of Pre-AIA or AIA Status
1.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
2.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.
3.Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Singla (US Pub.No.2014/0165140) in view of Thummala Abbigari (US Pat.No.10,812,608).
4. Regarding claims 1,4 and 14 Singla teaches a method and a system comprising: at an event bus service in a multi-tenant provider network: receiving a first event structure at an event bus, wherein the first event structure represents an event, and wherein the event bus is provisioned to a first provider network customer account; evaluate a set of one or more routing rules defined for the event bus against the first event structure (Para:0048 teaches the user and/or session information of an event may be determined from fields in the event wherein the events include security events, application events (e.g. financial transactions events), and other types of events generated by agents deployed at systems for which the security system has oversight. Para:0046 teaches the detection of potential intrusions, including fraud during the course of financial transactions, is facilitated by the generation of a reference baseline, which represents a pattern of historical (e.g. normal or anomalous) behavior or business patterns of a use; these patterns in the reference baseline are then used to detect anomalies in the user’s behavior.
Para:0042 teaches the rules engine is configured to compare a sequence of incoming events and time data (including time gaps) of a current session to the reference baseline associated with the particular user. Para:0078 teaches a user-specific reference baseline may include a sequence of event 1 followed by event 2, with an average time gap of 7 seconds wherein the reference baseline may include an attribute listing the average time gap between these specific events, and for purposes of rule-matching, a current session's sequence of events may be deemed to match the reference baseline as long as the time gap is within the standard deviation of 2 seconds from the average time gap in the reference baseline.
Para:0080 teaches any incoming sequence of a current session that does not match the reference baseline is deemed to be suspect, and the rule condition returns “true” (where the condition is looking for anomalous behavior), i.e. a rule fire. Where the reference baseline includes just those sequences indicative of “anomalous” user behavior, any incoming sequence of a current session that does not match the reference baseline is deemed to be non-suspect, and the rule condition returns “false”);
determining that the first event structure matches an event pattern of a particular routing rule of the set of one or more routing rules (Para:0066, Para:0073 and Para:0094 teaches the distinctive sequences in the reference baseline are used to detect anomalies in the user's behavior. Para:0067, Para: 0092-0095 teaches the new sequence may also be added to the baseline but flagged as anomalous, such that future matches to this pattern will cause the rule to be fired... a flow that is flagged as anomalous and/or otherwise suspicious.
Para:0098 teaches the rule conditions that look for fraud-related rule firings and also look for security- related rule firings, for example for a target host. When the conditions are satisfied, correlation may be performed thereby bridging transactional or fraud-based event knowledge with security data);
and delivering an event structure representing the event to the particular target resource, wherein the event structure comprises the encrypted event data (Para:0029-0030 teaches the event manager generates the event data messages such as correlation events and audit events. Where bi-directional communication with agents 12a-n is implemented, event manager may be used to transmit messages to agents 12a-n wherein if encryption is employed for agent-manager communications, event manager is responsible for decrypting the messages received from agents 12a-n and encrypting any messages transmitted to agents 12a-n).
Singla teaches all the above claimed limitations but fails to teach selecting a particular cryptographic key to use to encrypt the event data based on the particular routing rule or the particular target resource; encrypting an event data of the first event structure using a particular cryptographic key belonging to the second provider network account to yield an encrypted event data.
Thummala Abbigari teaches the particular routing rule specifies a particular target resource in the multi-tenant provider network, and wherein the particular target resource is provisioned to a second provider network customer account (Fig.4B and Col.16, lines.58-65 teaches selective delivery of events to consumers/recipients in a multi-tenant provider network . Figs.1A-B and Col.6, lines.51-64 teaches the event (e.g., first event 115A) is delivered to only a subset of all of the consumers (e.g., consumers 159A, 159B, and 159J) that corresponds to the intended recipients (e.g., consumers with IDs “1,” “4,” and “2”) based on a subset of the data structures to which the event was added (e.g., data structures 153A, 153B, and 153J). Delivering an event to a consumer means sending an event to or making an event available for a consumer such that the consumer can consume the event. Thus, implementations allow for selective delivery of an event to consumers, based on an attribute included in the event and the set of IDs for intended recipients for the event);
selecting a particular cryptographic key to use to encrypt the event data based on the particular routing rule or the particular target resource; encrypting an event data of the first event structure using a particular cryptographic key belonging to the second provider network account to yield an encrypted event data ; durably storing the encrypted event data before delivery of the encrypted event data to the particular target resource; (Col.2, lines.5-12 teaches an event to be delivered to a consumer based on intended recipients for that event (i.e., a recipient to which an event is intended to be delivered). Col.9, lines.24-34 teaches encrypting event means to encode it such that only authorized entities can decrypt it (and decrypting data means to decode encrypted data such that it can be read). Col.9, lines. 55-67; Col.10, lines.1-2 teaches the publisher of an event may encrypt the payload of an event with a public key provided by a consumer which is an intended recipient of the event, and the consumer which is the intended recipient may decrypt the payload of the event with the private key corresponding to the public key that the consumer provided to the publisher, as such selecting user specific cryptographic key (public/private key) to encrypt and decrypt event data);
and delivering a second event structure representing the event to the particular target resource, wherein the second event structure comprises the encrypted event data (Fig.3, Col.12, lines.-50-58 teaches delivering a second event structure to an intended recipients based on the identifier.Col.9, lines. 55-67; Col.10, lines.1-2 teaches delivering encrypted event data).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Singla to include selecting a particular cryptographic key to use to encrypt the event data based on the particular routing rule or the particular target resource; encrypting an event data of the first event structure using a particular cryptographic key belonging to the second provider network account to yield an encrypted event data as taught by Thummala Abbigari such a setup will provide finer-grained control over delivery of events to consumers by performing recipient-based filtering, and thus improve flexibility for publishers, relevance for consumers, and/or efficient use of computing resources in publish-subscribe messaging.
5. Regarding claims 2, 5 and 15 Thummala Abbigari teaches the method and the system, further comprising: at the event bus service in the multi-tenant provider network: selecting the particular cryptographic key to use to encrypt the event data based on determining a user-specified association between the particular cryptographic key and the particular routing rule (Figs.1A-B and Col.6, lines.51-64 teaches the event (e.g., first event 115A) is delivered to only a subset of all of the consumers (e.g., consumers 159A, 159B, and 159J) that corresponds to the intended recipients (e.g., consumers with IDs “1,” “4,” and “2”) based on a subset of the data structures to which the event was added (e.g., data structures 153A, 153B, and 153J). Delivering an event to a consumer means sending an event to or making an event available for a consumer such that the consumer can consume the event. Thus, implementations allow for selective delivery of an event to consumers, based on an attribute included in the event and the set of IDs for intended recipients for the event.
Col.2, lines.5-12 teaches an event to be delivered to a consumer based on intended recipients for that event (i.e., a recipient to which an event is intended to be delivered). Col.9, lines.24-34 teaches encrypting event means to encode it such that only authorized entities can decrypt it (and decrypting data means to decode encrypted data such that it can be read). Col.9, lines. 55-67; Col.10, lines.1-2 teaches the publisher of an event may encrypt the payload of an event with a public key provided by a consumer which is an intended recipient of the event, and the consumer which is the intended recipient may decrypt the payload of the event with the private key corresponding to the public key that the consumer provided to the publisher, as such selecting user specific cryptographic key (public/private key) to encrypt and decrypt event data).
6. Regarding claims 3,6 and 16 Thummala Abbigari teaches the method and the system, further comprising: at the event bus service in the multi-tenant provider network: selecting the particular cryptographic key to use to encrypt the event data based on determining a user-specified association between the particular cryptographic key and the particular target resource (Figs.1A-B and Col.6, lines.51-64 teaches the event (e.g., first event 115A) is delivered to only a subset of all of the consumers (e.g., consumers 159A, 159B, and 159J) that corresponds to the intended recipients (e.g., consumers with IDs “1,” “4,” and “2”) based on a subset of the data structures to which the event was added (e.g., data structures 153A, 153B, and 153J). Delivering an event to a consumer means sending an event to or making an event available for a consumer such that the consumer can consume the event. Thus, implementations allow for selective delivery of an event to consumers, based on an attribute included in the event and the set of IDs for intended recipients for the event.
Col.2, lines.5-12 teaches an event to be delivered to a consumer based on intended recipients for that event (i.e., a recipient to which an event is intended to be delivered). Col.9, lines.24-34 teaches encrypting event means to encode it such that only authorized entities can decrypt it (and decrypting data means to decode encrypted data such that it can be read). Col.9, lines. 55-67; Col.10, lines.1-2 teaches the publisher of an event may encrypt the payload of an event with a public key provided by a consumer which is an intended recipient of the event, and the consumer which is the intended recipient may decrypt the payload of the event with the private key corresponding to the public key that the consumer provided to the publisher, as such selecting user specific cryptographic key (public/private key) to encrypt and decrypt event data).
7. Regarding claims 7 and 17 Thummala Abbigari teaches the method and the system, wherein the second event structure identifies in plaintext the particular cryptographic key used to encrypt the event data (Col.10, lines.24-37 teaches event structure identifies in plaintext. Col.9, lines.24-34 ; lines. 55-67; and Col.10, lines.1-2 teaches the cryptographic key used to encrypt the event data).
8. Regarding claims 8 and 18 Thummala Abbigari teaches the method and the system, wherein the second event structure identifies in plaintext the event bus (Col.10, lines.24-37 teaches the event structure identifies in plaintext the event bus).
9. Regarding claims 9 and 19 Thummala Abbigari teaches the method and the system, wherein a multi-tenant service in the multi-tenant provider network comprises the particular target resource provisioned to the second provider network customer account and also comprises other resources provisioned to other provider network customer accounts (Fig.4B and Col.16, lines.58-65 teaches a multi-tenant provider network. Figs.1A-C and Col.3, lines.12-40 teaches the target resource provisioned to the second provider network customer account).
10. Regarding claims 10 and 20 Thummala Abbigari teaches the method and the system, wherein the event bus is a first event bus; wherein the particular target resource comprises a second event bus provisioned to the second provider network customer account; and wherein the method further comprises: at the event bus service in the multi-tenant provider network: receiving the second event structure at the second event bus (Figs.3-4 and Col.12, lines.28-37 teaches another request is submitted to publish a second event) , the second event structure comprising an unencrypted portion and the encrypted event data; using the particular cryptographic key or a cryptographic key associated with the particular cryptographic key to decrypt the encrypted event data to yield a decrypted event data; evaluating a set of one or more routing rules defined for the second event bus against a third event structure, wherein the third event structure comprises the unencrypted portion and the decrypted event data; encrypting the decrypted event data using the particular cryptographic key to yield a re-encrypted event data; and durably storing the re-encrypted event data (Col.9, lines24-33 teaches header in an event can also allow the header and the body of the event to be encrypted separately. Encrypting data means to encode it such that only authorized entities can decrypt it (and decrypting data means to decode encrypted data such that it can be read). In one implementation, an event's header may be unencrypted and the event's body encrypted. In another implementation, an event's header and body may be encrypted, but encrypted separately (i.e., using different ciphers, using different public-private key pairs, etc.). Either of these implementations provide for encrypted transmission of the event's payload.Col.9, lines.59-67; Col.10, lines.1-9 teaches the publisher of an event may encrypt the payload of an event with a public key provided by a consumer which is an intended recipient of the event, and server 100 or the source of events 103 may encrypt the header of the event with a public key provided by server 106. Then server 106 may decrypt the header of the event with a private key corresponding to the public key that the server provided, and the consumer which is the intended recipient may decrypt the payload of the event with the private key corresponding to the public key that the consumer provided to the publisher. Other implementations are possible (e.g., a shared key is used by multiple consumers to decrypt a payload of an event that is delivered to those consumers, the server decrypts both the header and payload of an event and delivers the event to one or more consumers securely (e.g., using transport layer security (TLS), secure sockets layer (SSL) technology, by re-encrypting the payload such that the consumers can decrypt it, etc.).
11. Regarding claim 11 Thummala Abbigari teaches the method, further comprising: at the event bus service in the multi-tenant provider network: receiving a request to publish the first event structure to the event bus, the request comprising an identifier of the particular cryptographic key; and selecting the particular cryptographic key to use to encrypt the event data based on the particular cryptographic key being identified in the request to publish (Figs.1A-C, and Col.2, lines.5-12; lines.45-65 teaches receiving a request to publish an event. A request to publish an event is a request to make an event available in a source of events. With reference to FIG. 1C, in block 188 wherein a request to publish an event is received. For example, implementations may include block 191, where the request includes a set of identifiers for the intended recipients. An identifier is data that identifies (e.g., an intended recipient of an event). An identifier may be a unique identifier (i.e., an identifier that identifies a single entity, such as a single intended recipient).The request includes a payload and an identifier for a topic per block 193. Optionally, the payload and the identifier for the topic are included in another event per block 195. Thus, implementations may support 1) a request including data for an event, the data including a payload and a topic ID, 2) that data being included in another event, and/or 3) the request including a set of identifiers for intended recipients.
Figs.1A-B and Col.6, lines.51-64 teaches the event (e.g., first event 115A) is delivered to only a subset of all of the consumers (e.g., consumers 159A, 159B, and 159J) that corresponds to the intended recipients (e.g., consumers with IDs “1,” “4,” and “2”) based on a subset of the data structures to which the event was added (e.g., data structures 153A, 153B, and 153J). Delivering an event to a consumer means sending an event to or making an event available for a consumer such that the consumer can consume the event. Thus, implementations allow for selective delivery of an event to consumers, based on an attribute included in the event and the set of IDs for intended recipients for the event Col.9, lines.24-34 teaches encrypting event means to encode it such that only authorized entities can decrypt it (and decrypting data means to decode encrypted data such that it can be read). Col.9, lines. 55-67; Col.10, lines.1-2 teaches the publisher of an event may encrypt the payload of an event with a public key provided by a consumer which is an intended recipient of the event, and the consumer which is the intended recipient may decrypt the payload of the event with the private key corresponding to the public key that the consumer provided to the publisher).
12. Regarding claim 12 Thummala Abbigari teaches the method, further comprising: at the event bus service in the multi-tenant provider network: receiving a request to publish the first event structure to the event bus, wherein the request to publish comprises the particular cryptographic key; and selecting the particular cryptographic key to use to encrypt the event data based on the particular cryptographic key being in the request to publish (Col.2, lines.5-12; lines.45-65 teaches receiving a request to publish an event. A request to publish an event is a request to make an event available in a source of events. With reference to FIG. 1C, in block 188 wherein a request to publish an event is received. For example, implementations may include block 191, where the request includes a set of identifiers for the intended recipients. An identifier is data that identifies (e.g., an intended recipient of an event). An identifier may be a unique identifier (i.e., an identifier that identifies a single entity, such as a single intended recipient).The request includes a payload and an identifier for a topic per block 193. Optionally, the payload and the identifier for the topic are included in another event per block 195. Thus, implementations may support 1) a request including data for an event, the data including a payload and a topic ID, 2) that data being included in another event, and/or 3) the request including a set of identifiers for intended recipients.
Figs.1A-B and Col.6, lines.51-64 teaches the event (e.g., first event 115A) is delivered to only a subset of all of the consumers (e.g., consumers 159A, 159B, and 159J) that corresponds to the intended recipients (e.g., consumers with IDs “1,” “4,” and “2”) based on a subset of the data structures to which the event was added (e.g., data structures 153A, 153B, and 153J). Delivering an event to a consumer means sending an event to or making an event available for a consumer such that the consumer can consume the event. Thus, implementations allow for selective delivery of an event to consumers, based on an attribute included in the event and the set of IDs for intended recipients for the event. Col.9, lines.24-34 teaches encrypting event means to encode it such that only authorized entities can decrypt it (and decrypting data means to decode encrypted data such that it can be read). Col.9, lines. 55-67; Col.10, lines.1-2 teaches the publisher of an event may encrypt the payload of an event with a public key provided by a consumer which is an intended recipient of the event, and the consumer which is the intended recipient may decrypt the payload of the event with the private key corresponding to the public key that the consumer provided to the publisher).
13. Regarding claim 13 Thummala Abbigari teaches the method, further comprising: at the event bus service in the multi-tenant provider network: receiving a request to publish the first event structure to the event bus, wherein the first event structure comprises a plurality of cryptographic keys, wherein the plurality of cryptographic keys comprises the particular cryptographic key, and wherein the request to publish comprises a path expression selecting the particular cryptographic key in the first event structure; and selecting the particular cryptographic key to use to encrypt the event data based on the particular cryptographic key being selected by the path expression of the request to publish (Col.2, lines.5-12; lines.45-65 teaches receiving a request to publish an event. A request to publish an event is a request to make an event available in a source of events. With reference to FIG. 1C, in block 188 wherein a request to publish an event is received. For example, implementations may include block 191, where the request includes a set of identifiers for the intended recipients. An identifier is data that identifies (e.g., an intended recipient of an event). An identifier may be a unique identifier (i.e., an identifier that identifies a single entity, such as a single intended recipient).The request includes a payload and an identifier for a topic per block 193. Optionally, the payload and the identifier for the topic are included in another event per block 195. Thus, implementations may support 1) a request including data for an event, the data including a payload and a topic ID, 2) that data being included in another event, and/or 3) the request including a set of identifiers for intended recipients.
Figs.1A-B and Col.6, lines.51-64 teaches the event (e.g., first event 115A) is delivered to only a subset of all of the consumers (e.g., consumers 159A, 159B, and 159J) that corresponds to the intended recipients (e.g., consumers with IDs “1,” “4,” and “2”) based on a subset of the data structures to which the event was added (e.g., data structures 153A, 153B, and 153J). Delivering an event to a consumer means sending an event to or making an event available for a consumer such that the consumer can consume the event. Thus, implementations allow for selective delivery of an event to consumers, based on an attribute included in the event and the set of IDs for intended recipients for the event. Col.9, lines.24-34 teaches encrypting event means to encode it such that only authorized entities can decrypt it (and decrypting data means to decode encrypted data such that it can be read). Col.9, lines. 55-67; Col.10, lines.1-2 teaches the publisher of an event may encrypt the payload of an event with a public key provided by a consumer which is an intended recipient of the event, and the consumer which is the intended recipient may decrypt the payload of the event with the private key corresponding to the public key that the consumer provided to the publisher).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEREENA T CATTUNGAL whose telephone number is (571)270-0506. The examiner can normally be reached Mon-Fri : 7:30 AM-5 PM EST.
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, Lynn Feild can be reached at 571-272-2092. 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.
/DEREENA T CATTUNGAL/ Primary Examiner, Art Unit 2431