Prosecution Insights
Last updated: April 19, 2026
Application No. 18/749,515

SYSTEMS AND METHODS FOR TIERED SYNCHRONIZATION

Final Rejection §103
Filed
Jun 20, 2024
Examiner
FILIPCZYK, MARCIN R
Art Unit
2153
Tech Center
2100 — Computer Architecture & Software
Assignee
Mongodb Inc.
OA Round
2 (Final)
65%
Grant Probability
Moderate
3-4
OA Rounds
3y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 65% of resolved cases
65%
Career Allow Rate
289 granted / 447 resolved
+9.7% vs TC avg
Strong +37% interview lift
Without
With
+37.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
29 currently pending
Career history
476
Total Applications
across all art units

Statute-Specific Performance

§101
12.9%
-27.1% vs TC avg
§103
31.3%
-8.7% vs TC avg
§102
35.6%
-4.4% vs TC avg
§112
6.9%
-33.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 447 resolved cases

Office Action

§103
Response to Amendment 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 . This action is responsive to application filed on 10/16/25. Claims 1-21 are pending. Abstract Idea Analysis: Claims 1 and 11 are found statutory and compliant. The claimed subject matter discloses providing access to a mid-tier server over a local network in a cloud-tier server system and synchronizing by the mid-tier server data with the cloud-tier server over the internet. This concept integrates the functionality of the mid-tier server into a practical application of cloud computing. 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-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jain et al (USPN. 2024/0007414) in view of Garg et al (USPN. 2024/0086567) further in view of Sharma et al (USPN. 2017/0177613). Regarding claims 1 and 11, Jain teaches a tiered database synchronization system and method, comprising (fig. 1): a cloud-tier server comprising a cloud-tier database (figs. A1, A2, A3, and F3 (cloud data center A130); and a mid-tier server comprising a mid-tier database storing mid-tier data corresponding to a subset of cloud-tier data stored in the mid-tier server configured to (figs. A1, A2, A3, and F3 Edge Cloud Node/Intermediate network node, pars. 103 and 181, Edge cloud A110 and A340 ): provide access to the mid-tier data stored in the mid-tier database to one or more clients over a local network (figs. A1, A2, A3, and F3, pars. 181, Edge cloud over LAN), but Jain does not explicitly teach flexible schema data structures. However, Garg teaches schema modification system providing flexible schema data structures (pars. 72-73, “ the schema modification system 102 adapts or modifies a payload schema based on detecting a change to a source network component and/or a target network component. In particular, the schema modification system 102 can receive or identify a modified payload schema to adjust for a version update to a source network component and/or a version update to a target network component”, Garg). It would have been obvious to one of ordinary skill in the art at the effective filing date to integrate Garg’s schema modification into Jain cloud system (fig. A1, items A120 and A130, Jain). One would have been motivated to integrate schema modification in Jain cloud system to manage different type of data sources in edge computing (fig. A2, vehicles, heathcare and edge cloud data handling, Jain). Jain in view of Garg combined teach providing the flexible schema data structures in response to flexible schema data operations executed locally by the one or more clients on the flexible schema data structures (figs. A1, A2, A3, and F3, pars. 181, Edge cloud over LAN, modified Jain and pars. 72-73, flexible schema is utilized based on local and target changes/executions, Garg); and, Synchronize the flexible schema data structures of the mid tier data with the corresponding subset of the cloud tier data stored in the cloud tier database of the cloud-tier server over the Internet (figs. A1, A2, A3, and F3, pars. 181-182, and 290, items F300 and F304, share/communicate between devices, cloud and nodes using modified Jain). In the case where synchronization is not explicitly synchronizing data, Sharma teaches synchronizing data between local and remote cloud systems (figs. 1 and 2, local clouds 104 and 106, remote cloud 102 and synchronizing data 108, par. 56, synchronizing local files, Sharma). It would have been obvious to one of ordinary skill in the art at the effective filing date to synchronize collected Jain Edge Cloud A110 data in view of Sharma (fig. 1, item 108, Sharma) by synchronizing/managing the local Edge cloud data collected (fig. A2, item A110 and A205, pars. 97, 100 and 101, Nodes facilitate or use Edge cloud A110, and aggregation, Jain). One would have been motivated to synchronize all data created to create a network Hub of all created data and devices (fig. A2, devices A205 and Hub A225, Jain). Claims 2 and 12. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is configured to synchronize the mid-tier data with the cloud-tier data when (figs. A1, A2, A3, and F3 (cloud data center A130 and edge cloud A110, Jain): the mid-tier data is modified by the one or more clients, and the mid-tier server detects the modification over the local network and the mid-tier data is modified at the cloud-tier server, and the mid-tier server detects the modification over the Internet (pars. 89 and 91, Edge cloud A110 provide ultra low latency response times for services and functions used by data sources A160 and reduce network backhaul traffic, note that requested context and updates are exchanged, see pars. 103-104, Jain). Claims 3 and 13. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is configured to (figs. A1, A2, A3, and F3, Jain): provide, to the one or more clients, access to the mid-tier data (figs. A1, A2, A3, and F3, pars. 181, Edge cloud, loT devices in communication with each other over LAN with Server F330, Jain) in response to flexible schema data operations executed locally by the one or more client on the flexible schema data structures (pars. 72-73, “ the schema modification system 102 adapts or modifies a payload schema based on detecting a change to a source network component and/or a target network component, Garg); and request, from the cloud-tier database, access to data stored in the cloud-tier database that is not stored in the non-relational portion of the mid-tier database (par. 181, “server F330 to facilitate communication with the cloud F300”, Jain). Claims 4 and 14. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is further configured to, while the mid-tier server is disconnected from the cloud-tier server: update the mid-tier data when modified by a first client and provide updated mid-tier data to a second client (pars. 214 and 217, servers are in communication with network 1110, and are used for “commercial transaction” such as a payment, note that the server is handling the client transaction without the cloud data center and provides “updates” to the end users, such as sale confirmation to buyer and seller, Jain). Claims 5 and 15. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is further configured to, when the mid-tier server is reconnected to the cloud-tier server after being disconnected from the cloud-tier server, update the subset of cloud-tier data based on the updated mid-tier data (fig. A3, par. 103, “Edge cloud A110 are connected to a cloud or data center A360, which uses a backhaul network A350 to fulfill higher latency requests from a cloud/data center for websites, application database servers. LoT devices and servers are updated when requested context and updates are exchanged, see pars. 103-104, Jain). Claims 6 and 16. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is physically located in a location with intermittent access to the Internet (fig. A3 and F1, pars. 159-160 and 162-164, loT networks connected to network Internet with wired and wireless technologies, wireless comprise intermittent connection). Claims 7 and 17. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is configured to (figs. A1, A2, A3, and F3): receive, from a first client over the local network, a first changeset that is representative of a flexible schema data operation on a data object in the mid-tier database performed by the first client (fig. A2, A205 data from Healthcare/vehicles, modified Jain); receive, from a second client over the local network, a second changeset that is representative of a flexible schema data operation on the data object performed by the second client (fig. A2, A205 data from Healthcare/vehicles concerning other users, modified Jain); and in response to receiving, from the first client over the local network, a synchronization request for synchronizing the first client at least with the second client, transmit, to the first client over the local network, the second changeset, wherein the first client is configured to merge the first changeset and the second changeset to update the data object (fig. 1 sync 108, and relevant text, Sharma). Claims 8 and 18. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 7, wherein the mid-tier server is further configured to (figs. A1, A2, A3, and F3): receive, from the cloud-tier server over the Internet, a third changeset that is representative of a flexible schema data operation on a version of the data object in the cloud-tier database performed by a client that is not connected over the local network (fig. A2, A205 data from Healthcare/vehicles concerning further other users, modified Jain); and in response to receiving the synchronization request from the first client over the local network, further transmit, to the first client over the local network, the third changeset, wherein the first client is further configured to merge the first changeset and the second changeset with the third changeset (fig. 1 sync 108 all local changes from plurality of local clouds of Jain in view of Sharma, see also relevant text, Sharma). Claims 9 and 19. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is configured to (figs. A1, A2, A3, and F3, Jain): act as a client of the cloud-tier server over the Internet (A110, A120 acts as a client to A130, Jain); act as a server for the one or more clients over the local network (A110, A120 act as a server to A161-A167, pars. 103 and 181, Edge cloud server, Jain). Claims 10 and 20. Jain/Garg/Sharma combined teach tiered database synchronization system of claim 1, wherein the mid-tier server is configured to periodically check an Internet connection and, in response to detecting that the mid-tier server is connected to the cloud-tier server over the Internet, synchronize data with the cloud-tier server over the Internet (figs. F1 and F3, pars. 163-164 and 181, the IoTs detect mid-tier gateway F310 as an intermediate network node and connect, Jain, in modified by Sharma further teaches synchronize data over the cloud, pars. 137 and 141, Sharma). Claim 21. Jain/Garg/Sharma combined teach wherein the flexible schema data structures comprise documents organized in collections of the mid tier data, the documents comprising attribute value pairs (pars. 509 and 518, structure data of dataset size, hardware and operator comprise next level attributes that are normalized for re-use, Jain, and par. 50, flexible schema pair data is processed, Garg). Response to Arguments Applicant’s arguments filed on 10/16/25 with respect to claim(s) 1-21 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. Please refer to the new ground rejection for teachings of the amended subject matter. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure in the field of local servers and clouds: USPN. 20190319793: pars. 59 and 119, fig. 10, servers, cloud network 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 MARCIN R FILIPCZYK whose telephone number is (571)272-4019. The examiner can normally be reached M-F 7-4 EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached at 571-272-8352. 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. January 21, 2026 /MARCIN R FILIPCZYK/Primary Examiner, Art Unit 2153
Read full office action

Prosecution Timeline

Jun 20, 2024
Application Filed
Jun 12, 2025
Non-Final Rejection — §103
Oct 14, 2025
Applicant Interview (Telephonic)
Oct 14, 2025
Examiner Interview Summary
Oct 16, 2025
Response Filed
Jan 21, 2026
Final Rejection — §103
Mar 30, 2026
Examiner Interview Summary
Mar 30, 2026
Applicant Interview (Telephonic)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602724
DUAL LEDGER SYNCING
2y 5m to grant Granted Apr 14, 2026
Patent 12585712
ADVERSARIAL BANDITS POLICY FOR CRAWLING HIGHLY DYNAMIC CONTENT
2y 5m to grant Granted Mar 24, 2026
Patent 12566737
DATA QUALITY SOLUTION USING EDGE COMPUTING AND BLOCKCHAIN TECHNOLOGY
2y 5m to grant Granted Mar 03, 2026
Patent 12561381
TIME AND CLICK BASED UPDATABLE STATIC WEB PAGE RANKING
2y 5m to grant Granted Feb 24, 2026
Patent 12554764
METHODS AND SYSTEMS FOR OPTIMIZING DISPLAY OF USER CONTENT
2y 5m to grant Granted Feb 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

3-4
Expected OA Rounds
65%
Grant Probability
99%
With Interview (+37.2%)
3y 6m
Median Time to Grant
Moderate
PTA Risk
Based on 447 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