DETAILED ACTION
This action is in response to communication filed on 9/5/2024.
Claims 1-20 are pending.
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
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 1-2, 4-5, 7-9, 11-12, 14-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Judge (US 2007/0300286) in view of Isaksson et al. (US 2010/0202469).
Regarding claim 1, Judge discloses a computer-implemented method comprising:
receiving an email message to be processed by a plurality of computing systems, wherein the plurality of computing systems each provide a different service for emails (Judge discloses receiving an email message for processing by multiple interrogation engines (computing system), each providing a different security service (e.g., firewall, intrusion detection, anti-virus, anti-spam); see [0046] “electronic communication directed to or originating from an email server is received. One or more tests can be applied to the received electronic communication to compare the sender's address in the received electronic communication to addresses contained in one or more whitelists” and [0086-0087] “FIG. 3 depicts a block diagram of the logical components of a security enhancement system…Blocks 320-360 represent different assessments that may be applied to electronic communications”);
generating a first request for a first computing system of the plurality of computing systems to process the email message (Judge discloses generating an index (request) for a received email to assign it to an interrogation engine (computing system) for processing. The index serves as a request for the first engine to process the stored email; see [0182] “Upon receipt at step 812, the communication is stored in a portion of the SDS referred to as the unprocessed message store. The communication is assigned at step 815 an index used to uniquely identify it in the unprocessed message store, and this index is placed in the first queue based upon the ordering constraints”);
adding the first request for the first computing system to a first request queue (Judge discloses adding the index (request) to the first queue for the first interrogation engine. The index is explicitly added to the first queue; see [0182] “Upon receipt at step 812, the communication is stored in a portion of the SDS referred to as the unprocessed message store. The communication is assigned at step 815 an index used to uniquely identify it in the unprocessed message store, and this index is placed in the first queue based upon the ordering constraints”).
However, the prior art does not explicitly disclose responsive to determining that a predetermined event has occurred for the first request queue, performing a skip action and removing the first request from the first request queue.
Isaksson in the field of the same endeavor discloses techniques for managing a queue of packets transmitted from a sender to a receiver across a communications network. In particular, Isaksson teaches the following:
responsive to determining that a predetermined event has occurred for the first request queue, performing a skip action and removing the first request from the first request queue (Isaksson discloses a queue manager that detect events (e.g., sender state changes or queue inactivity) and adjusts parameter to enable packet dropping (removal), directly aligning with event-triggered skipping; see [0052] “At step 708, the queue manager 304 determines whether the state of the sender (e.g., the state of a packet transmission process in the sender)is in the congestion avoidance state or will transition to the congestion avoidance state or detects an event suggesting that the sender is in the congestion avoidance state or will transition to the congestion avoidance state. In some embodiments, the step of detecting an event suggesting that sender will transition to the congestion avoidance state consists of determining that a packet 101 has been dropped from the queue 302” and [0054] “At step 714, the queue manager 304 determines whether the sender is currently in the slow-start state or detects an event suggesting that the sender is currently in the slow-start state. In some embodiments, the step of detecting an event suggesting that the sender is currently in the slow-start state consists of detecting whether the queue 302 has been inactive for a predetermined period of time”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Isaksson. One would have been motivated to improve the efficiency and responsiveness of queue management in a message threat processing system, yielding predictable results of enhanced system performance without undue experimentation.
Regarding claim 2, Judge-Isaksson discloses the method of claim 1, wherein the predetermined event is selected from the group of the first request remaining in the first request queue for an amount of time that exceeds a time threshold (Isaksson discloses a predetermined event where a packet (request) remains in the queue for a time exceeding a time threshold (Maximum Age Threshold), triggering removal (drop) from the queue; [0056-0057] “At step 804, the age of the oldest packet in the queue 302 is checked. If that packet has been in the queue for a period of time greater than the Maximum Age Threshold (T.sub.max), the queue management process 800 will proceed to step 806”),
the first computing system failing to process a queued request in the first request queue in a time window (Isaksson discloses an event where a packet (request) is not processed (remains queued) within a time window defined by the queue management parameter (e.g., Minimum Age Threshold or Maximum Age Threshold), leading to drop (removal). The “failing to process a queued request” is interpreted as the packet exceeding the time threshold without being forwarded (processed), triggering the action; see [0017] “the step of using the queue management parameter in deciding whether a packet in the queue should be dropped from the queue may include the following steps: (i) determining a time value representing the length of time the packet has been in the queue and (ii) comparing the time value to the value of the queue management parameter. In some embodiments, the packet is dropped from the queue in response to the result of the comparing step indicating that the time value is greater than the value of the queue management parameter”),
a request queue length of the first request queue exceeding a threshold length (Isaksson discloses a predetermined event where the queue length exceeds a threshold length (Lower Drop Threshold), contributing to the decision to drop (remove) a packet from the queue. Checking queue length against a threshold to trigger queue management actions; see [0060-0061] “At step 814, the queue management process checks whether the current length of the queue is greater than the Lower Drop Threshold (T.sub.LD). If the current length of the queue is not above T.sub.LD, queue management process 800 will proceed to step 812 and terminate. If the current length of the queue is greater than T.sub.LD, queue management process 800 will proceed to step 816. At step 816, the queue management process determines the amount of time that has elapsed since the last packet was dropped (.DELTA.t)”), and
combinations thereof (Isaksson discloses combining multiple conditions (queue length exceeding threshold, time-related threshold for age and inter-drop) to trigger the drop (removal) action. The decision process explicitly uses a combination of time and length threshold; see [0060-0063] “At step 814, the queue management process checks whether the current length of the queue is greater than the Lower Drop Threshold (T.sub.LD)…At step 816, the queue management process determines the amount of time that has elapsed since the last packet was dropped (.DELTA.t)…. At step 820, after queue management process 800 has determined that no packets have been dropped by this instance of the process, the current queue length is greater than the Lower Drop”).
Regarding claim 4, Judge-Isaksson discloses the method of claim 1, wherein performing the skip action comprises at least one action selected from the group of:
adding a second request for a second computing system of the plurality of computing systems to process the email message to a second request queue;
responsive to the first computing system performing a malware detection scanning service, determining to not deliver the email message (Judge [0106] “Such corrective measures could include refusing acceptance of further communications from the source of the received communication, quarantining the communication, stripping the communication so that it can be safely handled by the application server, and/or throttling excessive numbers of incoming connections per second to levels manageable by internal application servers”);
performing mitigation of the email message;
sending an alert to an administrator, the alert indicating that the predetermined event has occurred; and combinations thereof.
Regarding claim 5, Judge-Isaksson discloses the method of claim 4, wherein:
mitigation includes modifying the email message by at least one action selected from the group of removing a uniform resource locator in the email message, removing an attachment in the email message, rewriting one or more recipients of the email in the email message, generating a read-only version of the email in the email message, adding a warning to the email message, and combinations thereof (Judge [0106] “Such corrective measures could include refusing acceptance of further communications from the source of the received communication, quarantining the communication, stripping the communication so that it can be safely handled by the application server, and/or throttling excessive numbers of incoming connections per second to levels manageable by internal application servers”); and
the method further comprises delivering the modified email message (Judge [0188] “If no more interrogations are required (step 840), a further check is made to determine if the communication passed interrogation by all appropriate engines at step 850. If the communication passed all interrogations, then it is forwarded to its destination in step 855 and processing with respect to this communication ends at step 870”).
Regarding claim 7, Judge-Isaksson discloses the method of claim 1, wherein the plurality of computing systems performs a respective service selected from the group of scanning the email message for suspicious content, modifying the email message, routing the email message, and combinations thereof (Judge [0090] “Application specific anti virus protection and anti-spam protection 340 provides support for screening application specific communications for associated viruses and/or spam”).
Regarding claim 8, Judge-Isaksson discloses the method of claim 7, wherein scanning the email message for suspicious content includes an action selected from the group of scanning for malicious content, scanning for suspicious content, scanning for prohibited information, scanning for personally identifiable information, and combinations thereof (Judge [0090] “Application specific anti virus protection and anti-spam protection 340 provides support for screening application specific communications for associated viruses and/or spam”).
Regarding claim 9, Judge-Isaksson discloses the method of claim 7, wherein modifying the email message includes an action selected from the group of adding a warning banner to the email message, removing an attachment from the email message, rewriting a uniform resource locator (URL) in the email message to point to a URL protection service, and combinations thereof (Judge [0091] “Executable attachments or communication components, often sources of viruses and/or worms, and/or questionable content can be stripped or quarantined before they get to the application server or client”).
Regarding claim(s) 11-12, 14-15 and 16-17, 19-20, do(es) not teach or further define over the limitation in claim(s) 1-2, 4-5 respectively. Therefore claim(s) 11-12, 14-15 and 16-17, 19-20, is/are rejected for the same rationale of rejection as set forth in claim(s) 1-2, 4-5 respectively.
Claims 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Judge (US 2007/0300286) in view of Isaksson et al. (US 2010/0202469) in view of Kelly et al. (US 2009/0248814).
Regarding claim 6, Judge-Isaksson discloses the method of claim 1, further comprising:
delivering the email message (Judge [0157] “If a message passes normal interrogation 915, i.e. it is determined not to be spam or a threat (or to have a lower likelihood of being spam or a threat), it can be presented to its intended recipient for delivery 920”); and
performing a remedial action by:
responsive to the first computing system identifying the email message as suspicious, removing the email message from an email message inbox of a recipient or providing a warning to the recipient that identifies the email message as suspicious (Judge [0106] “Such corrective measures could include refusing acceptance of further communications from the source of the received communication, quarantining the communication, stripping the communication so that it can be safely handled by the application server, and/or throttling excessive numbers of incoming connections per second to levels manageable by internal application servers”).
However, the prior art does not explicitly disclose resubmitting the email message to the first computing system.
Kelly in the field of the same endeavor discloses techniques for processing email messages rescans emails messages that have already been scanned for spam and delivered to user inboxes with updated spam detection rules. In particular, Kelly teaches the following:
resubmitting the email message to the first computing system (Kelly [0019] “Once the updated rules 126 are downloaded, update and rescan plug-in 124 rescans the unread messages in the local inbox 122 and the recipient inbox 114 if the email software 121 maintains a connection to recipient inbox 114. The X-header of each unread message is checked and if the current rules are newer than the rules originally used to scan the mail at the email server 108, the message will be rescanned with the newer spam detection rules 126”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Kelly to improve detection accuracy by identifying and remediating previously undetected suspicion messages, yielding predictable results in enhance email security.
Allowable Subject Matter
Claims 3, 10, 13, and 18 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.
Conclusion
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451