Prosecution Insights
Last updated: April 19, 2026
Application No. 14/323,450

Distributed Cloud Computing Platform

Final Rejection §103§112
Filed
Jul 03, 2014
Examiner
RAZA, MUHAMMAD A
Art Unit
2449
Tech Center
2400 — Computer Networks
Assignee
Comcast Cable Communications LLC
OA Round
12 (Final)
58%
Grant Probability
Moderate
13-14
OA Rounds
3y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 58% of resolved cases
58%
Career Allow Rate
158 granted / 274 resolved
At TC average
Strong +71% interview lift
Without
With
+70.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
32 currently pending
Career history
306
Total Applications
across all art units

Statute-Specific Performance

§101
17.0%
-23.0% vs TC avg
§103
47.7%
+7.7% vs TC avg
§102
6.5%
-33.5% vs TC avg
§112
21.4%
-18.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 274 resolved cases

Office Action

§103 §112
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 . Claims 1-39 are pending in this Office Action. Response to Arguments Applicant’s arguments filed in the amendment filed on 02/26/2026, have been fully considered but they are not persuasive. The reasons set forth below. Drawings The formal drawings received on 07/03/2014 have been entered. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1-39 is/are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1, 10, and 14 recite “determine a network condition of the local gaming session,” which is not disclosed by the applicant’s specification. Claims 1, 10, and 14 recite “route, based on the network condition, non real-time sensitive …,” which is not disclosed by the applicant’s specification. Claim 13 recites “wherein routing the non real-time sensitive data comprises sending the non real-time sensitive data via a high-latency network connection,” which is not disclosed by the applicant’s specification. Claims 32, 35, 38 recite “wherein the network condition is a number of interaction commands processed at a given time,” which is not disclosed by the applicant’s specification. Claims 33, 36, 39 recite “wherein the system further comprises at least one second user device and wherein the system is further configured to prioritize the one or more interaction commands over other traffic so as to match latencies between the at least one user device and the at least one second user device,” which is not disclosed by the applicant’s specification. 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 1-39 is/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 limitation “Claim 1. … each server of the plurality of servers is configured to: send, via a local gaming session, to at least one user device participating in the local gaming session, by a server of the plurality of servers nearest to the at least one user device, a data stream comprising gaming data; receive, via the local gaming session, from the at least one user device, one or more interaction commands associated with the gaming data; determine a network condition of the local gaming session …; and route, based on the network condition non real-time sensitive data …; and the at least one user device, configured to: send, via the local gaming session, the one or more interaction commands to the server of the plurality of servers. Claim 4. … each server of the plurality of servers is further configured to: determine, for each interaction command of the one or more interaction commands, a priority, wherein the priority comprises either a high priority or a low priority; and process, based on the priority, high priority interaction commands prior to low priority interaction commands. Claim 5. … each server of the plurality of servers is further configured to: send the high priority interaction commands prior to the low priority interaction commands. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. There is insufficient disclosure of the corresponding structure, material, or acts for performing the entire claimed function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Applicant may: (a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph; (b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)). If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either: (a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181. 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. Claim(s) 1-2, 9-11, 14, 15, and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283) and Schrecke (US 20140328205). Claims 10, 1. Barak teaches: A method comprising: – in paragraphs [0022]-[0047] (The disclosed subject matter is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the subject matter.) sending, via a local gaming session, by a server of a plurality of servers nearest at least one user device participating in the local gaming session, to the at least one user device, – in paragraphs [0043]-[0047], Fig. 2 (A first player (not shown) is using end unit 1 (200) or a first console to connect to server 1 (204), and a second player (not shown) is using end unit 2 (220) or a second console to connect to server 2 (224). Server 1 (204) and server 2 (224) are part of a cloud computing system. Thus, all the associated players and servers may be present at totally different locations, such as cities, countries or continents. Server 1 (204) which may be implemented as any computing platform is executing gaming application 1 (212), which serves as a "wrapper" for, or communicates with game session 1 (208) which executes the specific game selected by the players. Similarly, server 2 (224) is executing gaming application 2 (232), which serves as a "wrapper" to, or communicates with game session 2 (228). Gaming application 1 (212) and gaming application 2 (232) enable the players to play the game by providing access to game session 1 (208) and game session 2 (228), respectively. Game session 1 (208) and game session 2 (228) communicate through communication server 236 in order to provide notifications about users' actions and status. For example, game session 1 (208) may be notified about the first player pressing on a particular button, and may take the relevant actions and generate the corresponding video, and may also notify game session 2 (228) which analyzes the situation and also generates a video.) a data stream comprising real-time sensitive data; – in paragraphs [0043]-[0047], Fig. 2 (Although the two players participate in the same game, two different instances are created, being game session 1 (208) and game session 2 (228), servers are active in providing the game, and two video streams are created and sent to end unit or console 1 (200) and end unit or console 2 (220).) receiving, by the server of the plurality of servers via the local gaming session, a plurality of interaction commands associated with the real-time sensitive data from the at least one user device; – in paragraphs [0043]-[0047], Fig. 2 (Server 1 (204) which may be implemented as any computing platform is executing gaming application 1 (212), which serves as a "wrapper" for, or communicates with game session 1 (208) which executes the specific game selected by the players. Similarly, server 2 (224) is executing gaming application 2 (232), which serves as a "wrapper" to, or communicates with game session 2 (228). Game session 1 (208) and game session 2 (228) communicate through communication server 236 in order to provide notifications about users' actions and status. For example, game session 1 (208) may be notified about the first player pressing on a particular button, and may take the relevant actions and generate the corresponding video, and may also notify game session 2 (228) which analyzes the situation and also generates a video.) Barak does not explicitly teach: a data stream comprising real-time sensitive data; a plurality of interaction commands associated with the real-time sensitive data. However, Burns teaches: a data stream comprising real-time sensitive data; – on lines in columns (Low latency communication channel 14 would be used to transmit real-time data, such as requested text updates or object manipulations, in addition to voice discussion relative to a particular video sequence.) a plurality of interaction commands associated with the real-time sensitive data – on lines in columns (For remote computing applications such as multi-player games, low latency communication channel 14 would be used to transmit commands and responses and to communicate with other players.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak with Burns to include a data stream comprising real-time sensitive data; a plurality of interaction commands associated with the real-time sensitive data, as taught by Burns, on lines 1-67 in columns 1-2 , to prevent significant delays between generation of information at one location and receipt of information at another location as such delays make various types of communication media and channels unacceptable for interactive applications, which impose constraints of real-time or near real-time responsiveness to be considered high quality. Combination of Barak and Burns does not explicitly teach: determining a network condition of the local gaming session, routing, based on the network condition, non real-time sensitive data at a lower priority than the real-time sensitive data. However, Rodbro teaches: determining a network condition of the local gaming session, – in paragraphs [0004]-[0044] (In step S306 a current transmission condition is determined. The current transmission condition describes the conditions in which the applications are currently accessing the network 112.) routing, based on the network condition, non real-time sensitive data at a lower priority than the real-time sensitive data. – in paragraphs [0004]-[0044] (In step S308 the BLC 204 dynamically adapts the bandwidth limitations of the applications according to the current transmission condition determined in step S306. When the network access is to be limited, stricter bandwidth limitations are applied to the non real-time applications 108 than to the real-time applications 106 since the non real-time applications 108 can cope with delays better than the real-time applications 106 can cope with delays. By lowering the QoS of the port, network routers in the network 100 will reduce priority for the packets sent via the port.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak and Burns with Rodbro to include determining a network condition of the local gaming session, routing, based on the network condition, non real-time sensitive data at a lower priority than the real-time sensitive data, as taught by Rodbro, in paragraphs [0001]-[0010], to serve high priority packets over lower priority ones, thus providing less queuing delay in the network for real-time data. Combination of Barak, Burns, and Rodbro does not explicitly teach: wherein the network condition is determined based on a delay between transmission of the data stream and receipt of a responsive interaction command from the at least one user device. However, Schrecke teaches: wherein the network condition is determined based on a delay between transmission of the data stream and receipt of a responsive interaction command from the at least one user device; and – in paragraphs [0010]-[0040] (As shown in block 302, the invention includes, for example by using time stamping, the transmit time within a traffic packet of interest and transmits the packet to a receiving participating node at the other end of the link, in block 304. The receiving node then immediately or after a predetermined amount of time sends a response to the transmitting node, upon receiving the transmitted packet, in block 306. In block 310, the invention the estimates the round trip delay as the difference between the transmit time and the time the response was received minus the processing time taking into account the predetermined amount of time as the round trip delay of the packet through the link. Processing time can be configured as a static value, assumed to be zero, or measured as part of the implementation depending on the accuracy desired.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, and Rodbro with Schrecke to include wherein the network condition is determined based on a delay between transmission of the data stream and receipt of a responsive interaction command from the at least one user device, as taught by Schrecke, in paragraphs [0001]-[0028], to provide a technique for indirect link characterization and link quality measurement of a digital network. Claim 14. Claims 14 is substantially similar to claims 1 and 10, except for the limitation: wherein the apparatus is nearest the at least one user device. Barak teaches: wherein the apparatus is nearest the at least one user device. – in paragraphs [0043]-[0047], Fig. 2 (A first player (not shown) is using end unit 1 (200) or a first console to connect to server 1 (204), and a second player (not shown) is using end unit 2 (220) or a second console to connect to server 2 (224). All the associated players and servers may be present at totally different locations, such as cities, countries or continents.) Claims 2, 11. The system of claim 1 – refer to the indicated claim for reference(s). Barak teaches: wherein the local gaming session comprises one or more of a video game, a video conference, or a presentation. – in paragraphs [0043]-[0047], Fig. 2 (Although the two players participate in the same game, two different instances are created, being game session 1 (208) and game session 2 (228), three servers are active in providing the game, and two video streams are created and sent to end unit or console 1 (200) and end unit or console 2 (220).) Claim 9. The system of claim 1 – refer to the indicated claim for reference(s). Barak teaches: wherein each server of the plurality of servers is associated with a different geographic location. – in paragraphs [0043]-[0047], Fig. 2 (A first player (not shown) is using end unit 1 (200) or a first console to connect to server 1 (204), and a second player (not shown) is using end unit 2 (220) or a second console to connect to server 2 (224). Server 1 (204) and server 2 (224) are part of a cloud computing system. Thus, all the associated players and servers may be present at totally different locations, such as cities, countries or continents.) Claim 15. The apparatus of claim 14 – refer to the indicated claim for reference(s). Barak teaches: wherein the processor executable instructions, when executed by the one or more processors, further cause the apparatus to associate a second data stream to a second user device, wherein the second data stream comprises information associated with the local gaming session. – in paragraphs [0043]-[0047], Fig. 2 (Gaming application 1 (212) and gaming application 2 (232) enable the players to play the game by providing access to game session 1 (208) and game session 2 (228), respectively. Game session 1 (208) and game session 2 (228) communicate through communication server 236 in order to provide notifications about users' actions and status. For example, game session 1 (208) may be notified about the first player pressing on a particular button, and may take the relevant actions and generate the corresponding video, and may also notify game session 2 (228) which analyzes the situation and also generates a video. Although the two players participate in the same game, two different instances are created, being game session 1 (208) and game session 2 (228), servers are active in providing the game, and two video streams are created and sent to end unit or console 1 (200) and end unit or console 2 (220).)) Claim 22. The system of claim 1 – refer to the indicated claim for reference(s). Barak teaches: wherein the real-time sensitive data comprises one or more of at least one interaction command or a result of the at least one interaction command. – in paragraphs [0043]-[0047], Fig. 2 (Game session 1 (208) and game session 2 (228) communicate through communication server 236 in order to provide notifications about users' actions and status. For example, game session 1 (208) may be notified about the first player pressing on a particular button, and may take the relevant actions and generate the corresponding video, and may also notify game session 2 (228) which analyzes the situation and also generates a video.) Claim(s) 3-7, 12, 16, 17, 19, 20, 25, and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), and Pedersen (US 20110276699). Claims 3, 17. The system of claim 1 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: wherein the at least one user device comprises one or more of a mobile device, a set-top box, or a smart device. However, Pedersen teaches: wherein the at least one user device comprises one or more of a mobile device, a set-top box, or a smart device. – in paragraph [0096] (the computing device 100 can be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile telephone, any other computer, or other form of computing or telecommunications device that is capable of communication and that has sufficient processor power and memory capacity to perform the operations described herein.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Pedersen to include wherein the at least one user device comprises one or more of a mobile device, a set-top box, or a smart device, as taught by Pedersen, in paragraph [0006], to assign different priority levels or quality of service levels to individual virtual channels within a remote session are needed to improve an end user's experience. Claims 25, 4, 19. The method of claim 10 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: further comprising: determining, for each interaction command of the plurality of interaction commands, a priority, wherein the priority comprises either a high priority or a low priority; and processing, based on the priority, high priority interaction commands prior to low priority interaction commands, wherein the high priority interaction commands comprise real-time interaction commands, and wherein the low priority interaction commands comprise non-time-sensitive interaction commands. However, Pedersen teaches: further comprising: determining, for each interaction command of the plurality of interaction commands, a priority, – in paragraph [0062] (Data assigned a high priority may be transmitted before data assigned a low priority.) wherein the priority comprises either a high priority or a low priority; and – in paragraph [0062] (Data assigned a high priority may be transmitted before data assigned a low priority.) processing, based on the priority, high priority interaction commands prior to low priority interaction commands, – in paragraph [0062] (Data assigned a high priority may be transmitted before data assigned a low priority.) wherein the high priority interaction commands comprise real-time interaction commands, and – in paragraph [0007] (A first transport layer connection can have a highest priority level and can transmit real-time information such as audio and video conferencing information.) wherein the low priority interaction commands comprise non-time-sensitive interaction commands. – in paragraph (Another transport layer connection can have a lower priority level and can transmit image data and image commands, while another TCP or UDP connection can have a still lower priority level and can transmit scanner data and drive mapping information.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Pedersen to include further comprising: determining, for each interaction command of the plurality of interaction commands, a priority, wherein the priority comprises either a high priority or a low priority; and processing, based on the priority, high priority interaction commands prior to low priority interaction commands, wherein the high priority interaction commands comprise real-time interaction commands, and wherein the low priority interaction commands comprise non-time-sensitive interaction commands, as taught by Pedersen, in paragraph [0006], to assign different priority levels or quality of service levels to individual virtual channels within a remote session are needed to improve an end user's experience. Claims 5, 12, 16. The system of claim 4 – refer to the indicated claim for reference(s). Pedersen teaches: wherein each server of the plurality of servers is further configured to: send the high priority interaction commands prior to the low priority interaction commands. – in paragraph [0062] (Data assigned a high priority may be transmitted before data assigned a low priority.) Claims 20, 6. The apparatus of claim 19 – refer to the indicated claim for reference(s). Pedersen teaches: wherein the high priority interaction command comprises a real-time interaction command and additional information, and – in paragraph [0007] (A first transport layer connection can have a highest priority level and can transmit real-time information such as audio and video conferencing information.) wherein the processor executable instructions, when executed by the one or more processors, further cause the apparatus to process the real-time interaction command prior to the additional information. – in paragraph [0007] (Another transport layer connection can have a lower priority level and can transmit image data and image commands, while another TCP or UDP connection can have a still lower priority level and can transmit scanner data and drive mapping information.) Claim 7. The method of claim 4 – refer to the indicated claim for reference(s). Rodbro teaches: wherein the low priority interaction commands comprise non-time-sensitive interaction commands. – in paragraphs [0004]-[0044] (In step S308 the BLC 204 dynamically adapts the bandwidth limitations of the applications according to the current transmission condition determined in step S306. When the network access is to be limited, stricter bandwidth limitations are applied to the non real-time applications 108 than to the real-time applications 106 since the non real-time applications 108 can cope with delays better than the real-time applications 106 can cope with delays. By lowering the QoS of the port, network routers in the network 100 will reduce priority for the packets sent via the port.) Claim 26. Claim 26 is substantially similar to claim 5. Claim(s) 23, 24, and 27-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), Pedersen (US 20110276699), and Chang (US 20050278642). Claim 23. The system of claim 4 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, Schrecke, and Pedersen does not explicitly teach: wherein the high priority interaction commands comprise at least one of moving a game character or avatar, or opening fire with an in-game weapon. However, Chang teaches: wherein the high priority interaction commands comprise at least one of moving a game character or avatar, or opening fire with an in-game weapon. – in paragraphs [0032], [0035] (The prioritizing of interactions (304) allows the collaborative server to further optimize the experience of users of all client devices. In the case of a combat game, the collaborative server might apply a high priority to interactions such as weapon and view interactions, and apply a relatively lower priority to speech interactions between players and rendering the background environment. Higher priority events are considered important to maintaining the level of interactivity of the application and therefore processed more readily than lower priority events and events not considered important to the overall interactivity or other function in the application.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, Schrecke, and Pedersen with Chang to include wherein the high priority interaction commands comprise at least one of moving a game character or avatar, or opening fire with an in-game weapon, as taught by Chang, in paragraph [0002], to create effective collaborative environments for client devices with widely varying operational characteristics. Claim 24. The system of claim 4 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, Schrecke, and Pedersen does not explicitly teach: wherein the low priority interaction commands comprise at least one of changing a background pattern of a gaming program, or changing a display color of a gaming character. However, Chang teaches: wherein the low priority interaction commands comprise at least one of changing a background pattern of a gaming program, or changing a display color of a gaming character. – in paragraphs [0032], [0035] (The prioritizing of interactions (304) allows the collaborative server to further optimize the experience of users of all client devices. In the case of a combat game, the collaborative server might apply a high priority to interactions such as weapon and view interactions, and apply a relatively lower priority to speech interactions between players and rendering the background environment. Higher priority events are considered important to maintaining the level of interactivity of the application and therefore processed more readily than lower priority events and events not considered important to the overall interactivity or other function in the application.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, Schrecke, and Pedersen with Chang to include wherein the low priority interaction commands comprise at least one of changing a background pattern of a gaming program, or changing a display color of a gaming character, as taught by Chang, in paragraph [0002], to create effective collaborative environments for client devices with widely varying operational characteristics. Claim 27. Claim 27 is substantially similar to claim 23. Claim 28. Claim 28 is substantially similar to claim 24. Claim 29. Claim 29 is substantially similar to claim 23. Claim 30. Claim 30 is substantially similar to claim 24. Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), Craig (US 20070009029), and Chang (US 20050278642). Claim 8. The system of claim 1 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: wherein each server of the plurality of servers is located at a headend. However, Craig teaches: wherein each server of the plurality of servers is located at a headend. – in paragraph [0040] (The application server 114 and the plurality of game servers 116 may be located at a cable television system headend.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Craig to include wherein each server of the plurality of servers is located at a headend as taught by Craig, in paragraph [0001], to provide an interactive video-game system in which low latency is maintained despite a limited bandwidth connection between a client device and a remotely located video-game system. Combination of Barak, Burns, Rodbro, Schrecke, and Craig does not explicitly teach: wherein the high priority interaction commands comprise at least one of moving a game character or avatar, or opening fire with an in-game weapon. However, Chang teaches: wherein the high priority interaction commands comprise at least one of moving a game character or avatar, or opening fire with an in-game weapon. – in paragraphs [0032], [0035] (The prioritizing of interactions (304) allows the collaborative server to further optimize the experience of users of all client devices. In the case of a combat game, the collaborative server might apply a high priority to interactions such as weapon and view interactions, and apply a relatively lower priority to speech interactions between players and rendering the background environment. Higher priority events are considered important to maintaining the level of interactivity of the application and therefore processed more readily than lower priority events and events not considered important to the overall interactivity or other function in the application.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, Schrecke, and Craig with Chang to include wherein the high priority interaction commands comprise at least one of moving a game character or avatar, or opening fire with an in-game weapon, as taught by Chang, in paragraph [0002], to create effective collaborative environments for client devices with widely varying operational characteristics. Claim(s) 31, 33, 34, 36, 37, and 39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), and Dillon (US 20130322255). Claims 31, 34, 37. The system of claim 1 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: wherein the network condition is latency. However, Dillon teaches: wherein the network condition is latency. – in paragraph [0036] (Systems and methods for providing active quality of service (QOS) for application data transmissions over conventional broadband networks, based upon determined latency parameters, are disclosed.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Dillon to include wherein the network condition is latency, as taught by Dillon, in paragraph [0008], to provide an approach that achieves improved network performance (e.g., latency, jitter, throughput) through ordinary-grade (e.g., consumer-grade) broadband connections over conventional broadband networks, facilitating support of application-level quality of service traffic requirements (e.g., traffic requirements of real-time service applications, such as voice-over-IP (VOIP) services) through such ordinary-grade broadband connections over conventional broadband networks. Claims 33, 36, 39. The system of claim 1 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: wherein the system further comprises at least one second user device and wherein the system is further configured to prioritize the one or more interaction commands over other traffic so as to standardize latency between the at least one user device and the at least one second user device. However, Dillon teaches: wherein the system further comprises at least one second user device and wherein the system is further configured to prioritize the one or more interaction commands over other traffic so as to standardize latency between the at least one user device and the at least one second user device. – in paragraph [0092] (The TELQO functionality: (1) dynamically monitors the loading of the broadband connection and controls the traffic rate to avoid overflowing the connection with the result that the broadband connection provides a consistent low latency for data, including control the traffic flow over split tunnel 502 from the public network (e.g., Internet sites 523, 524, 525); (2) classifies and prioritizes traffic so that VOIP and latency sensitive applications are given preference over Bulk-Transfer traffic (e.g., even when the broadband is saturated), such as to promote a relatively reliable VOIP transport, and a relatively consistent and improved responsiveness; and (3) allocates bandwidth so that, when offered traffic exceeds available capacity, the lower priority traffic (e.g., guest WiFi traffic) can be restricted to a configurable percentage of the broadband capacity of the one or more tunnels of the network 500a.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Dillon to include wherein the system further comprises at least one second user device and wherein the system is further configured to prioritize the one or more interaction commands over other traffic so as to standardize latency between the at least one user device and the at least one second user device, as taught by Dillon, in paragraph [0008], to provide an approach that achieves improved network performance (e.g., latency, jitter, throughput) through ordinary-grade (e.g., consumer-grade) broadband connections over conventional broadband networks, facilitating support of application-level quality of service traffic requirements (e.g., traffic requirements of real-time service applications, such as voice-over-IP (VOIP) services) through such ordinary-grade broadband connections over conventional broadband networks. Claim(s) 32, 35, and 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), and Guo (US 7526564). Claims 32, 35, 38. The system of claim 1 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: wherein the network condition is a number of interaction commands processed at a given time. However, Guo teaches: wherein the network condition is a number of interaction commands processed at a given time. – on lines 65-67 in column 12 (It proves valuable to consider the following performance indices: Network load: The network load is given by the number of bytes that are transmitted per time unit.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Guo to include wherein the network condition is a number of interaction commands processed at a given time, as taught by Guo, on lines 42-59 in column 1, to provide a new architecture and operational techniques for supporting high quality live and on-demand streaming multimedia on a data network. Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), and Zhu (US 8792876). Claim 13. The method of claim 10 – refer to the indicated claim for reference(s). Rodbro teaches: wherein routing the non real-time sensitive data comprises sending the non real-time sensitive data via a network connection. – in paragraphs [0004]-[0044] (In step S308 the BLC 204 dynamically adapts the bandwidth limitations of the applications according to the current transmission condition determined in step S306. When the network access is to be limited, stricter bandwidth limitations are applied to the non real-time applications 108 than to the real-time applications 106 since the non real-time applications 108 can cope with delays better than the real-time applications 106 can cope with delays. By lowering the QoS of the port, network routers in the network 100 will reduce priority for the packets sent via the port.) Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: wherein the network connection is a high-latency network connection. However, Zhu teaches: wherein the network connection is a high-latency network connection – on lines 48-65 in column 2 (The other traffic separation mechanism is based on per-service-flow. If the service flow is for voice traffic, it can be routed to the low latency network and other data traffic can be routed to the high latency network. The third traffic separation can be through a VLAN ID from the AAA server for the R3 traffic.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Zhu to include wherein the network connection is a high-latency network connection, as taught by Zhu, on lines 65-67 in column 1, to provide network element that defines one or more quality of service attributes for the endpoint. Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), and Monteiro (US 7228359). Claim 21. The method of claim 10 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: further comprising: receiving, from the at least one user device, a request to participate in the local gaming session, wherein the request comprises an identifier of the at least one user device; and determining, based on the identifier, a location of the at least one user device and the server of the plurality of servers. However, Monteiro teaches: further comprising: receiving, from the at least one user device, a request to participate in the local gaming session, – on lines 53-64 in column 1 (The domain name section of DNS requests can be modified to include embedded client identifiers.) wherein the request comprises an identifier of the at least one user device; and – on lines 53-64 in column 1 (The domain name section of DNS requests can be modified to include embedded client identifiers.) determining, based on the identifier, a location of the at least one user device and the server of the plurality of servers. – on lines 53-64 in column 1 (The domain name section of DNS requests can be modified to include embedded client identifiers. Accordingly, when there are multiple content servers that are capable of providing content to a client, a DNS server (e.g., a content router) can select the content server which is closest to the client using the client identifier which identifies the client.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Monteiro to include further comprising: receiving, from the at least one user device, a request to participate in the local gaming session, wherein the request comprises an identifier of the at least one user device; and determining, based on the identifier, a location of the at least one user device and the server of the plurality of servers, as taught by Monteiro, on lines 25-36 in column 4, to provide domain name service (DNS) based on a client identifier that identifies a client. For example, when there are multiple content servers that are capable of providing content to a client, a DNS server can select the content server which is closest to the client using the client identifier which identifies the client. Such content routing based on the client identifier provides improved accuracy over a conventional approach of selecting the content server which is closest to a DNS proxy in which the client may be far away from the DNS proxy. Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Barak (US 20150174478) in view of Burns (US 5995518), and further in view of Rodbro (US 20110312283), Schrecke (US 20140328205), and Perrin (US 20150156278). Claim 18. The apparatus of claim 14 – refer to the indicated claim for reference(s). Combination of Barak, Burns, Rodbro, and Schrecke does not explicitly teach: wherein the processor executable instructions, when executed by the one or more processors, further cause the apparatus to cause, the at least one user device to display the rendered video content. However, Perrin teaches: wherein the processor executable instructions, when executed by the one or more processors, further cause the apparatus to cause, the at least one user device to display the rendered video content. – in paragraphs [0139]-[0231], [0270], [0289], and Fig. 1 (The rendering server 100 is configured for rendering game screens for the client devices 300a to 300e, based on commands/instructions received from the central server 200. These commands can be transmitted from the central server 200 to the rendering server 100 in the form of packets 40 over the network 450. Output signals 30 containing the rendered game screens are distributed by the rendering server 100 to the client devices 300 over the network 400, such as the Internet.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, Rodbro, and Schrecke with Perrin to include wherein the processor executable instructions, when executed by the one or more processors, further cause the apparatus to cause, the at least one user device to display the rendered video content, as taught by Perrin, in paragraphs [0001] and [0006], to provide an approach for efficient usage of network resources, particularly bandwidth, when remotely executing rendering commands. REMARKS Applicant has presented amendments to the claims. The examiner maintains the rejections, see remarks below. Argument 1: The applicant argues that the rejections under 35 U.S.C. 112, first paragraph, are improper. In response, the examiner respectfully submits: However, the rejections are proper. Claims 1-39 is/are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1, 10, and 14 recite “determine a network condition of the local gaming session,” which is not disclosed by the applicant’s specification. The applicant’s specification neither mentions the concept of determining a network condition nor determining a network condition of the local gaming session. These concepts are not present in the paragraphs mentioned in the applicant’s remarks. Claims 1, 10, and 14 recite “route, based on the network condition, non real-time sensitive …,” which is not disclosed by the applicant’s specification. The applicant’s specification neither mentions the concept of route based on the network condition nor route, based on the network condition, non real-time sensitive. These concepts are not present in the paragraphs mentioned in the applicant’s remarks. Claim 13 recites “wherein routing the non real-time sensitive data comprises sending the non real-time sensitive data via a high-latency network connection,” which is not disclosed by the applicant’s specification. The applicant’s specification neither mentions the concept of routing the non real-time sensitive data nor sending the non real-time sensitive data via a high-latency network connection. These concepts are not present in the paragraphs mentioned in the applicant’s remarks. Claims 32, 35, 38 recite “wherein the network condition is a number of interaction commands processed at a given time,” which is not disclosed by the applicant’s specification. The applicant’s specification does not mention the concept of the network condition is a number of interaction commands processed at a given time. This concept is not present in the paragraphs mentioned in the applicant’s remarks. Claims 33, 36, 39 recite “wherein the system further comprises at least one second user device and wherein the system is further configured to prioritize the one or more interaction commands over other traffic so as to match latencies between the at least one user device and the at least one second user device,” which is not disclosed by the applicant’s specification. The applicant’s specification neither mentions the concept of prioritize the one or more interaction commands over other traffic nor prioritize the one or more interaction commands over other traffic so as to match latencies between the at least one user device and the at least one second user device. These concepts are not present in the paragraphs mentioned in the applicant’s remarks. Argument 2: The applicant argues that the rejection under 35 U.S.C. 112, second paragraph, is improper. In response, the examiner respectfully submits: However, the rejection under 35 U.S.C. 112, second paragraph, is proper. Claims 1-39 is/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 limitation “Claim 1. … each server of the plurality of servers is configured to: send, via a local gaming session, to at least one user device participating in the local gaming session, by a server of the plurality of servers nearest to the at least one user device, a data stream comprising gaming data; receive, via the local gaming session, from the at least one user device, one or more interaction commands associated with the gaming data; determine a network condition of the local gaming session …; and route, based on the network condition non real-time sensitive data …; and the at least one user device, configured to: send, via the local gaming session, the one or more interaction commands to the server of the plurality of servers. Claim 4. … each server of the plurality of servers is further configured to: determine, for each interaction command of the one or more interaction commands, a priority, wherein the priority comprises either a high priority or a low priority; and process, based on the priority, high priority interaction commands prior to low priority interaction commands. Claim 5. … each server of the plurality of servers is further configured to: send the high priority interaction commands prior to the low priority interaction commands. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. There is insufficient disclosure of the corresponding structure, material, or acts for performing the entire claimed function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Argument 3: The applicant argues that the rejection under 35 U.S.C. 103 is improper. In response, the examiner respectfully submits: However, the rejection under 35 U.S.C. 103 is proper. Barak teaches: sending, via a local gaming session, by a server of a plurality of servers nearest at least one user device participating in the local gaming session, to the at least one user device, – in paragraphs [0043]-[0047], Fig. 2 (A first player (not shown) is using end unit 1 (200) or a first console to connect to server 1 (204), and a second player (not shown) is using end unit 2 (220) or a second console to connect to server 2 (224). Server 1 (204) and server 2 (224) are part of a cloud computing system. Thus, all the associated players and servers may be present at totally different locations, such as cities, countries or continents. Server 1 (204) which may be implemented as any computing platform is executing gaming application 1 (212), which serves as a "wrapper" for, or communicates with game session 1 (208) which executes the specific game selected by the players. Similarly, server 2 (224) is executing gaming application 2 (232), which serves as a "wrapper" to, or communicates with game session 2 (228). Gaming application 1 (212) and gaming application 2 (232) enable the players to play the game by providing access to game session 1 (208) and game session 2 (228), respectively. Game session 1 (208) and game session 2 (228) communicate through communication server 236 in order to provide notifications about users' actions and status. For example, game session 1 (208) may be notified about the first player pressing on a particular button, and may take the relevant actions and generate the corresponding video, and may also notify game session 2 (228) which analyzes the situation and also generates a video.) a data stream comprising real-time sensitive data; – in paragraphs [0043]-[0047], Fig. 2 (Although the two players participate in the same game, two different instances are created, being game session 1 (208) and game session 2 (228), servers are active in providing the game, and two video streams are created and sent to end unit or console 1 (200) and end unit or console 2 (220).) receiving, by the server of the plurality of servers via the local gaming session, a plurality of interaction commands associated with the real-time sensitive data from the at least one user device; – in paragraphs [0043]-[0047], Fig. 2 (Server 1 (204) which may be implemented as any computing platform is executing gaming application 1 (212), which serves as a "wrapper" for, or communicates with game session 1 (208) which executes the specific game selected by the players. Similarly, server 2 (224) is executing gaming application 2 (232), which serves as a "wrapper" to, or communicates with game session 2 (228). Game session 1 (208) and game session 2 (228) communicate through communication server 236 in order to provide notifications about users' actions and status. For example, game session 1 (208) may be notified about the first player pressing on a particular button, and may take the relevant actions and generate the corresponding video, and may also notify game session 2 (228) which analyzes the situation and also generates a video.) Barak does not explicitly teach: a data stream comprising real-time sensitive data; a plurality of interaction commands associated with the real-time sensitive data. However, Burns teaches: a data stream comprising real-time sensitive data; – on lines in columns (Low latency communication channel 14 would be used to transmit real-time data, such as requested text updates or object manipulations, in addition to voice discussion relative to a particular video sequence.) a plurality of interaction commands associated with the real-time sensitive data – on lines in columns (For remote computing applications such as multi-player games, low latency communication channel 14 would be used to transmit commands and responses and to communicate with other players.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak with Burns to include a data stream comprising real-time sensitive data; a plurality of interaction commands associated with the real-time sensitive data, as taught by Burns, on lines 1-67 in columns 1-2 , to prevent significant delays between generation of information at one location and receipt of information at another location as such delays make various types of communication media and channels unacceptable for interactive applications, which impose constraints of real-time or near real-time responsiveness to be considered high quality. Combination of Barak and Burns does not explicitly teach: determining a network condition of the local gaming session, routing, based on the network condition, non real-time sensitive data at a lower priority than the real-time sensitive data. However, Rodbro teaches: determining a network condition of the local gaming session, – in paragraphs [0004]-[0044] (In step S306 a current transmission condition is determined. The current transmission condition describes the conditions in which the applications are currently accessing the network 112.) routing, based on the network condition, non real-time sensitive data at a lower priority than the real-time sensitive data. – in paragraphs [0004]-[0044] (In step S308 the BLC 204 dynamically adapts the bandwidth limitations of the applications according to the current transmission condition determined in step S306. When the network access is to be limited, stricter bandwidth limitations are applied to the non real-time applications 108 than to the real-time applications 106 since the non real-time applications 108 can cope with delays better than the real-time applications 106 can cope with delays. By lowering the QoS of the port, network routers in the network 100 will reduce priority for the packets sent via the port.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak and Burns with Rodbro to include determining a network condition of the local gaming session, routing, based on the network condition, non real-time sensitive data at a lower priority than the real-time sensitive data, as taught by Rodbro, in paragraphs [0001]-[0010], to serve high priority packets over lower priority ones, thus providing less queuing delay in the network for real-time data. Combination of Barak, Burns, and Rodbro does not explicitly teach: wherein the network condition is determined based on a delay between transmission of the data stream and receipt of a responsive interaction command from the at least one user device. However, Schrecke teaches: wherein the network condition is determined based on a delay between transmission of the data stream and receipt of a responsive interaction command from the at least one user device; and – in paragraphs [0010]-[0040] (As shown in block 302, the invention includes, for example by using time stamping, the transmit time within a traffic packet of interest and transmits the packet to a receiving participating node at the other end of the link, in block 304. The receiving node then immediately or after a predetermined amount of time sends a response to the transmitting node, upon receiving the transmitted packet, in block 306. In block 310, the invention the estimates the round trip delay as the difference between the transmit time and the time the response was received minus the processing time taking into account the predetermined amount of time as the round trip delay of the packet through the link. Processing time can be configured as a static value, assumed to be zero, or measured as part of the implementation depending on the accuracy desired.) It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Barak, Burns, and Rodbro with Schrecke to include wherein the network condition is determined based on a delay between transmission of the data stream and receipt of a responsive interaction command from the at least one user device, as taught by Schrecke, in paragraphs [0001]-[0028], to provide a technique for indirect link characterization and link quality measurement of a digital network. Conclusion THIS ACTION IS MADE FINAL. 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 MUHAMMAD RAZA whose telephone number is (571)272-7734. The examiner can normally be reached Monday-Friday, 7:00 A.M.-5:00 P.M.. 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, Vivek Srivastava can be reached on (571)272-7304. 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. /MUHAMMAD RAZA/Primary Examiner, Art Unit 2449
Read full office action

Prosecution Timeline

Jul 03, 2014
Application Filed
Apr 18, 2016
Non-Final Rejection — §103, §112
Aug 09, 2016
Applicant Interview (Telephonic)
Sep 06, 2016
Response Filed
Dec 12, 2016
Final Rejection — §103, §112
Feb 21, 2017
Request for Continued Examination
Feb 24, 2017
Response after Non-Final Action
Apr 30, 2017
Non-Final Rejection — §103, §112
Aug 08, 2017
Response Filed
Oct 30, 2017
Final Rejection — §103, §112
Jan 02, 2018
Response after Non-Final Action
Mar 01, 2018
Notice of Allowance
May 01, 2018
Response after Non-Final Action
May 12, 2018
Response after Non-Final Action
Jul 27, 2018
Non-Final Rejection — §103, §112
Feb 06, 2019
Applicant Interview
Feb 06, 2019
Applicant Interview (Telephonic)
Feb 07, 2019
Response Filed
May 28, 2019
Final Rejection — §103, §112
Sep 03, 2019
Request for Continued Examination
Sep 06, 2019
Response after Non-Final Action
Oct 08, 2019
Examiner Interview (Telephonic)
Jan 18, 2020
Non-Final Rejection — §103, §112
Jul 23, 2020
Response Filed
Oct 05, 2020
Examiner Interview (Telephonic)
Oct 24, 2020
Non-Final Rejection — §103, §112
Mar 01, 2021
Response after Non-Final Action
Mar 01, 2021
Notice of Allowance
Mar 30, 2021
Response after Non-Final Action
Oct 06, 2021
Response after Non-Final Action
Oct 06, 2021
Response after Non-Final Action
Oct 07, 2021
Response after Non-Final Action
Oct 13, 2021
Response after Non-Final Action
Nov 09, 2021
Response after Non-Final Action
Jan 19, 2022
Response after Non-Final Action
Apr 23, 2022
Response after Non-Final Action
Sep 13, 2022
Response after Non-Final Action
Sep 14, 2022
Response after Non-Final Action
Sep 15, 2022
Response after Non-Final Action
Sep 15, 2022
Response after Non-Final Action
May 30, 2023
Response after Non-Final Action
Aug 03, 2023
Request for Continued Examination
Aug 05, 2023
Response after Non-Final Action
May 08, 2024
Non-Final Rejection — §103, §112
Nov 13, 2024
Response Filed
Mar 06, 2025
Final Rejection — §103, §112
Jul 14, 2025
Request for Continued Examination
Jul 18, 2025
Response after Non-Final Action
Nov 22, 2025
Non-Final Rejection — §103, §112
Feb 26, 2026
Response Filed
Mar 16, 2026
Final Rejection — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12603935
WORKFLOW COORDINATION IN COORDINATION NAMESPACE
2y 5m to grant Granted Apr 14, 2026
Patent 12598147
COLLABORATIVE RELATIONAL MANAGEMENT OF NETWORK AND CLOUD-BASED RESOURCES
2y 5m to grant Granted Apr 07, 2026
Patent 12592917
NETWORK LINK ESTABLISHMENT IN A MULTI-CLOUD INFRASTRUCTURE
2y 5m to grant Granted Mar 31, 2026
Patent 12587451
AUTOMATING SECURED DEPLOYMENT OF CONTAINERIZED WORKLOADS ON EDGE DEVICES
2y 5m to grant Granted Mar 24, 2026
Patent 12580978
APPLICATION-CENTRIC WEB PROTOCOL-BASED DATA STORAGE
2y 5m to grant Granted Mar 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

13-14
Expected OA Rounds
58%
Grant Probability
99%
With Interview (+70.8%)
3y 6m
Median Time to Grant
High
PTA Risk
Based on 274 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month