Prosecution Insights
Last updated: April 19, 2026
Application No. 18/473,794

SYSTEMS AND METHODS RELATING TO OBJECT PROTECTION

Final Rejection §101§103§112
Filed
Sep 25, 2023
Examiner
SHEIKH, ASFAND M
Art Unit
3626
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Capital One Services LLC
OA Round
2 (Final)
46%
Grant Probability
Moderate
3-4
OA Rounds
4y 7m
To Grant
94%
With Interview

Examiner Intelligence

Grants 46% of resolved cases
46%
Career Allow Rate
257 granted / 557 resolved
-5.9% vs TC avg
Strong +48% interview lift
Without
With
+48.0%
Interview Lift
resolved cases with interview
Typical timeline
4y 7m
Avg Prosecution
35 currently pending
Career history
592
Total Applications
across all art units

Statute-Specific Performance

§101
27.8%
-12.2% vs TC avg
§103
45.6%
+5.6% vs TC avg
§102
8.4%
-31.6% vs TC avg
§112
9.1%
-30.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 557 resolved cases

Office Action

§101 §103 §112
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 . Claim(s) 1-20 are pending for examination. Claim(s) 1, 11, 12, and 20 are amended. This action is Final. Response to Arguments Applicant's arguments filed 9/16/2025 with respect to the 35 U.S.C. 101 rejection have been fully considered but they are not persuasive. Applicant Argues: Specifically, amended claim 1 recites "monitoring, using a processor, of audio data and history data associated with a user, wherein the audio data comprises at least one conversation related to at least one user interaction with at least one object," "detecting an object replacement triggering event, based on feature extraction analysis of the at least one conversation and the history data, wherein the object replacement triggering event includes audio indications from the user," and "receiving user data for the user associated with the feature extraction analysis of the at least one conversation and the history data." Such features are non-human, technical functions that provide more than mere instructions to "apply it," and therefore cannot be considered an abstract idea. Further, such features are not sales or marketing activities, and do more than just link the claim to a technical environment. Examiner’s Response: The examiner respectfully disagrees. The additional element of “using a processor” is described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration (see Applicant’s Specification, ⁋[0035] and ⁋⁋ [0148]-[0151]).). This elements in the steps is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component and merely invoke such additional elements as a tool to perform the abstract idea as identified in Step 2A-Prong 1 (i.e., "monitoring of audio data and history data associated with a user, wherein the audio data comprises at least one conversation related to at least one user interaction with at least one object," "detecting an object replacement triggering event, based on feature extraction analysis of the at least one conversation and the history data, wherein the object replacement triggering event includes audio indications from the user," and "receiving user data for the user associated with the feature extraction analysis of the at least one conversation and the history data."). See MPEP 2106.05(f). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. In addition, the limitations of (i.e., "monitoring of audio data and history data associated with a user, wherein the audio data comprises at least one conversation related to at least one user interaction with at least one object," "detecting an object replacement triggering event, based on feature extraction analysis of the at least one conversation and the history data, wherein the object replacement triggering event includes audio indications from the user," and "receiving user data for the user associated with the feature extraction analysis of the at least one conversation and the history data.") are in fact related to sales activities or behaviors and/or business relations as they focus on “object replacement” (i.e., construed as a sales activity and/or business relation). Therefore, the examiner finds this argument not persuasive. Applicant Argues: Further, the subject matter of claim 1 is integrated into a practical application. The Specification sets out the technical problem and technical solution, the latter of which is embodied in the claims. For example, the claimed features result in improvement to the technology for object protection indication systems. The features of amended claim 1 may advantageously combine audio data and history data, enabling the system to consider both real-time information and past patterns or trends to make informed decisions. As such, the functionality of object protection indication systems is improved, providing a more comprehensive and accurate assessment. See Specification paras. [00103]-[00105]. Therefore, based at least on the foregoing, amended claim 1 is believed to recite eligible subject matter. Further, claims 11 and 20, although of different scope, have been amended to recite features similar to the features of amended claim 1, and thus is also believed to recite eligible subject matter for at least the same reasons as amended claim 1. Accordingly, in view of the foregoing, Applicant respectfully requests that the rejection of claims 1, 11 and 20, as well as the claims depending therefrom, under § 101 be withdrawn. Examiner’s Response: The examiner respectfully disagrees. The examiner respectfully notes that improvement lies within the abstract idea itself, as identified in Step 2A-Prong 1. The examiner notes that the “using a processor” amounts no more than mere instructions to apply the exception using a generic computer component and merely invoke such additional elements as a tool to perform the abstract idea. See MPEP 2106.05(f). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, the examiner finds this argument not persuasive. Applicant's arguments filed 9/16/2025 with respect to the 35 U.S.C. 103 rejection have been considered but are moot in view of new grounds of rejection. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim(s) 13 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 13 recites the limitation the replacement server database There is insufficient antecedent basis for this limitation in the claim. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claim(s) 1-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more. Step 1: claim(s) 1-20 are directed to a process and/or machine. Therefore, the claims are directed to statutory subject matter under Step 1 (Step 1: YES). See MPEP 2106.03. Prong 1, Step 2A: claim 1, and similar claim(s) 11 and 20, taken as representative, recites at least the following limitations that recite an abstract idea: A computer-implemented method for providing an object protection indicator, the method comprising: monitoring detecting an object replacement triggering event, based on a result of the monitoring feature extraction analysis of the at least one conversation and the history data, wherein the object replacement triggering event includes an audio indication from the user; receiving user data for the user associated with the feature extraction analysis of the at least one of audio data or conversation and the history data; identifying an object corresponding to the object replacement triggering event based on the user data; identifying object-related information, the object-related information comprising at least one of an object protection information or an object replacement information; and transmitting the at least one of the object protection information or the object replacement information based on identifying the object-related information. Additionally, regarding Claim 11, the following limitations similarly recite an abstract idea: receiving determining, based on the authentication data, that one or more objects should have replacement coverage; prompting the user [... additional limitations omitted as they correspond to the limitations above for Claim 1]. The above limitations, under their broadest reasonable interpretation, fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, enumerated in MPEP 2106.04(a)(2)(II), in that they recite "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. The broadest reasonable interpretation of these limitations includes for claim 1, and for similar claim(s) 11 and 20 includes authenticating a user and offering replacement coverage on an object and further monitoring data related to the user and based on an event offer additional protection and/or replacement information in the form of object related information, thus, the claim 1, and similar claim(s) 11 and 20 falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas as they recite a commercial interaction in the form of sales activities or behaviors and/or business relations. Accordingly, these claims recite an abstract idea. Prong 2, Step 2A: Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)), (2) Adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)). Claim 1, and for similar claim(s) 11 and 20, recite i.e., a data server, [user device prompting] and processor, and general concepts of receiving/transmitting. These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration (see Applicant’s Specification, ⁋[0035] and ⁋⁋ [0148]-[0151]).). These elements in the steps are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component and merely invoke such additional elements as a tool to perform the abstract idea. See MPEP 2106.05(f). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. As such, under Prong 2 of Step 2A, when considered both individually and as a whole, the limitations of Claim 1, and for similar claim(s) 11 and 20 are not indicative of integration into a practical application (Prong 2, Step 2A: NO). See MPEP 2106.04(d). Since claim 1, and similar claim(s) 11 and 20 recites an abstract idea and fails to integrate the abstract idea into a practical application, claim 1, and similar claim(s) 11 and 20 is “directed to” an abstract idea under Step 2A (Step 2A: YES). See MPEP 2106.04(d). Step 2B: The recitation of the additional elements is acknowledged, as identified above with respect to Prong 2 of Step 2A. These additional elements do not add significantly more to the abstract idea for the same reasons as addressed above with respect to Prong 2 of Step 2A. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of for claim 1, and for similar claim(s) 11 and 20, i.e., a data server, [user device prompting] and processor, and general concepts of receiving/transmitting; amounts to no more than mere instructions to apply the exception using a generic computer component and do not add anything that is not already present when they are considered individually or in combination. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, under Step 2B, there are no meaningful limitations in claim 1, and similar claim(s) 11 and 20 that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself (Step 2B: NO). See MPEP 2106.05. Accordingly, under the Subject Matter Eligibility test, claim 1, and similar claim(s) 11 and 20 is ineligible. Regarding Claims 2-10 and 12-19, claims 2-10 and 12-19 further defines the abstract idea that is present in their respective independent claims and hence are abstract for at least the reasons presented above w/ respect to “Certain Methods of Organizing Human Activity” as the claims recite concepts related to "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations, i.e., further features related to object related information. These dependent claim does not include any additional elements that integrate the abstract idea into a practical application; as such elements are recited at a high level of generality such that it amounts not more than mere instructions to apply the exception using generic computer components (i.e., database (claim 3, 13, and 15) and GUI (claim 4) and [trained] machine learning model (claim 6 and 17)). Even in combination, these additional elements do not integrate the abstract idea into a practical application and do no not amount to significantly more than the abstract idea itself. Thus, the aforementioned claims are not patent-eligible. 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, 3, 10, 11-12, 14, 15, and 20 is/are is/are rejected under 35 U.S.C. 103 as being unpatentable over Wakim (US 9,007,229 B1) in view of Sylves (US 2014/0220526 A1). Regarding Claim 1; Wakim discloses a computer-implemented method for providing an object protection indicator, the method comprising: monitoring, using a processor, (FIG. 6 and FIG. 8 and FIG. 9 and col. 9, lines 50-58 - FIG. 6 is a graph 600 illustrating data from different sensors 210 in the user device 102 and the physical events described thereby. In this graph, time is indicated along a horizontal axis 602 ranging from time zero to fourteen hours. For the sake of illustration, consider that this describes a trip by the user 104. At time 2 hours, the user 104 leaves home and drives to the harbor. At time 8 hours, the user has boarded a fishing boat and is fishing until time 12 hours. Finally, at time hour 14, the user 104 has returned to the hotel to sleep and col. 10, lines 36-40 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events); detecting an object replacement triggering event, based on a result feature extraction analysis of the at least (FIG. 6 and FIG. 8 and FIG. 9 and col. 9, lines 50-58 and col. 10, lines 36-59 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events... For the example depicted here, and by way of illustration only, assume that physical events are identified when all three physical quantities being measured exceed the minimum threshold 612. Shown here are three physical events 618(1), 618(2), and 618(3) depicted at times 8, 10, and 12 hours, respectively, while the user 104 was fishing. During this time, the speed, acceleration, and humidity exceed the minimum threshold 612 in the same interval and col. 12, lines 26-39); receiving user data for a user associated with the feature extraction analysis of the at least (FIG. 6 and FIG. 8 and FIG. 9 and col. 7, lines 40-45 - The other data 420 may include information such as payment account information for the users 104, relationships between user devices 102 and the users, and so forth. For example, the other data 420 may specify that the user 104(1) owns user devices 102(1) and 102(2), so recommendations should be provided to the user 104(1) and col. 8, lines 48-50 and col. 9, lines 33-40 - User demographics 418(8) for users 104 associated with the user devices 102 may be considered in the recommendation process. The users 104 may be associated with the user devices 102 by purchase, use, and so forth. The user demographics 418(8) may include a home location of the user 104, age of the user 104, occupation of the user 104, and so forth. For example, a more comprehensive extended warranty item 422(2) may be offered to younger users and col. 11, lines 40-42 - At 806, the server 108 generates recommendation data 112 by determining one or more recommended items 422 based at least in part on the one or more recommendation factors 418 and col. 10, lines 36-59 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events... For the example depicted here, and by way of illustration only, assume that physical events are identified when all three physical quantities being measured exceed the minimum threshold 612. Shown here are three physical events 618(1), 618(2), and 618(3) depicted at times 8, 10, and 12 hours, respectively, while the user 104 was fishing. During this time, the speed, acceleration, and humidity exceed the minimum threshold 612 in the same interval); identifying an object corresponding to the object replacement triggering event based on the user data (FIG. 8 and FIG. 9 and col. 7, lines 40-45 - The other data 420 may include information such as payment account information for the users 104, relationships between user devices 102 and the users, and so forth. For example, the other data 420 may specify that the user 104(1) owns user devices 102(1) and 102(2), so recommendations should be provided to the user 104(1)) identifying object-related information, the object-related information comprising at least one of an object protection information or an object replacement information (FIG. 7 and col. 10, lines 60-col. 11, lines 16 - FIG. 7 illustrates a user interface 700 of the user device 102 presenting recommended items 422. As described above, the recommendation may be based at least in part on the sensor data 110, environmental data 114, or both. As mentioned above, in some implementations, the recommendation data 112 or a portion thereof may be presented by the user device 102 as shown here. A physical event message 702 is displayed which provides an indication to the user 104 that a physical event has occurred or may occur. This physical event may be identified based at least in part on the sensor data 110 or the environmental data 114. For example, based at least in part on the sensor data 110 from the one or more accelerometers 210(1), an acceleration which has exceeded a minimum threshold has been identified as a physical event, such as a drop onto a hard surface. A recommended item list 704 may be presented, presenting one or more items 422. In this example, an extended warranty and a protective cover are the recommended items 422. A purchase control 706 may also be presented. When activated, the corresponding item 422 may be purchase) and transmitting the at least one of the object protection information or the object replacement information based on identifying the object-related information (FIG. 7 and col. 10, lines 60-col. 11, lines 16 - FIG. 7 illustrates a user interface 700 of the user device 102 presenting recommended items 422. As described above, the recommendation may be based at least in part on the sensor data 110, environmental data 114, or both. As mentioned above, in some implementations, the recommendation data 112 or a portion thereof may be presented by the user device 102 as shown here. A physical event message 702 is displayed which provides an indication to the user 104 that a physical event has occurred or may occur. This physical event may be identified based at least in part on the sensor data 110 or the environmental data 114. For example, based at least in part on the sensor data 110 from the one or more accelerometers 210(1), an acceleration which has exceeded a minimum threshold has been identified as a physical event, such as a drop onto a hard surface. A recommended item list 704 may be presented, presenting one or more items 422. In this example, an extended warranty and a protective cover are the recommended items 422. A purchase control 706 may also be presented. When activated, the corresponding item 422 may be purchase). Wakim fails to explicitly disclose: monitoring, using a processor, audio data..., wherein the audio data comprises at least one conversation related to at least one user interaction with tat least one object; detecting an object replacement triggering event, based on a result feature extraction analysis of the at least one conversation..., wherein the object replacement triggering event includes an audio indication from the user; [and] receiving user data for a user associated with the feature extraction analysis of the at least one conversation.... However, in an analogous art, Sylves teaches [concepts of]: monitoring, using a processor, audio data..., wherein the audio data comprises at least one conversation related to at least one user interaction with tat least one object ([0042]-[0043] - In some implementations, attribute information may include information associated with an audio recording.... Attribute information may include product information about a product and/or service discussed in the audio recording, and/or information identifying a device used by a speaker, such as information identifying a cell phone model (e.g., "smart phone model X"), a telephone type (e.g., a touchtone telephone), etc.); detecting an object replacement triggering event, based on a result feature extraction analysis of the at least one conversation..., wherein the object replacement triggering event includes an audio indication from the user (([0042]-[0043] - In some implementations, attribute information may include information associated with an audio recording.... The product and/or service information may be useful for determining a speaker's sentiment toward the product and/or service (e.g., assessing a customer's satisfaction with a recently purchased service, assessing a customer's frustration with a malfunctioning product, etc.). In some implementations, attribute information (e.g., information identifying a product and/or service) may be related to all of the keywords and/or emotions associated with a communication (e.g., a conversation, an utterance, etc.), or may be related to a single keyword and/or emotion associated with the communication); [and] receiving user data for a user associated with the feature extraction analysis of the at least one conversation... ([0042]-[0043] - The unique audio recording identifier may include a string of characters (e.g., numbers, letters, and/or symbols), and may be useful for identifying an audio recording and associating the audio recording with other voice emotion and attribute information. Additionally, or alternatively, attribute information may include a unique identification number identifying a speaker on the audio recording (e.g., a caller, a call center representative, etc.), such as a speaker's name, a speaker's service provider account number, a speaker's employee identification number, or the like. In some implementations, the unique audio recording identifier may change as the audio recording progresses. For example, the unique audio recording identifier may be modified based on attribute information associated with the audio recording). Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Sylves to the monitoring, detecting, and receive of user data of Wakim to [additionally] include monitoring, using a processor, at least audio data..., wherein the audio data comprises at least one conversation related to at least one user interaction with tat least one object; detecting an object replacement triggering event, based on a result feature extraction analysis of the at least one conversation..., wherein the object replacement triggering event includes an audio indication from the user; [and] receiving user data for a user associated with the feature extraction analysis of the at least one conversation.... One would have been motivated to combine the teachings of Sylves to Wakim to do so as it provides / allows [to be] helpful in assessing the quality of interactions (Sylves, [0001]). Regarding Claim 3; Wakim in view of Sylves discloses the method to Claim 1. Wakin further discloses wherein the user data includes registered protection information input by the user, or operation data from an operation database (FIG. 2 and FIG. 6 and FIG. 8 and FIG. 9 and col. 9, lines 50-64 - A magnitude 604 of a physical event is indicated along a vertical axis. This magnitude 604 may comprise a scalar quantity such as temperature, m/s.sup.2, humidity and so forth. In other implementations, the magnitude 604 may be representative of the severity of the physical events 418(6). In some implementations, vector quantities may be used and col. 10, lines 36-59). Regarding Claim 10; Wakim in view of Sylves discloses the method to Claim 1. Wakin further discloses further comprising: transmitting an indication to the user to provide the object protection information (FIG. 7 and col. 11, lines 8-16). Regarding Claim 11; Wakim in view of discloses a computer-implemented method for offering a safeguarding indicator for an item, the method comprising: receiving, from a data server, authentication data related to a user (FIG. 4-Server w/ 430 and FIG. 8 and col. 8, lines 20-22 - Other modules 430 may be present in the memory 404 as well. These modules may provide functions including authorization, authentication, accounting, security, and so forth and col. 11, lines 25-30 - FIG. 8 illustrates a scenario 800 in which a recommendation is made based at least in part on the sensor data 110. At 802, the user 104 purchases a user device 102. At that time of purchase, the user 104 may have been presented with various items 422 for purchase, such as extended warranties, insurance, protective covers, and so forth. However, for some reason, the user 104 chose not to purchase the items 422);) determining, based on the authentication data, that one or more objects should have replacement coverage (FIG. 8 and col. 11, lines 25-30 - FIG. 8 illustrates a scenario 800 in which a recommendation is made based at least in part on the sensor data 110. At 802, the user 104 purchases a user device 102. At that time of purchase, the user 104 may have been presented with various items 422 for purchase, such as extended warranties, insurance, protective covers, and so forth. However, for some reason, the user 104 chose not to purchase the items 422); prompting the user via a user device, to obtain and input replacement coverage information corresponding to each of the one or more objects (FIG. 1 – depicts user device 102 and server 108 (i.e., as noted the only device actors) and FIG. 8 and col. 3, lines 3-14 - The server 108 may use the sensor data 110, other information about environmental data associated with the user device 102, or a combination thereof to identify physical events which have affected or may affect the user device 102 to generate recommendation data 112. The recommendation data 112 may comprise one or more items such as goods or services which may be of interest to the user 104 of the user device 102. These one or more items may include extended warranties, repair services, warranty services, user device upgrades, personal services, vehicular services, and so forth. The server 108 is described below in more detail with regard to FIG. 4. and col. 6, lines 18-24 - An internet browser module 224 is configured to provide access to content such as web pages and so forth. For example, the internet browser module 224 may be configured to render at least a portion of hyper-text markup language ("HTML") files on the display 206. In some implementations, the recommendation data 112 or a portion thereof may be presented by the internet browser module 224 and col. 11, lines 25-30 - FIG. 8 illustrates a scenario 800 in which a recommendation is made based at least in part on the sensor data 110. At 802, the user 104 purchases a user device 102. At that time of purchase, the user 104 may have been presented with various items 422 for purchase, such as extended warranties, insurance, protective covers, and so forth. However, for some reason, the user 104 chose not to purchase the items 422); monitoring, using a processor, [history data] associated with a user (FIG. 6 and FIG. 8 and FIG. 9 and col. 9, lines 50-58 - FIG. 6 is a graph 600 illustrating data from different sensors 210 in the user device 102 and the physical events described thereby. In this graph, time is indicated along a horizontal axis 602 ranging from time zero to fourteen hours. For the sake of illustration, consider that this describes a trip by the user 104. At time 2 hours, the user 104 leaves home and drives to the harbor. At time 8 hours, the user has boarded a fishing boat and is fishing until time 12 hours. Finally, at time hour 14, the user 104 has returned to the hotel to sleep and col. 10, lines 36-40 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events) detecting an object replacement triggering event, based on feature extraction analysis of [the history data] (FIG. 6 and FIG. 8 and FIG. 9 and col. 9, lines 50-58 and col. 10, lines 36-59 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events... For the example depicted here, and by way of illustration only, assume that physical events are identified when all three physical quantities being measured exceed the minimum threshold 612. Shown here are three physical events 618(1), 618(2), and 618(3) depicted at times 8, 10, and 12 hours, respectively, while the user 104 was fishing. During this time, the speed, acceleration, and humidity exceed the minimum threshold 612 in the same interval and col. 12, lines 26-39); receiving user data for a user associated with the at least [the history data] (FIG. 6 and FIG. 8 and FIG. 9 and col. 7, lines 40-45 - The other data 420 may include information such as payment account information for the users 104, relationships between user devices 102 and the users, and so forth. For example, the other data 420 may specify that the user 104(1) owns user devices 102(1) and 102(2), so recommendations should be provided to the user 104(1) and col. 8, lines 48-50 and col. 9, lines 33-40 - User demographics 418(8) for users 104 associated with the user devices 102 may be considered in the recommendation process. The users 104 may be associated with the user devices 102 by purchase, use, and so forth. The user demographics 418(8) may include a home location of the user 104, age of the user 104, occupation of the user 104, and so forth. For example, a more comprehensive extended warranty item 422(2) may be offered to younger users and col. 11, lines 40-42 - At 806, the server 108 generates recommendation data 112 by determining one or more recommended items 422 based at least in part on the one or more recommendation factors 418 and col. 10, lines 36-59 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events... For the example depicted here, and by way of illustration only, assume that physical events are identified when all three physical quantities being measured exceed the minimum threshold 612. Shown here are three physical events 618(1), 618(2), and 618(3) depicted at times 8, 10, and 12 hours, respectively, while the user 104 was fishing. During this time, the speed, acceleration, and humidity exceed the minimum threshold 612 in the same interval); identifying object-related information, the object-related information comprising at least one of an object protection information or an object replacement information (FIG. 7 and col. 10, lines 60-col. 11, lines 16 - FIG. 7 illustrates a user interface 700 of the user device 102 presenting recommended items 422. As described above, the recommendation may be based at least in part on the sensor data 110, environmental data 114, or both. As mentioned above, in some implementations, the recommendation data 112 or a portion thereof may be presented by the user device 102 as shown here. A physical event message 702 is displayed which provides an indication to the user 104 that a physical event has occurred or may occur. This physical event may be identified based at least in part on the sensor data 110 or the environmental data 114. For example, based at least in part on the sensor data 110 from the one or more accelerometers 210(1), an acceleration which has exceeded a minimum threshold has been identified as a physical event, such as a drop onto a hard surface. A recommended item list 704 may be presented, presenting one or more items 422. In this example, an extended warranty and a protective cover are the recommended items 422. A purchase control 706 may also be presented. When activated, the corresponding item 422 may be purchase) and transmitting the at least one of the object protection information or the object replacement information based on identifying the object-related information (FIG. 7 and col. 10, lines 60-col. 11, lines 16 - FIG. 7 illustrates a user interface 700 of the user device 102 presenting recommended items 422. As described above, the recommendation may be based at least in part on the sensor data 110, environmental data 114, or both. As mentioned above, in some implementations, the recommendation data 112 or a portion thereof may be presented by the user device 102 as shown here. A physical event message 702 is displayed which provides an indication to the user 104 that a physical event has occurred or may occur. This physical event may be identified based at least in part on the sensor data 110 or the environmental data 114. For example, based at least in part on the sensor data 110 from the one or more accelerometers 210(1), an acceleration which has exceeded a minimum threshold has been identified as a physical event, such as a drop onto a hard surface. A recommended item list 704 may be presented, presenting one or more items 422. In this example, an extended warranty and a protective cover are the recommended items 422. A purchase control 706 may also be presented. When activated, the corresponding item 422 may be purchase). Wakim fails to explicitly disclose: monitoring, using a processor, audio data associated with the user, wherein the audio data comprises at least one conversation related to at least one user interaction with tat least one object; detecting an object replacement triggering event, based on a result feature extraction analysis of the at least one conversation, wherein the object replacement triggering event includes an audio indication from the user; [and] receiving user data for a user associated with the feature extraction analysis of the at least one conversation. However, in an analogous art, Sylves teaches [concepts of]: monitoring, using a processor, audio data associated with the user, wherein the audio data comprises at least one conversation related to at least one user interaction with tat least one object ([0042]-[0043] - In some implementations, attribute information may include information associated with an audio recording.... Attribute information may include product information about a product and/or service discussed in the audio recording, and/or information identifying a device used by a speaker, such as information identifying a cell phone model (e.g., "smart phone model X"), a telephone type (e.g., a touchtone telephone), etc.); detecting an object replacement triggering event, based on a result feature extraction analysis of the at least one conversation, wherein the object replacement triggering event includes an audio indication from the user (([0042]-[0043] - In some implementations, attribute information may include information associated with an audio recording.... The product and/or service information may be useful for determining a speaker's sentiment toward the product and/or service (e.g., assessing a customer's satisfaction with a recently purchased service, assessing a customer's frustration with a malfunctioning product, etc.). In some implementations, attribute information (e.g., information identifying a product and/or service) may be related to all of the keywords and/or emotions associated with a communication (e.g., a conversation, an utterance, etc.), or may be related to a single keyword and/or emotion associated with the communication); [and] receiving user data for a user associated with the feature extraction analysis of the at least one conversation ([0042]-[0043] - The unique audio recording identifier may include a string of characters (e.g., numbers, letters, and/or symbols), and may be useful for identifying an audio recording and associating the audio recording with other voice emotion and attribute information. Additionally, or alternatively, attribute information may include a unique identification number identifying a speaker on the audio recording (e.g., a caller, a call center representative, etc.), such as a speaker's name, a speaker's service provider account number, a speaker's employee identification number, or the like. In some implementations, the unique audio recording identifier may change as the audio recording progresses. For example, the unique audio recording identifier may be modified based on attribute information associated with the audio recording). Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Sylves to the monitoring, detecting, and receive of user data of Wakim to [additionally] include monitoring, using a processor, audio data associated with the user, wherein the audio data comprises at least one conversation related to at least one user interaction with tat least one object; detecting an object replacement triggering event, based on a result feature extraction analysis of the at least one conversation wherein the object replacement triggering event includes an audio indication from the user; [and] receiving user data for a user associated with the feature extraction analysis of the at least one conversation. One would have been motivated to combine the teachings of Sylves to Wakim to do so as it provides / allows [to be] helpful in assessing the quality of interactions (Sylves, [0001]). Additionally, Regarding Claim 12; Wakim, as shown above re: Claim 11, discloses the features of: monitoring, using a processor, history data associated with a user (FIG. 6 and FIG. 8 and FIG. 9 and col. 9, lines 50-58 - FIG. 6 is a graph 600 illustrating data from different sensors 210 in the user device 102 and the physical events described thereby. In this graph, time is indicated along a horizontal axis 602 ranging from time zero to fourteen hours. For the sake of illustration, consider that this describes a trip by the user 104. At time 2 hours, the user 104 leaves home and drives to the harbor. At time 8 hours, the user has boarded a fishing boat and is fishing until time 12 hours. Finally, at time hour 14, the user 104 has returned to the hotel to sleep and col. 10, lines 36-40 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events); detecting an object replacement triggering event, based on feature extraction analysis of [the history data] (FIG. 6 and FIG. 8 and FIG. 9 and col. 9, lines 50-58 and col. 10, lines 36-59 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events... For the example depicted here, and by way of illustration only, assume that physical events are identified when all three physical quantities being measured exceed the minimum threshold 612. Shown here are three physical events 618(1), 618(2), and 618(3) depicted at times 8, 10, and 12 hours, respectively, while the user 104 was fishing. During this time, the speed, acceleration, and humidity exceed the minimum threshold 612 in the same interval and col. 12, lines 26-39); receiving user data for a user associated with the at least the history data (FIG. 6 and FIG. 8 and FIG. 9 and col. 7, lines 40-45 - The other data 420 may include information such as payment account information for the users 104, relationships between user devices 102 and the users, and so forth. For example, the other data 420 may specify that the user 104(1) owns user devices 102(1) and 102(2), so recommendations should be provided to the user 104(1) and col. 8, lines 48-50 and col. 9, lines 33-40 - User demographics 418(8) for users 104 associated with the user devices 102 may be considered in the recommendation process. The users 104 may be associated with the user devices 102 by purchase, use, and so forth. The user demographics 418(8) may include a home location of the user 104, age of the user 104, occupation of the user 104, and so forth. For example, a more comprehensive extended warranty item 422(2) may be offered to younger users and col. 11, lines 40-42 - At 806, the server 108 generates recommendation data 112 by determining one or more recommended items 422 based at least in part on the one or more recommendation factors 418 and col. 10, lines 36-59 - A lookback window 616 may be used by the recommendation module 426 during generation of the recommendation data 112. The lookback window 616 allows the recommendation module 426 to account for a pattern of occurrence of the physical events... For the example depicted here, and by way of illustration only, assume that physical events are identified when all three physical quantities being measured exceed the minimum threshold 612. Shown here are three physical events 618(1), 618(2), and 618(3) depicted at times 8, 10, and 12 hours, respectively, while the user 104 was fishing. During this time, the speed, acceleration, and humidity exceed the minimum threshold 612 in the same interval); identifying the object corresponding to the object replacement triggering event based on the user data (FIG. 8 and FIG. 9 and col. 7, lines 40-45 - The other data 420 may include information such as payment account information for the users 104, relationships between user devices 102 and the users, and so forth. For example, the other data 420 may specify that the user 104(1) owns user devices 102(1) and 102(2), so recommendations should be provided to the user 104(1). Regarding Claim 14; Wakim in view of Sylves discloses the method to Claim 1. Wakin further discloses wherein transmitting the object protection information includes an interactive agent for providing the user with responsive coverage information (FIG. 7 and col. 11, lines 16-24 and In some implementations the recommendation may comprise an action by another party. For example, instead of or in addition to the information presented as shown here in FIG. 7, a service representative may communicate with the user 104 associated with the user device 102. For example, the service representative may call the user 104 at a previously determined telephone number, or initiate a chat session on the user device 102) Regarding Claim(s) 15; claim(s) 15 is/are directed to a/an “similar” method associated with the method claimed in claim(s) 3. Claim(s) 15 is/are similar in scope to claim(s) 3, and is/are therefore rejected under similar rationale. Regarding Claim(s) 20; claim(s) 20 is/are directed to a/an system associated with the method claimed in claim(s) 1. Claim(s) 20 is/are similar in scope to claim(s) 1, and is/are therefore rejected under similar rationale. Claim(s) 2 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wakim (US 9,007,229 B1) in view of Sylves (US 2014/0220526 A1) and further in view of Mikan et al. (US 2013/0041759 A1) Regarding Claim 2; Wakim in view of Sylves discloses the method to Claim 1. Wakim in view of Sylves fails to explicitly disclose wherein the monitoring is performed based on receiving an opt-in indication from the user. However, in an analogous art, Mikan teaches wherein the monitoring is performed based on receiving an opt-in indication from the user ([0010] and [0048] - Method 500 can begin with step 501 in which the server 130 receives user acceptance of an opt-in program in which the server 130 monitors usage of consumer items by the user and conveys certain information to promoters of products or services). Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Mikan to the monitoring of Wakim in view of Sylves to include wherein the monitoring is performed based on receiving an opt-in indication from the use One would have been motivated to combine the teachings of Mikan to Wakim in view of Sylves to do so as it provides / allows for monitoring usage of an assortment of items, identifying replacement items according to the usage, and selecting advertisers to present “and promote “products that are similar or equivalent to the replacement items (as gleaned from, Mikan, [0003[ and [0010]). Regarding Claim(s) 18; claim(s) 18 is/are directed to a/an “similar” method associated with the method claimed in claim(s) 2. Claim(s) 18 is/are similar in scope to claim(s) 2, and is/are therefore rejected under similar rationale. Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wakim (US 9,007,229 B1) in view of Sylves (US 2014/0220526 A1) and further in view of Mayman (US 2018/0033016 A1) Regarding Claim 4; Wakim in view of Sylves discloses the method to Claim 1. Wakim discloses further comprising: providing, to a GUI display of a user device, icon information comprising ...the object protection information (FIG. 7). Wakim in view of Sylves fails to explicitly disclose further comprising: providing, to a GUI display of a user device, ... information comprising contact information related to the object protection information. However, in an analogous art, Mayman further teaches comprising: providing, to a GUI display of a user device, ... information comprising contact information related to the object protection information (FIG. 4D and FIG. 4E and [0072] - By contrast, registration via a curated product information system, in accordance with some embodiments, may provide simple access to information about all of the products that a consumer has registered (e.g., t
Read full office action

Prosecution Timeline

Sep 25, 2023
Application Filed
Jun 13, 2025
Non-Final Rejection — §101, §103, §112
Aug 20, 2025
Interview Requested
Aug 27, 2025
Applicant Interview (Telephonic)
Aug 28, 2025
Examiner Interview Summary
Sep 16, 2025
Response Filed
Dec 16, 2025
Final Rejection — §101, §103, §112
Mar 10, 2026
Interview Requested
Mar 24, 2026
Applicant Interview (Telephonic)
Mar 25, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12056682
TRANSACTION CHANGE BACK PROCESSING
2y 5m to grant Granted Aug 06, 2024
Patent 12051068
SYSTEM, METHOD, AND COMPUTER PROGRAM PRODUCT FOR REMOTE AUTHORIZATION OF PAYMENT TRANSACTIONS
2y 5m to grant Granted Jul 30, 2024
Patent 12026789
SYSTEMS AND METHODS OF FORENSIC ANALYSIS OF CRYPTOCURRENCY TRANSACTIONS
2y 5m to grant Granted Jul 02, 2024
Patent 12008520
SYSTEMS AND METHODS FOR RECYCLING CONSUMER ELECTRONIC DEVICES
2y 5m to grant Granted Jun 11, 2024
Patent 11989789
Systems and Methods for Locating Merchant Terminals Based on Transaction Data
2y 5m to grant Granted May 21, 2024
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
46%
Grant Probability
94%
With Interview (+48.0%)
4y 7m
Median Time to Grant
Moderate
PTA Risk
Based on 557 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