Prosecution Insights
Last updated: April 19, 2026
Application No. 18/735,479

COMPLIANT DATA MANAGEMENT FOR CUSTOM OBJECTS

Non-Final OA §103
Filed
Jun 06, 2024
Examiner
VUONG, CAO DANG
Art Unit
2153
Tech Center
2100 — Computer Architecture & Software
Assignee
SAP SE
OA Round
3 (Non-Final)
68%
Grant Probability
Favorable
3-4
OA Rounds
3y 4m
To Grant
94%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allow Rate
74 granted / 109 resolved
+12.9% vs TC avg
Strong +26% interview lift
Without
With
+26.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 4m
Avg Prosecution
21 currently pending
Career history
130
Total Applications
across all art units

Statute-Specific Performance

§101
13.9%
-26.1% vs TC avg
§103
60.1%
+20.1% vs TC avg
§102
12.6%
-27.4% vs TC avg
§112
8.5%
-31.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 109 resolved cases

Office Action

§103
DETAILED ACTION 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 Non-Final Office Action is in response to the application 18/735,479 filed on 01/08/2026. Status of Claims: Claims 1, 5, 10, 14, and 19 are amended in this Office Action. Claims 2, 4, 11, 13, and 20 are canceled in this Office Action. Claims 21-23 are new in this Office Action. Claims 1, 3, 5-10, 12, 14-19, and 21-23 are pending in this Office Action. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/08/2026 has been entered. Response to Arguments After closely reviewing the Applicant’s arguments filed in the remarks filed 01/08/2026 (pages 7-11) regarding to claims 1, 10 and 19, the Examiner respectfully submits that the arguments are not persuasive. Regarding claims 1, 10 and 19: The applicant argued that the prior arts of record do not teach “wherein the data destruction object is linked to the custom object using a first user interface”. The examiner respectfully disagrees with the Applicant; the Examiner respectfully submits that Shah discloses “[0047] In alternative embodiments, process 200 allows or enables a user to optionally cancel the pending in step 250. As such, the deletion of the LUN by the storage management controller 120 (step 260) may be configured as automatic or requiring a user to approve the scheduled deletion.”. The system of Shah is directed to deleting data according to a created profile with self-destruction properties. Also, the system incorporates user’s involvement in the deleting process such as cancel or approve the deletion process. Although Shah does not explicitly disclose “a first user interface”, one of ordinary skills in the art can understand that user’s interactions such as canceling and approving deletion of data with respective profiles can correspond to a first user interface in an environment with data destruction object and custom object. Therefore, Shah at least teaches “wherein the data destruction object is linked to the custom object using a first user interface”. The applicant argued that the prior arts of record do not teach “wherein the information lifecycle management object is linked to the data destruction object using a second user interface”. The examiner respectfully disagrees with the Applicant; the Examiner respectfully submits that Shah discloses “[0045] Once the LUN has been provisioned, the storage management controller 120 creates for the LUN a profile (in respective meta-data structure 170) that includes indications of self-destruction properties (parameter values 172) in step 220. Alternatively the profile may be inherited from a LUN already assigned with a profile containing self-destruction properties (parameter values 172) or may be specified by a user during step 220”. The system of Shah is directed to deleting data according to a created profile with self-destruction properties wherein self-destruction properties of a profile can be specified by a user. Although Shah does not explicitly disclose “a second user interface”, one of ordinary skills in the art can understand that user’s interactions with a profile with self-destruction properties that eventually used to execute the deletion process can correspond to a second user interface in an environment with information lifecycle management object and data destruction object. Therefore, Shah at least teaches “wherein the information lifecycle management object is linked to the data destruction object using a second user interface”. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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. Claims 1, 3, 5-10, 12, 14-19, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Shah (US PGPUB 20150127902) “Shah” in view of Todd et al. (US PGPUB 20050160120) “Todd”, Khadiwala et al.(US PGPUB 20180101328) “Khadiwala”, and Fernando et al. (US PGPUB 20190236198) “Fernando”. Regarding claim 1, Shah teaches a computer-implemented method, comprising: creating a data destruction object linked to a custom object ([0045] Once the LUN (custom object) has been provisioned, the storage management controller creates for the LUN a profile (data destruction object) that includes indications of self-destruction properties... The profile may be associated with one or more LUNs in this step… Examiner’s note: Thus, the created profile can be equivalent to a data destruction object because it can contain information relating to a data destruction and the profile is associated with the corresponding object), wherein the data destruction object is linked to the custom object using a first user interface ([0047] In alternative embodiments, process 200 allows or enables a user to optionally cancel the pending in step 250. As such, the deletion of the LUN by the storage management controller 120 (step 260) may be configured as automatic or requiring a user to approve the scheduled deletion... Examiner’s note: User’s involvements in the deletion process such as approving a deletion can correspond to a first user interface incorporated between data destruction object and the custom object); creating an information lifecycle management object linked to the data destruction object ([0045]: The storage management controller creates for the LUN a profile that includes indications of self-destruction properties (information lifecycle management object). The self-destruction properties include an expiration date for the LUN, preferably according to data contained or to be contained in the LUN... Examiner’s note: Thus, self-destruction properties within a profile is equivalent to the information lifecycle management object linked to the data destruction object), wherein the information lifecycle management object is linked to the data destruction object using a second user interface ([0045] Once the LUN has been provisioned, the storage management controller 120 creates for the LUN a profile that includes indications of self-destruction properties in step 220. Alternatively the profile may be inherited from a LUN already assigned with a profile containing self-destruction properties (parameter values 172) or may be specified by a user… Examiner’s note: A profile that containing self-destruction properties indicating how LUNs are deleted can be specified by a user thus can correspond to a second user interface incorporated between the information lifecycle management object and data destruction object); scheduling a data destruction batch job selecting the data destruction object for destruction ([0046]: The storage management controller monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value of the self-destruction properties of each LUN. If the LUN has a self-destruction date past the current date, the storage management controller 120 marks the LUN as a past-due LUN… [0047]: As such, the deletion of the LUN by the storage management controller 120 may be configured as automatic or requiring a user to approve the scheduled deletion… Examiner’s note: Thus, a deletion on the object can be scheduled automatically or by a user after a determination is made such as objects that have a self-destruction date past the current date); and destroying, based on the scheduling, one or more data of the custom object ([0046]: The storage management controller destroys any marked past-due LUNs by performing a deletion of the LUN. The LUN deletion is preferably one of a secure delete, soft delete, or normal delete.); wherein each of the data destruction object, custom object, the information lifecycle management object, and information lifecycle management object having the similar context comprises data and logic defining a runtime implementation ([0046] In step 240, the storage management controller 120 monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value 172 of the self-destruction properties of each LUN. If the LUN has a self-destruction date 172 past the current date, the storage management controller 120 marks the LUN as a past-due LUN in step 250. In step 260 the storage management controller 120 destroys any marked past-due LUNs by performing a deletion of the LUN. The LUN deletion is preferably one of a secure delete, soft delete, or normal delete. A secure delete involves over-writing the data of the past-due LUN and addressing the physical data locations of the LUN as free space. A normal delete only addresses the physical data locations of the LUN as free space. A soft delete marks the LUN identifier as deleted but allows a user to undo the operation at a later date… Examiner’s note: After the creation and assigning of profiles to LUNs wherein profiles can contain self-destruction parameters, the system can begin the monitoring and marking steps that results in the destroying step. Steps 240 to 260 of fig. 2 can be equivalent to runtime implementation where a data destruction job can be started. During these steps, LUNs, self-destruction parameters of profiles are used to monitor and mark LUNs for destroying jobs and this can be equivalent to data destruction object, custom object, the information lifecycle management object comprising data and logic defining a runtime implementation ) . Shah does not explicitly teach grouping the information lifecycle management object into an audit area comprising information lifecycle management objects having a similar context, wherein a data retention policy is created, while in the audit area, for the information lifecycle management object; and verifying the destroy based on a check of a destruction log; wherein information lifecycle management object having the similar context comprises data and logic defining a runtime implementation; and wherein the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object. Todd teaches grouping the information lifecycle management object into an audit area comprising information lifecycle management objects having a similar context, wherein a data retention policy is created, while in the audit area, for the information lifecycle management object (Fig. 8 & [0111] When a host sends a request to store a CDF on the storage system, the host may indicate a retention class (audit area) for the unit of data. The storage system may maintain one or more records, such as record 801 (FIG. 8), that associates retention classes with retention periods. Thus, in the example of FIG. 8, a unit of data in the "E-mail" retention class is assigned a retention period of seven years (data retention policy), and a unit of data in the "Financial Records" class is assigned a retention period of five years. When the storage system receives a request to delete a unit of data, the storage system may first determine which retention class the unit of data is in, and then determine the value of the retention period for that unit of data (e.g., based on record 801). The storage system may then determine if the retention period has expired, and if it has not, deny the deletion request in the manner described above…[0114] In record 801, retention classes are identified by a name, such as "E-mail" or "Financial Records." However, it should be appreciated that retention classes need not be identified by a human-readable name, as any suitable identifier, such as a string of number and/or characters, may be used… Examiner’s note: Thus, data can be grouped to a class or an area that indicates its corresponding retention period. The class or area can have similar contexts such as data relating to email or financial records); wherein information lifecycle management object having the similar context comprises data and logic defining a runtime implementation ([0111]: The storage system may maintain one or more records, such as record 801 (FIG. 8), that associates retention classes with retention periods. Thus, in the example of FIG. 8, a unit of data in the "E-mail" retention class is assigned a retention period of seven years, and a unit of data in the "Financial Records" class is assigned a retention period of five years. When the storage system receives a request to delete a unit of data, the storage system may first determine which retention class the unit of data is in, and then determine the value of the retention period for that unit of data (e.g., based on record 801)…Examiner’s note: The system contains retention classes wherein each retention class describe data that share the same context. Each retention class is defined with a retention period that determines when a unit of data in the class can be deleted which can be equivalent data and logic defining a runtime implementation). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Todd teachings in the Shah system. Skilled artisan would have been motivated to incorporate assigning a retention class to data taught by Todd in the Shah system to effectively assign a retention period for the particular data and improves organization of the system by grouping data with similar class characteristics to a corresponding retention period . This close relation between both of the references highly suggests an expectation of success. Shah in view of Todd does not explicitly teach verifying the destroy based on a check of a destruction log; and wherein the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object. Khadiwala teaches verifying the destroy based on a check of a destruction log ([0139]: When the intent to delete is in the delete log (destruction log), the method continues to step where the computing device skips the data access request. When the intent to delete is not in the delete log, the method branches back to where the computing device executes the data access request. When the data element is confirmed to be deleted the computing device updates the delete log to remove the intent to delete… Examiner’s note: Thus, the system can verify that a delete or destroy based on a check from a log and the delete or destroy can be confirmed when an intent to delete is removed from the log). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Khadiwala teachings in the Shah and Todd system. Skilled artisan would have been motivated to incorporate verification of destroy operation based on a log taught by Khadiwala in the Shah and Todd system to ensure the destroy/delete process is completed, thus enhances security and reduces risks within the system . This close relation between of the references highly suggests an expectation of success. Shah in view of Todd and Khadiwala does not explicitly teach wherein the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object. Fernando teaches the data destruction object comprises an application programming interface (API) that is called at runtime to initiate data destruction of the data destruction object ([0018] Accordingly, some implementations of the present disclosure provide an efficient mechanism for performing operations such as a delete operation for records of a data object within a multi-tenant database system. For example, the mechanism may introduce a new delete operation (e.g. method, function, call, class, verb, etc.) to one or more protocols or APIs (Application Programming Interface) used by an application platform of a database system. For example, some implementations may extend the capabilities of SOAP (Simple Object Access Protocol), REST (Representational state transfer), or an application platform specific programming language. In one implementation, the delete operation is configured to allow records to be identified by using a matching technique from information provided to the delete operation. For example, information may be provided in the form of a data structure such as an object that is passed as an argument to the delete operation. In one implementation, the information may specify values related to primary keys or unique record identifiers for the records to be deleted.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Fernando teachings in the Shah and Todd and Khadiwala system. Skilled artisan would have been motivated to incorporate an API in association with a delete operation taught by Fernando in the Shah and Todd and Khadiwala system to enable the automation of tasks and data exchange between different entities, reducing manual intervention, minimizing errors. Also, this leads to increased operational efficiency and cost savings. This close relation between of the references highly suggests an expectation of success. Regarding claim 3, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah further teaches wherein an application using the custom object is deployed in a container, wherein the container further includes the data destruction object and the information lifecycle management object ([0046]: The storage management controller monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value of the self-destruction properties of each LUN. If the LUN has a self-destruction date past the current date, the storage management controller marks the LUN as a past-due LUN… Examiner’s note: Thus, properties or information relating to the object such as self-destruction date and whether the objected is marked for destruction can be determined and attached to the object. The determined properties can be equivalent to data destruction object and the information lifecycle management object of the objects). Shah in view of Todd does not explicitly teach the custom object is deployed in a container to a destination cloud platform. Khadiwala teaches custom object is deployed in a container to a destination cloud platform ([0006]: For large services, applications, and/or functions, cloud computing may be performed by multiple cloud computing resources in a distributed manner to improve the response time for completion of the service, application, and/or function. For example, Hadoop is an open source software framework that supports distributed applications enabling application execution by thousands of computers…[0007] In addition to cloud computing, a computer may use “cloud storage” as part of its memory system. As is known, cloud storage enables a user, via its computer, to store files, applications, etc., on an Internet storage system…[0141]: Note that if the processing module, module, processing circuit, and/or processing unit includes more than one processing device, the processing devices may be centrally located (e.g., directly coupled together via a wired and/or wireless bus structure) or may be distributed located (e.g., cloud computing via indirect coupling via a local area network and/or a wide area network)). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Khadiwala teachings in the Shah and Todd and Fernando system. Skilled artisan would have been motivated to incorporate a cloud platform taught by Khadiwala in the Shah and Todd and Fernando system to improve the response time for completion of the service, application, and/or function, as recognized by Khadiwala ([0006]). This close relation between of the references highly suggests an expectation of success. Regarding claim 5, Shah in view of Todd, Khadiwala, and Ferando teaches all of the limitations of claim 1. Shah further wherein there is a 1-1 mapping between the information lifecycle management object and the data destruction object ( [0045]: The storage management controller creates for the LUN a profile that includes indications of self-destruction properties. Alternatively the profile may be inherited from a LUN already assigned with a profile containing self-destruction properties or may be specified by a user. Preferably the self-destruction properties include an expiration date for the LUN, preferably according to data contained or to be contained in the LUN. Once a profile has been created, the storage management controller 120 associates the profile with the LUN in step… Examiner’s note: Thus, a profile created can include indications of self-destruction properties and expiration date for the LUN and the properties are associated to each other within a profile of an object. Therefore, an equivalent to 1-1 mapping between the information lifecycle management object and the data destruction object can be presented by the profile created). Regarding claim 6, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah does not explicitly teach wherein the information lifecycle management object is grouped into the audit area using a third user interface. Todd teaches the information lifecycle management object is grouped into the audit area using a third user interface (Fig. 9 & [0123] Host computer executes an application program that a user or administrator of host may use to store data to and retrieve data from storage system. The application program is linked with an API that provides an interface for communicating with storage system... Examiner’s note: Thus, a user interface is present in the system). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Todd teachings in the Shah, Khadiwala, and Fernando system. Skilled artisan would have been motivated to incorporate a user interface taught by Todd in the Shah, Khadiwala, and Fernando system to improve interactions between the user and the system. This close relation between both of the references highly suggests an expectation of success. Regarding claim 7, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah does not explicitly teach wherein the similar context comprises a financial audit area, a tax audit area, or a human resource audit. Todd teaches wherein the similar context comprises a financial audit area, a tax audit area, or a human resource audit (Fig. 8 & [0111]: When a host sends a request to store a CDF on the storage system, the host may indicate a retention class (area) for the unit of data. The storage system may maintain one or more records, such as record 801 (FIG. 8), that associates retention classes with retention periods. Thus, in the example of FIG. 8, a unit of data in the "E-mail" retention class is assigned a retention period of seven years, and a unit of data in the "Financial Records" class (a financial audit area) is assigned a retention period of five years… Examiner’s note: Thus, the similar context can include at least a financial audit area). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Todd teachings in the Shah, Khadiwala, and Fernando system. Skilled artisan would have been motivated to incorporate determining specific classes or areas taught by Todd in the Shah, Khadiwala, and Fernando system to increase efficiency in determining a retention period for an object thus improves the organization and performance of the system. This close relation between both of the references highly suggests an expectation of success. Regarding claim 8, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah further teaches wherein the data retention policy is created, while in the audit area, for the information lifecycle management object using a fourth user interface ([0035] The client may be a general-purpose computer configured to execute applications. Moreover, the client may interact with the storage controller in accordance with a client/server model of information delivery. That is, the client may request the services of the storage controller, and the system may return the results of the services requested by the client, by exchanging packets over the network... Examiner’s note: Thus the system provides an interface for a user such as application to communicate with the controller to request the services of the storage controller). Regarding claim 9, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 8. Shah further teaches wherein the data retention policy specifies at least a time when the destroying can occur ([0045]: Preferably the self-destruction properties include an expiration date (a time when the destroying can occur) for the LUN, preferably according to data contained or to be contained in the LUN… [0046]: The storage management controller monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value of the self-destruction properties of each LUN. If the LUN has a self-destruction date past the current date, the storage management controller marks the LUN as a past-due LUN. The storage management controller destroys any marked past-due LUNs by performing a deletion of the LUN). Regarding claim 10, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 12, note the rejections of claim 3. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 14, note the rejections of claim 5. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 15, note the rejections of claim 6. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 16, note the rejections of claim 7. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 17, note the rejections of claim 8. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 18, note the rejections of claim 9. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 19, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings. Regarding claim 21, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah in view of Todd does not explicitly teach wherein calling the API at runtime to initiate the data destruction of the data destruction object further initiates creation of the destruction log for monitoring the destroy. Khadiwala teaches initiates creation of the destruction log for monitoring the destroy ([0124] When determining to queue the delete slice requests, the processing module 84 updates a delete log 474 within the memory 88 to include the delete slice request. For example, the processing module 84 adds the slice name and the revision level to a list of encoded data slices for deletion within the delete log 474… [0127] When the other encoded data slice is probably deleted, the processing module 84 verifies deletion. As a specific example of the verification, the processing module 84 accesses the delete log 474 and indicates that the other encoded data slice has been deleted when the other revision level and other slice name combination is not present…Examiner’s note: A destruction log or delete log is utilized as part of a deletion process to monitor the destroy or deletion process). Please refer to claim 1 for the motivational statement. Regarding claim 22, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah in view of Todd does not explicitly teach wherein calling the API at runtime to initiate the data destruction of the data destruction object further enables persistent storage of data destruction metadata. Khadiwala teaches enables persistent storage of data destruction metadata ([0124]: The processing module 84 updates a delete log 474 within the memory 88 to include the delete slice request…[0141]: Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Khadiwala teachings in the Shah and Todd system. Skilled artisan would have been motivated to incorporate storing data or metadata in persistent storage taught by Khadiwala in the Shah and Todd system to provide long-term data durability and enhances data integrity. This close relation between of the references highly suggests an expectation of success. Regarding claim 22, Shah in view of Todd, Khadiwala, and Fernando teaches all of the limitations of claim 1. Shah further teaches wherein calling the API at runtime to initiate the data destruction of the data destruction object further initiates performance of a data retention check for the information lifecycle management object ([0046] In step 240, the storage management controller 120 monitors LUNs having self-destruction properties by comparing the current date or system date against the respective date parameter value 172 of the self-destruction properties of each LUN. If the LUN has a self-destruction date 172 past the current date, the storage management controller 120 marks the LUN as a past-due LUN in step 250. In step 260 the storage management controller 120 destroys any marked past-due LUNs by performing a deletion of the LUN. The LUN deletion is preferably one of a secure delete, soft delete, or normal delete). Prior Art The prior arts made of record and not relied upon is considered pertinent to applicant's disclosure. See form PTO-892. Baez et al. (US PGPUB 20230090799) is directed to techniques for specifying a deleted data retention rule for deleted objects in a communication platform are described herein. Deleted objects include objects (e.g., files, reaction emojis, etc.), that are transmitted and/or accessible via the communication platform and subsequently deleted. An administrative user of an organization can establish one or more deleted data retention rules (e.g., policies) for the organization. A deleted data retention rule can include a policy for continued storage of a deleted object after receiving a request to delete the object from the communication platform. In response to receiving the request to delete the object, and based on a deleted data retention rule, the communication platform can remove the object from view by the end user (e.g., remove from an interface), but can continue to store the object in a database for a period of time specified in the deleted data retention rule. Sadiq et al. (US PGPUB 20220382713) is directed to managing erasure of data are presented. In response to receiving a request for erasure of data from a set of data stores, an erasure component can analyze a set of rules and information relating to the user account, including an account status and erasure hold status associated with the user account. The set of rules can be based on legal or contractual obligations applicable to the set of data stores, and can indicate various conditions under which data associated with a user account of a user can be eligible to be erased from the set of data stores or an associated data vault repository. The erasure component can determine eligibility for erasure of all or a portion of the set of data from the set of data stores based on the analysis results. Erasure component can determine erasure eligibility scores to pre-qualify user accounts for erasure eligibility. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAO DANG VUONG whose telephone number is (571)272-1812. The examiner can normally be reached M-F 7:30-5 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. /C.D.V./Examiner, Art Unit 2153 02/03/2026 /KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153
Read full office action

Prosecution Timeline

Jun 06, 2024
Application Filed
May 21, 2025
Non-Final Rejection — §103
Aug 20, 2025
Response Filed
Oct 24, 2025
Final Rejection — §103
Jan 08, 2026
Request for Continued Examination
Jan 25, 2026
Response after Non-Final Action
Feb 05, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596699
POPULATING MULTI-LAYER TECHNOLOGY PRODUCT CATALOGS
2y 5m to grant Granted Apr 07, 2026
Patent 12561356
NON-TRANSITORY COMPUTER-READABLE RECORDING MEDIUM STORING INFORMATION PROCESSING PROGRAM, INFORMATION PROCESSING METHOD, AND INFORMATION PROCESSING APPARATUS
2y 5m to grant Granted Feb 24, 2026
Patent 12536162
SYSTEM AND METHOD FOR ANALYSIS OF GRAPH DATABASES USING INTELLIGENT REASONING SYSTEMS
2y 5m to grant Granted Jan 27, 2026
Patent 12524438
CENTRALIZED DATABASE MANAGEMENT SYSTEM FOR DATABASE SYNCHRONIZATION USING SAME-SIZE INVERTIBLE BLOOM FILTERS
2y 5m to grant Granted Jan 13, 2026
Patent 12517926
System, Method, and Computer Program Product for Analyzing a Relational Database Using Embedding Learning
2y 5m to grant Granted Jan 06, 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
68%
Grant Probability
94%
With Interview (+26.2%)
3y 4m
Median Time to Grant
High
PTA Risk
Based on 109 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