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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-5, 8-12, and 15-19 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.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: the “interceptor,” “first scheduling service,” and “second scheduling service” in claim 8.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 15-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 15 refers to “the second scheduling service” in line 12. However, “a second scheduling service” has been defined twice; therefore, reference to “the second scheduling service” is ambiguous. Claims 16-19 depend on claim 15; therefore, they are rejected for the same reason.
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 (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 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.
Claim(s) 1, 2, 8, 15, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnaraj (US 2010/0005472) and further in view of Gassoway (US 2006/0029036) and further in view of Avetoom (US 2021/0157604) and further in view of Ciancio-Bunch (US 2014/0173012).
Regarding claim 1, Krishnaraj teaches: A method for scheduling tasks, the method comprising:
generating, by the interceptor service, tasks for carrying out the work request (¶ 182, “The process decomposer may be a business component that decomposes the requests from the request processor 1604, forming multiple messages” and ¶ 50, “At 240, the task is decomposed into one or more messages representing one or more respective discrete subtask”);
Krishnaraj does not teach; however, Gassoway discloses: marshalling, by the interceptor service, the tasks (¶ 44, “The client stub then performs marshaling (that is, a process of packaging, transporting, and unpackaging parameters between a client and a server) of the parameters (Step S602) by making calls into a library, giving a format of the data passed, having the library convert that data, and placing the data into a buffer”); and
unmarshalling, by the second scheduling service, the retrieved tasks (¶ 44, “When the client receives the reply, it exits the critical section protecting the sequence number and unmarshals the transmitted data (Step S606)”);
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of marshalling the tasks; and unmarshalling the retrieved tasks, as taught by Gassoway, in the same way to the tasks stored in queues, as taught by Krishnaraj. Both inventions are in the field of processing tasks, and combining them would have predictably resulted in “marshalling the remote calls into a format that can be understood both by the server and by the client,” as indicated by Gassoway (¶ 4).
Krishnaraj and Gassoway do not teach; however, Avetoom discloses: receiving, at an interceptor service (¶ 22, “A process distribution module 242 may include instructions for execution on the processor 220 to sort the client operations 236, 237, 238 from the provisioning clients 228, 230”), a work request implemented using hypertext transfer protocol and including a payload and metadata (¶ 25, “inspect a client operation (236, 237, or 238) upon receipt from a client 228” and “inspect one or more portions of the client operation (e.g., 236, 237, 238) including an HTTP header, payload, or other aspects of the data sent from a client 228, 230”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of receiving, at an interceptor service, a work request implemented using hypertext transfer protocol and including a payload and metadata, as taught by Avetoom, in the same way to the tasks stored in queues, as taught by Krishnaraj and Gassoway. Both inventions are in the field of receiving incoming requests, and combining them would have predictably resulted in “managing the distribution of traffic to software applications that ingest operations into an asynchronous queue when those operations are required to execute in a synchronous manner,” as indicated by Avetoom (¶ 30).
Krishnaraj, Gassoway, and Avetoom do not teach; however, Ciancio-Bunch discloses: storing, by a first scheduling service, the marshalled tasks in queues in a persistent memory shared with a second scheduling service (¶ 71, “The Build Manager and Injection Manager may transfer information (e.g. data or instructions) to one another using one or more blocking queues (e.g., durable blocking queue), which generally allow for blocking of functionality in some circumstances and sharing of work” and “write information relating to the individual emails to the one or more blocking queues”);
gathering, by the first scheduling service, email addresses needed to perform the tasks (¶ 43, “The activity data obtained in step 204 includes the type of information necessary to build and send emails, including informational content and recipient data”);
assigning, by the first scheduling service, the tasks to the second scheduling service (¶ 84, “the Build Manager 602 routes emails to the appropriate Send Center for injection into the Injection Manager at the Send Center”);
retrieving, by the second scheduling service, the tasks from the queues in the persistent memory shared with the first scheduling service (¶ 71, “the Injection Manager may be configured, for example, to read from the one or more blocking queues and inject the emails into an MTA”); and
sending, by the second scheduling service, the unmarshalled tasks to at least one service performer for execution (¶ 49, “After injection into the MTA in step 212, each email is sent to the intended recipient in step 214. One example of a system to support execution of the method 200 is displayed in FIG. 6A”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of storing, by a first scheduling service, the marshalled tasks in queues in a persistent memory shared with a second scheduling service; gathering, by the first scheduling service, email addresses needed to perform the tasks; assigning, by the first scheduling service, the tasks to the second scheduling service; retrieving, by the second scheduling service, the tasks from the queues in the persistent memory shared with the first scheduling service; and sending, by the second scheduling service, the unmarshalled tasks to at least one service performer for execution, as taught by Ciancio-Bunch, in the same way to the tasks stored in queues, as taught by Krishnaraj, Gassoway, and Avetoom. Both inventions are in the field of splitting a large job into units of work, and combining them would have predictably resulted in “a more efficient use of computing resources and a more reliable process,” as indicated by Ciancio-Bunch (¶ 24).
Regarding claim 2, Gassoway teaches: The method of claim 1, wherein the work request is a remote procedure call (¶ 27, “The first bind packet corresponds to a unique identifier that identifies the interface that a RPC connection is going to use”).
Claims 8, 15, and 16 recite commensurate subject matter as claims 1 and 2. Therefore, they are rejected for the same reasons.
Claim(s) 3, 9, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnaraj, Gassoway, Avetoom, and Ciancio-Bunch, as applied above, and further in view of Sawant (US 2024/0004739).
Regarding claim 3, Krishnaraj, Gassoway, Avetoom, and Ciancio-Bunch do not teach; however, Sawant discloses: the remote procedure call includes a flag (¶ 12, “receive RPC messages and to perform security operations and/or identity operations based on data stored in the header structures of the messages”) and wherein the method further comprises: identifying the flag in the remote procedure call (¶ 14, “The RPC messages are routed to rails and/or applications with respect to regions using header details passed from the sources in the payload of the message”); wherein the tasks are generated in response to identification of the flag (¶ 82, “At 514, a service interface function associated with the selected microservice is triggered based on routing data in the payload structure”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the remote procedure call includes a flag and wherein the method further comprises: identifying the flag in the remote procedure call; wherein the tasks are generated in response to identification of the flag, as taught by Sawant, in the same way to the remote procedure call, as taught by Krishnaraj, Gassoway, Avetoom, and Ciancio-Bunch. Both inventions are in the field of handling RPC calls, and combining them would have predictably resulted in “receiving and routing a remote procedure call (RPC) message from an external source,” as indicated by Sawant (abstract).
Claims 9 and 17 recite commensurate subject matter as claim 3. Therefore, they are rejected for the same reasons.
Claim(s) 4, 5, 10-12, 18, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krishnaraj, Gassoway, Avetoom, and Ciancio-Bunch, as applied above, and further in view of Broussard (US 2005/0155044).
Regarding claim 4, Krishnaraj, Gassoway, Avetoom, and Ciancio-Bunch do not teach; however, Broussard discloses: the marshalling comprises: converting the tasks to bytes (¶ 6, “RMI uses object serialization to marshal and unmarshal arguments for remote object calls. Object serialization refers to the ability to read or write an entire object to and from a raw byte stream”); wherein the storing comprises storing the bytes in the persistent memory (¶ 6, “It allows Java objects and primitives to be encoded into a byte stream suitable for streaming to some type of network, to a file-system, or more generally to a transmission medium or storage facility” and ¶ 22, “stored on a computer readable medium, for generating stubs needed to complete a call to a remote object in a Java technology based application or environment. The software may reside on a persistent medium such as a magnetic disk, magnetic tape, CD ROM, flash memory or other form of electrically alterable ROM”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the marshalling comprises: converting the tasks to bytes; wherein the storing comprises storing the bytes in persistent memory, as taught by Broussard, in the same way to the marshalling, as taught by Krishnaraj, Gassoway, Avetoom, and Ciancio-Bunch. Both inventions are in the field of marshalling tasks, and combining them would have predictably resulted in a method that “allows Java objects and primitives to be encoded into a byte stream suitable for streaming to some type of network,” as indicated by Broussard (¶ 6).
Regarding claim 5, Broussard teaches: The method of claim 4, wherein the retrieving comprises: retrieving the bytes from the persistent memory; wherein the unmarshalling comprises converting the retrieved bytes to the tasks (¶ 12, “On server-side 203, a tie file 122 receives the serialized byte stream sent by stub file 118 and de-serializes or un-marshals the corresponding arguments to reconstruct the objects and parameters of the remote object call”).
Claims 10-12, 18, and 19 recite commensurate subject matter as claims 4 and 5. Therefore, they are rejected for the same reasons.
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 JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/Primary Examiner, Art Unit 2198
Prosecution Insights