Prosecution Insights
Last updated: August 16, 2026
Application No. 18/343,572

METHOD, SERVER, AND USER TERMINAL FOR PROVIDING GIFT INFORMATION

Non-Final OA §101§103
Filed
Jun 28, 2023
Priority
Jul 05, 2022 — RE 10-2022-0082793
Examiner
WEINER, ARIELLE E
Art Unit
3689
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Kakao Corp.
OA Round
3 (Non-Final)
44%
Grant Probability
Moderate
3-4
OA Rounds
0m
Est. Remaining
97%
With Interview

Examiner Intelligence

Grants 44% of resolved cases
44%
Career Allowance Rate
104 granted / 237 resolved
-8.1% vs TC avg
Strong +53% interview lift
Without
With
+53.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
35 currently pending
Career history
279
Total Applications
across all art units

Statute-Specific Performance

§101
31.0%
-9.0% vs TC avg
§103
43.0%
+3.0% vs TC avg
§102
6.2%
-33.8% vs TC avg
§112
17.4%
-22.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 237 resolved cases

Office Action

§101 §103
DETAILED ACTION This action is in reply to the Amendments filed on 06/16/2026. Claims 15-20 are withdrawn. Claims 2, 5-6, and 9 are cancelled. Claim 22 is newly added Claims 1, 3-4, 7-8, 10-14 and 21-22 are currently pending. Claims 1, 3-4, 7-8, 10-14 and 21-22 are rejected and have been examined. Response to Amendment Applicant’s amendment, filed 06/16/2026, has been entered. Claims 1, 7, and 14 have been amended. Priority This patent Application claims priority from Foreign Application No. KR10-2022-0082793 filed 07/05/2022. This benefit has been received and acknowledged and therefore, the instant claims receive the effective filing date of 07/05/2022. Information Disclosure Statement Information Disclosure Statement received 06/16/2026 has been reviewed and considered. 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 06/16/2026 has been entered. 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 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. Claims 1, 3-4, 7-8, 10-14 and 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., law of nature, a natural phenomenon, or an abstract idea) without significantly more. Under Step 1 of the Subject Matter Eligibility Test for Products and Processes, the claims must be directed to one of the four statutory categories (see MPEP 2106.03). All the claims are directed to one of the four statutory categories (YES). Under Step 2A of the Subject Matter Eligibility Test, it is determined whether the claims are directed to a judicially recognized exception (see MPEP 2106.04). Step 2A is a two-prong inquiry. Under Prong 1, it is determined whether the claim recites a judicial exception (YES). Taking Claim 14 as representative, the claim recites limitations that fall within the certain methods of organizing human activity groupings of abstract ideas, including: -A server for providing gift information in a messenger service, the server comprising: -a memory storing instructions; and -a processor configured to execute the instructions to: -receive from the second user a gift provision request for sending a gift to the first user, the gift provision request including information on a gift sender and a gift recipient; -generate gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status including at least a blinded state; -determine, using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; -in response to determining that the second user is the blocked friend: -set the status of the gift information to the blinded state, -generate blinded gift information in which partial information of the gift information is not shown, the partial information including at least a gift sender and gift details; -provide the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information [is provided]; -provide, together with the blinded gift information, information enabling the first user terminal to display an information check interface for requesting provision of the partial information not shown in the blinded gift information; and -in response to receiving, via the information check interface, a request for provision of the partial information, provide the partial information to the first user terminal such that the first user terminal displays the partial information, without changing the status of the gift information The above limitations recite the concept of providing full or partial gift information to a user from a friend. The above limitations fall within the “Certain Methods of Organizing Human Activity” groupings of abstract ideas, enumerated in MPEP 2106.04(a). Certain methods of organizing human activity include: fundamental economic principles or practices (including hedging, insurance, and mitigating risk) commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; and business relations) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) The limitations of receive from the second user a gift provision request for sending a gift to the first user, the gift provision request including information on a gift sender and a gift recipient; determine, using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; in response to determining that the second user is the blocked friend: set the status of the gift information to the blinded state, and generate blinded gift information in which partial information of the gift information is not shown, the partial information including at least a gift sender and gift details are processes that, under their broadest reasonable interpretation, cover a commercial interaction. For example, “receive,” “determine,” “set,” and “generate,” in the context of this claim encompass advertising, and marketing or sales activities. Similarly, the limitations of a server for providing gift information in a messenger service, the server comprising: generate gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status including at least a blinded state; provide the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information [is provided]; provide, together with the blinded gift information, information enabling the first user terminal to display an information check interface for requesting provision of the partial information not shown in the blinded gift information; and in response to receiving, via the information check interface, a request for provision of the partial information, provide the partial information to the first user terminal such that the first user terminal displays the partial information, without changing the status of the gift information, are processes that, under their broadest reasonable interpretation, cover a commercial interaction. That is, other than reciting that the providing of gift information is by a server, that the storing is in the memory, that the blinded gift information is provided to a first user terminal used by the first user, that the substitute information is displayed by the first user terminal, that the information provided enables the first user terminal to display an information check interface, that the receiving is via the information check interface, and that the partial information is provided to the first user terminal such that the first user terminal displays the partial information, nothing in the claim element precludes the step from practically being performed by people. For example, but for the “server,” “memory,” “first user terminal,” and “an information check interface,” language, “providing,” “generate,” “provide,” “provide,” “receiving,” and “provide” in the context of this claim encompasses advertising, and marketing or sales activities. Under Prong 2, it is determined whether the claim recites additional elements that integrate the exception into a practical application of the exception. This judicial exception is not integrated into a practical application (NO). -A server for providing gift information in a messenger service, the server comprising: -a memory storing instructions; and -a processor configured to execute the instructions to: -receive from the second user a gift provision request for sending a gift to the first user, the gift provision request including information on a gift sender and a gift recipient; -generate gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status including at least a blinded state; -determine, using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; -in response to determining that the second user is the blocked friend: -set the status of the gift information to the blinded state, -generate blinded gift information in which partial information of the gift information is not shown, the partial information including at least a gift sender and gift details; -provide the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information; -provide, together with the blinded gift information, information enabling the first user terminal to display an information check interface for requesting provision of the partial information not shown in the blinded gift information; and -in response to receiving, via the information check interface, a request for provision of the partial information, provide the partial information to the first user terminal such that the first user terminal displays the partial information, without changing the status of the gift information These limitations are not indicative of integration into a practical application because: The additional elements of claim 14 are recited at a high level of generality (i.e. as generic computing hardware) such that they amount to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea) as supported by paragraph [0068] of Applicant’s specification – “The processor 25 may control overall operations of the communication unit 21, the input unit 22, the output unit 23, and the memory 24 to execute an application related to the messenger service.” Specifically, the additional elements of a server, a memory storing instructions, a processor, a first user terminal, and an information check interface configured to execute the instructions are recited at a high-level of generality (i.e. as a generic processor performing the generic computer functions of receiving data, generating data, determining data, and providing data) such that they amount do no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. Further, the additional elements do no more than generally link the use of the judicial exception to a particular technological environment or field of use (such as computers or computing networks). Employing well-known computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not integrate the exception into a practical application. Additionally, the additional elements are insufficient to integrate the abstract idea into a practical application because the claim fails to i) reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, ii) apply the judicial exception with, or use the judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, iii) effect a transformation or reduction of a particular article to a different state or thing, or iv) apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Accordingly, the judicial exception is not integrated into a practical application. Under Step 2B, it is determined whether the claims recite additional elements that amount to significantly more than the judicial exception. The claims of the present application do not include additional elements that are sufficient to amount to significantly more than the judicial exception (NO). In the case of claim 14, taken individually or as a whole, the additional elements of claim 9 do not provide an inventive concept. As discussed above under step 2A (prong 2) with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed functions amount to no more than a general link to a technological environment. Even considered as an ordered combination (as a whole), the additional elements do not add anything significantly more than when considered individually. Claim 1 is a method reciting similar functions as claim 14. Examiner notes that claim 1 recites the additional elements of a server, a processor, a memory, a communication unit, a first user terminal, and an information check interface, however, claim 1 does not qualify as eligible subject matter for similar reasons as claim 14 indicated above. Claim 13 is a non-transitory computer readable recording medium reciting similar functions as claim 14. Examiner notes that claim 13 recites the additional elements of non-transitory computer readable recording medium storing instructions, one or more processors, a communication unit, a first user terminal, and a user interface, however, claim 13 does not qualify as eligible subject matter for similar reasons as claim 14 indicated above. Therefore, claims 1 and 13-14 do not provide an inventive concept and do not qualify as eligible subject matter. Dependent claims 3-4, 7-8, 10-12 and 21, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. § 101 because they do not add “significantly more” to the abstract idea. More specifically, dependent claims 3-4, 7-8, 10-12 and 21 further fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas in that they recite commercial interactions. Dependent claims 3-4, 7-8, 10-12 do not recite any farther additional elements, and as such are not indicative of integration into a practical application for at least similar reasons discussed above. Dependent claim 21 recites the additional element of the first user terminal but similar to the analysis under prong two of Step 2A these additional elements are used as a tool to perform the abstract idea. As such, under prong two of Step 2A, claims 3-4, 7-8, 10-12 and 21 are not indicative of integration into a practical application for at least similar reasons as discussed above. Thus, dependent claims 3-4, 7-8, 10-12 and 21 are “directed to” an abstract idea. Next, under Step 2B, similar to the analysis of claims 1 and 13-14, dependent claims 3-4, 7-8, 10-12 and 21 when analyzed individually and as an ordered combination, merely further define the commonplace business method (i.e. providing full or partial gift information to a user from a friend) being applied on a general-purpose computer and, therefore, do not amount to significantly more than the abstract idea itself. Accordingly, the Examiner concludes that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. The analysis above applies to all statutory categories of invention. Claim 22 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., law of nature, a natural phenomenon, or an abstract idea) without significantly more. Under Step 1 of the Subject Matter Eligibility Test for Products and Processes, the claims must be directed to one of the four statutory categories (see MPEP 2106.03). All the claims are directed to one of the four statutory categories (YES). Under Step 2A of the Subject Matter Eligibility Test, it is determined whether the claims are directed to a judicially recognized exception (see MPEP 2106.04). Step 2A is a two-prong inquiry. Under Prong 1, it is determined whether the claim recites a judicial exception (YES). Taking Claim 22 as representative, the claim recites limitations that fall within the certain methods of organizing human activity groupings of abstract ideas, including: -A method of providing gift information by a server in a messenger service, the server comprising a processor, a memory and a communication unit, the method comprising: -receiving, by the communication unit, from a second user, a gift provision request for sending a gift to a first user, the gift provision request including information on a gift sender and a gift recipient; -generating, by the processor, gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status being one of a normal state, a blinded state, an unblinded state, or a deleted state; -determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; -in response to determining that the second user is the blocked friend: -setting the status of the gift information to the blinded state, -generating blinded gift information in which part of the gift information, including at least one of a gift sender, gift details, or a gift sent time, is not shown or is replaced with another image or wording, and -providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information [is provided]; and -in response to receiving, from the first user, a delete request for the blinded gift information: -changing the status of the gift information from the blinded state to the deleted state, -causing the first user terminal to display [of] information indicating that the gift information has been deleted without showing the partial information not shown in the blinded gift information, and -providing, to the second user, decline information indicating that the first user declines the gift in response to the gift provision request, wherein the decline information does not indicate whether the second user is the blocked friend set by the first user or whether the gift information was in the blinded state The above limitations recite the concept of providing full or partial gift information to a user from a friend. The above limitations fall within the “Certain Methods of Organizing Human Activity” groupings of abstract ideas, enumerated in MPEP 2106.04(a). Certain methods of organizing human activity include: fundamental economic principles or practices (including hedging, insurance, and mitigating risk) commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; and business relations) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) The limitations of in response to determining that the second user is the blocked friend: setting the status of the gift information to the blinded state, generating blinded gift information in which part of the gift information, including at least one of a gift sender, gift details, or a gift sent time, is not shown or is replaced with another image or wording, and in response to receiving, from the first user, a delete request for the blinded gift information: changing the status of the gift information from the blinded state to the deleted state, providing, to the second user, decline information indicating that the first user declines the gift in response to the gift provision request, wherein the decline information does not indicate whether the second user is the blocked friend set by the first user or whether the gift information was in the blinded state are processes that, under their broadest reasonable interpretation, cover a commercial interaction. For example, “setting,” “generating,” “receiving,” “delete,” “changing,” and “providing,” in the context of this claim encompass advertising, and marketing or sales activities. Similarly, the limitations of a method of providing gift information by a server in a messenger service, the server comprising a processor, a memory and a communication unit, the method comprising: receiving, by the communication unit, from a second user, a gift provision request for sending a gift to a first user, the gift provision request including information on a gift sender and a gift recipient; generating, by the processor, gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status being one of a normal state, a blinded state, an unblinded state, or a deleted state; determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information [is provided]; and causing the first user terminal to display [of] information indicating that the gift information has been deleted without showing the partial information not shown in the blinded gift information are processes that, under their broadest reasonable interpretation, cover a commercial interaction. That is, other than reciting that the providing is by a server that comprises a processor, a memory and a communication unit, that the receiving is by the communication unit, that the generating is by the processor, that the storing is in the memory, that the determining is by the processor, that the providing is to a first user terminal, that the substitute information is displayed by the first user terminal, and that the displaying is by the first user terminal, nothing in the claim element precludes the step from practically being performed by people. For example, but for the “server,” “processor,” “memory,” “communication unit,” and “first user terminal,” language, “providing,” “receiving,” “generating,” “determining,” “providing,” and “causing display” in the context of this claim encompasses advertising, and marketing or sales activities. Under Prong 2, it is determined whether the claim recites additional elements that integrate the exception into a practical application of the exception. This judicial exception is not integrated into a practical application (NO). -A method of providing gift information by a server in a messenger service, the server comprising a processor, a memory and a communication unit, the method comprising: -receiving, by the communication unit, from a second user, a gift provision request for sending a gift to a first user, the gift provision request including information on a gift sender and a gift recipient; -generating, by the processor, gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status being one of a normal state, a blinded state, an unblinded state, or a deleted state; -determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; -in response to determining that the second user is the blocked friend: -setting the status of the gift information to the blinded state, -generating blinded gift information in which part of the gift information, including at least one of a gift sender, gift details, or a gift sent time, is not shown or is replaced with another image or wording, and -providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information; and -in response to receiving, from the first user, a delete request for the blinded gift information: -changing the status of the gift information from the blinded state to the deleted state, -causing the first user terminal to display information indicating that the gift information has been deleted without showing the partial information not shown in the blinded gift information, and -providing, to the second user, decline information indicating that the first user declines the gift in response to the gift provision request, wherein the decline information does not indicate whether the second user is the blocked friend set by the first user or whether the gift information was in the blinded state These limitations are not indicative of integration into a practical application because: The additional elements of claim 22 are recited at a high level of generality (i.e. as generic computing hardware) such that they amount to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea) as supported by paragraph [0068] of Applicant’s specification – “The processor 25 may control overall operations of the communication unit 21, the input unit 22, the output unit 23, and the memory 24 to execute an application related to the messenger service.” Specifically, the additional elements of a server, a processor, a memory, a communication unit, and a first user terminal (i.e. as a generic processor performing the generic computer functions of receiving data, generating data, determining data, setting data, providing data, changing data, causing display of data, and providing data) such that they amount do no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. Further, the additional elements do no more than generally link the use of the judicial exception to a particular technological environment or field of use (such as computers or computing networks). Employing well-known computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not integrate the exception into a practical application. Additionally, the additional elements are insufficient to integrate the abstract idea into a practical application because the claim fails to i) reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, ii) apply the judicial exception with, or use the judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, iii) effect a transformation or reduction of a particular article to a different state or thing, or iv) apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Accordingly, the judicial exception is not integrated into a practical application. Under Step 2B, it is determined whether the claims recite additional elements that amount to significantly more than the judicial exception. The claims of the present application do not include additional elements that are sufficient to amount to significantly more than the judicial exception (NO). In the case of claim 22, taken individually or as a whole, the additional elements of claim 9 do not provide an inventive concept. As discussed above under step 2A (prong 2) with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed functions amount to no more than a general link to a technological environment. Even considered as an ordered combination (as a whole), the additional elements do not add anything significantly more than when considered individually. Therefore, claim 22 does not provide an inventive concept and do not qualify as eligible subject matter. 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1, 4, 7-8, 10-11, 13-14, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Uhll et al. (US 2019/0386951 A1), hereinafter Uhll, in view of Wynn et al. (US 2008/0005325 A1), hereinafter Wynn. Regarding claim 1, Uhll discloses a method of providing gift information by a server in a messenger service, the server comprising a processor, a memory and a communication unit, the method comprising: -receiving, by the communication unit, from a second user, a gift provision request for sending a gift to a first user, the gift provision request including information on a gift sender and a gift recipient (Uhll, see at least: “home menu 32 may include links to the home page, to give wishes [i.e. receiving from a second user a gift provision request], to get wishes, to a how it works section and to a freebies section” [0065] and “The manner in which other items such as gifts may be attached to a wish or message is now described with reference to FIG. 32. As shown, the create a wish tool bar 106 may include an attach gift icon 134 [i.e. a gift provision request]. By selecting this icon 134, a gift library 380 may be displayed which allows the user to add a gift through the gift manager component 1012 (shown in FIG. 1) [i.e. for sending a gift to a first user]. The types of gifts available may vary” [0138] and “For example, as shown in FIG. 32, the gift library 380 may include images of digital gift cards or gift certificates 382 that a user may add to a wish [i.e. for sending a gift to a first user]. The digital gift cards 382 may include any suitable prepaid stored-value money card issued, for example, by a merchant, retailer, bank, credit card, airline and the like. The user may customize the digital gift card by selecting the merchant and the gift cash value amount” [0139] and “the GUIs of message creation process 100 may allow a user to add/select wish recipients [i.e. the gift provision request including information on a gift recipient], view wish idea templates, record and/or upload pictures, videos, audio, search and select stock pictures, videos, audio, create and customize a wish content, preview a wish, save a wish to wish vault, schedule delivery and/or unlock date of a wish, add a gift, select collaborator and receiver permissions, select privacy and sharing settings, delete a wish and other steps” [0074] and “The system of the invention also includes various databases, servers, connections and/or other infrastructure hardware to provide the appropriate platform from which to send messages and wishes [i.e. receiving, by the communication unit]” [0047] and Fig. 34 shows an example message to be included with the gift request including who the gift is from [i.e. the gift provision request including information on a gift sender]); -generating, by the processor, gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status including at least a blinded state (Uhll, see at least: “The schedule and send page 420 may also include one or more of the following: an edit button 450 allowing the user to navigate back in the system to message creation stage 1 in order to edit the wish, a preview button 452 allowing the user to view a wish preview as in preview stage 2, a delete button 454 allowing the user to delete the wish, a save button 456 allowing the user to save the wish to the wish vault [i.e. generating, by the processor, gift information corresponding to the gift provision request and storing, in the memory, the gift information]” [0157] and “the GUIs of message creation process 100 may allow a user to add/select wish recipients [i.e. the gift information including the gift recipient], view wish idea templates, record and/or upload pictures, videos, audio, search and select stock pictures, videos, audio, create and customize a wish content, preview a wish, save a wish to wish vault, schedule delivery and/or unlock date of a wish, add a gift, select collaborator and receiver permissions, select privacy and sharing settings, delete a wish and other steps” [0074] and “system 10 may generate and send an e-mail to the recipient(s) including, for example, wish status information such as, date created, unlock date, lock status date, created by, and/or recipient list [i.e. the gift information including the gift sender and the gift recipient, and a status of the gift information, the status including at least a blinded state]. It may allow the recipient to create an account, accept/reject a wish, and/or edit wish settings” [0161] and “the system may facilitate selecting, purchasing, storing and sending one or more gifts” [0011] and Fig. 34 shows an example message to be included with the gift request including who the gift is from [i.e. the gift information including the gift sender]); -a blocked friend set by the first user (Uhll, see at least: “Each wish data field 510 may also include one or more wish status icons 512 indicating the status of the wish in terms of whether there was any gift attached, whether the wish is locked or unlocked, whether there are any attachments. The “!” icon may indicate that there is an issue for the user to address. For example, the issue could be that they forgot to “send”, did not yet schedule a send date, or perhaps the recipient rejected their wish, blocked them [i.e. a blocked friend set by the first user] or never opened the e-mail notification” [0167]); -setting the status of the gift information to the blinded state (Uhll, see at least: “the schedule unlock date box 422 may include various options to change the locked/unlocked status of a wish or message [i.e. setting the status of the gift information to the blinded state]” [0153]), -information being gift information and the gift information including at least a gift sender and gift details (Uhll, see at least: “the GUIs of message creation process 100 may allow a user to add/select wish recipients, view wish idea templates, record and/or upload pictures, videos, audio, search and select stock pictures, videos, audio, create and customize a wish content, preview a wish, save a wish to wish vault, schedule delivery and/or unlock date of a wish, add a gift [i.e. information being gift information], select collaborator and receiver permissions, select privacy and sharing settings, delete a wish and other steps” [0074] and Fig. 39 displays an interface with the sent messages including a gift sender and the occasion for the gift (e.g. ‘Happy 40th Birthday!’) [i.e. gift information including at least a gift sender and gift details]); -providing, together with the blinded gift information, information enabling the first user terminal to display an information check interface for provision of the partial information not shown in the blinded gift information (Uhll, see at least: “Each of the wishes in the wish inbox 504 may include a wish data field 510, which may include a received wish action menu 520, which, when expanded provides a list of actions to apply to the received wish. For example, the received wish action menu 520 may provide options to accept the wish, reject the wish, reply to the wish, schedule, view locked/unlocked status, block sender and designate as favorite” [0172] and “The wish inbox 504 may include a listing of all the wishes received by the user. As shown in FIG. 39, the wish inbox 504 may be arranged much the same as the wish outbox 502 and include many of the same features described above with respect to the wish outbox 502” [0171] and Fig. 39 displays an interface [i.e. via the information check interface] with the option to preview a message, in menu 520, that is only partially shown in the inbox [i.e. providing, together with the blinded gift information, information enabling the first user terminal to display an information check interface for provision of the partial information not shown in the blinded gift information]); and -in response to receiving a request for provision of the partial information, providing the partial information to the first user terminal such that the first user terminal displays the partial information, without changing the status of the gift information (Uhll, see at least: “Each of the wishes in the wish inbox 504 may include a wish data field 510, which may include a received wish action menu 520, which, when expanded provides a list of actions to apply to the received wish. For example, the received wish action menu 520 may provide options to accept the wish, reject the wish, reply to the wish, schedule, view locked/unlocked status, block sender and designate as favorite” [0172] and “The wish inbox 504 may include a listing of all the wishes received by the user. As shown in FIG. 39, the wish inbox 504 may be arranged much the same as the wish outbox 502 and include many of the same features described above with respect to the wish outbox 502” [0171] and Fig. 39 displays an interface with the option to preview a blinded message in the inbox [i.e. in response to receiving a request for provision of the partial information to the first user terminal such that the first user terminal displays the partial information, without changing the status of the gift information] Examiner notes that a ‘preview’ only displays partial information and does not unlock a locked message so the status remains unchanged). Uhll does not explicitly disclose determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; setting the status of the information to the blinded state being in response to determining that the second user is the blocked friend; in response to determining that the second user is the blocked friend: generating blinded information in which partial information of the information is not shown, the partial information including at least a sender and details; in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information; the information check interface being for requesting provision of the partial information not shown in the blinded gift information; and receiving the request for provision of the partial information via the information check interface. Wynn, however, teaches sending messages to a contact (i.e. abstract), including the known technique of determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user (Wynn, see at least: “for a received message, the extracted information can include an identifier of the sender. At step 215, a contact list, such as the shared allow/block contact listed discussed further below, can be checked [i.e. by the processor using information on blocked friends set by the first user], based on the extracted identifier, to determine if the sender is on the contact list, and to determine the allow or block status of the sender if he or she is on the contact list [i.e. determining whether the second user is a blocked friend set by the first user]” [0042] and “At step 1330, the monitored user adds new contacts via an appropriate user interface [i.e. information on blocked friends set by the first user] and, at step 1340, the authorized user adds new contacts via an appropriate user interface” [0073] and “FIG. 13a illustrates a process for obtaining contact information for a shared allow/block contact list [i.e. information on blocked friends set by the first user]” [0022]); the known technique of in response to determining that the second user is the blocked friend: setting the status of the information to the blinded state (Wynn, see at least: “At step 210, information is extracted from messages of the monitored user, such as received and/or sent messages. For example, for a received message, the extracted information can include an identifier of the sender. At step 215, a contact list, such as the shared allow/block contact listed discussed further below, can be checked, based on the extracted identifier, to determine if the sender is on the contact list, and to determine the allow or block status of the sender [i.e. in response to determining that the second user is the blocked friend:] if he or she is on the contact list” [0042] and “if a blocking feature has been configured by the authorized user, the messages which have been found to be restricted are blocked so that the monitored user cannot access them. At step 260, the blocked messages are intercepted and stored under access-control [i.e. setting the status of the gift information to the blinded state], before they can be received and made available to the monitored user” [0045]); the known technique of, in response to determining that the second user is the blocked friend: generating blinded information in which partial information of the information is not shown, the partial information including at least a sender and details (Wynn, see at least: “At step 210, information is extracted from messages of the monitored user, such as received and/or sent messages. For example, for a received message, the extracted information can include an identifier of the sender. At step 215, a contact list, such as the shared allow/block contact listed discussed further below, can be checked, based on the extracted identifier, to determine if the sender is on the contact list, and to determine the allow or block status of the sender [i.e. in response to determining that the second user is the blocked friend: generating blinded information in which partial information of the information is not shown] if he or she is on the contact list” [0042] and “The text "SYSTEM" in the "From" field indicates that the monitoring and restricting functionality has provided the entry 810. The subject "BLOCKED" indicates that an e-mail message has been blocked [i.e. in which partial information of the information is not shown, the partial information including at least a sender and details]” [0060] and Fig 9 displays that the blocked message displays that "SYSTEM" sent the message rather than the blocked sender and does not display the content of the message [i.e. generating blinded information in which partial information of the information is not shown, the partial information including at least a sender and details]); the known technique of, in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information (Wynn, see at least: “The text "SYSTEM" in the "From" field indicates that the monitoring and restricting functionality has provided the entry 810. The subject "BLOCKED" indicates that an e-mail message has been blocked [i.e. in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information]” [0060] and Fig 9 displays that the blocked message displays that "SYSTEM" sent the message rather than the blocked sender and “SYSTEM MSG: Blocked e-mail attached” is displayed rather than displaying the content of the message [i.e. providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information]); the known technique of providing, together with the blinded gift information, information enabling the first user terminal to display an information check interface for requesting provision of the partial information not shown in the blinded gift information (Wynn, see at least: “FIG. 8 illustrates an inbox of an e-mail application of a monitored user showing a second format of a blocked message. In this format, the entry 810 for the blocked e-mail message provides essentially no information regarding the content of the e-mail message other than the fact that an e-mail message has been received and blocked. The date and time the e-mail message was received can also be provided. The text "SYSTEM" in the "From" field indicates that the monitoring and restricting functionality has provided the entry 810. The subject "BLOCKED" indicates that an e-mail message has been blocked [i.e. providing, together with the blinded gift information]” [0060] and “The user interface 900 appears when the monitored user opens a blocked e-mail message such as by selecting, e.g., double-clicking, the entry 810 of FIG. 8 [i.e. information enabling the first user terminal to display an information check interface]. The user interface 900 includes a header portion 910 which provides the sender, date, recipient and subject, and an indication that there is a file attached to the e-mail message. In this case, the monitoring and restricting functionality can generate a new e-mail message which includes the blocked message as an attachment … Additionally, an indicia 925, titled "Request access", can be selected by the monitored user to request access to the blocked e-mail message [i.e. display an information check interface for requesting provision of the partial information not shown in the blinded gift information]” [0062]); and the known technique of in response to receiving, via the information check interface, a request for provision of the partial information, providing the partial information to the first user terminal such that the first user terminal displays the partial information (Wynn, see at least: “The user interface 900 appears when the monitored user opens a blocked e-mail message such as by selecting, e.g., double-clicking, the entry 810 of FIG. 8 [i.e. information enabling the first user terminal to display an information check interface]. The user interface 900 includes a header portion 910 which provides the sender, date, recipient and subject, and an indication that there is a file attached to the e-mail message. In this case, the monitoring and restricting functionality can generate a new e-mail message which includes the blocked message as an attachment … Additionally, an indicia 925, titled "Request access", can be selected by the monitored user to request access to the blocked e-mail message [i.e. in response to receiving, via the information check interface, a request for provision of the partial information]” [0062] and “the authorized user can select an "Allow access" 1105 button to allow the monitored user to access the blocked e-mail message. Selection of this option causes the unblocked e-mail message to be provided to the monitored user's inbox, as indicated by the user interface 1200 of FIG. 12 [i.e. providing the partial information to the first user terminal such that the first user terminal displays the partial information]” [0068]). These known techniques are applicable to the method of Uhll as they both share characteristics and capabilities, namely, they are directed to sending messages to a contact. It would have been recognized that applying the known techniques of determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; in response to determining that the second user is the blocked friend: setting the status of the information to the blinded state; in response to determining that the second user is the blocked friend: generating blinded information in which partial information of the information is not shown, the partial information including at least a sender and details; in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information; providing, together with the blinded gift information, information enabling the first user terminal to display an information check interface for requesting provision of the partial information not shown in the blinded gift information; and in response to receiving, via the information check interface, a request for provision of the partial information, providing the partial information to the first user terminal such that the first user terminal displays the partial information, as taught by Wynn, to the teachings of Uhll would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar methods. Further, adding the modifications of determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; in response to determining that the second user is the blocked friend: setting the status of the information to the blinded state; in response to determining that the second user is the blocked friend: generating blinded information in which partial information of the information is not shown, the partial information including at least a sender and details; in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information; providing, together with the blinded gift information, information enabling the first user terminal to display an information check interface for requesting provision of the partial information not shown in the blinded gift information; and in response to receiving, via the information check interface, a request for provision of the partial information, providing the partial information to the first user terminal such that the first user terminal displays the partial information, as taught by Wynn, into the method of Uhll would have been recognized by those of ordinary skill in the art as resulting in an improved method that would prevent users from being exposed to inappropriate content (Wynn, [0001]). Regarding claim 4, Uhll in view if Wynn teaches the method of claim 1. Uhll further discloses: -wherein the partial information out of the gift information comprises at least one of sender information and gift details in the gift information (Uhll, see at least: Fig. 39 shows the received wishes in the wish inbox such as who it’s from [i.e. wherein the partial information out of the gift information comprises at least one of sender information and gift details in the gift information], a subject line, and part of a message). Regarding claim 7, Uhll in view if Wynn teaches the method of claim 1. Uhll further discloses: -in response to receiving a request for the state information from the first user, providing the state information to the first user (Uhll, see at least: “The wish inbox 504 may also include a search field 518 to search for received wishes by keyword, name, date and so forth. As illustrated in FIG. 40, an expand status box 514 [i.e. in response to receiving a request for the state information from the first user] may be opened to display the wish recipient(s) status [i.e. providing the state information to the first user], for example accepted, rejected, delivered, not delivered, viewed, blocked, and the like” [0173] and “The wish inbox 504 may include a listing of all the wishes received by the user [i.e. from the first user]” [0171]). Regarding claim 8, Uhll in view if Wynn teaches the method of claim 1. Uhll further discloses: -in response to receiving a request to provide the partial information out of the gift information from the first user, providing the first user with the partial information out of the gift information (Uhll, see at least: “The wish inbox 504 may include a listing of all the wishes received by the user” [0171] and “Each of the wishes in the wish inbox 504 may include a wish data field 510, which may include a received wish action menu 520, which, when expanded provides a list of actions to apply to the received wish. For example, the received wish action menu 520 may provide options to accept the wish, reject the wish, reply to the wish, schedule, view locked/unlocked status, block sender and designate as favorite” [0172] and Fig. 39 shows the received wishes in the wish inbox such as who it’s from, a subject line, and part of a message, as well as, a selectable option of ‘view’ [i.e. in response to receiving a request to provide the partial information out of the gift information from the first user] to view sent wish [i.e. providing the first user with the partial information out of the gift information]). Uhll does not explicitly disclose receiving the request to provide the partial information out of the gift information being from the first user before receiving the unblind request or the delete request. Wynn, however, teaches sending messages to a contact (i.e. abstract), including the known technique of, in response to receiving a request to provide the partial information out of the message information from the first user before receiving the unblind request or the delete request, providing the first user with the partial information out of the message information (Wynn, see at least: “the monitored user requests access to a blocked message. For example, this can be performed using the user interface 900 of FIG. 9 which includes a "Request access" link 925 which appears when a blocked e-mail message is opened [i.e. in response to receiving a request to provide the partial information out of the message information from the first user before receiving the unblind request or the delete request]” [0049] and Figs 8-9 show that when the recipient selects the blocked message to open [i.e. in response to receiving a request to provide the partial information out of the message information from the first user], partial information such as the sender is shown [i.e. providing the first user with the partial information out of the message information], as well as, options to delete the message and request access to the full message [i.e. before receiving the unblind request or the delete request]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Uhll with Wynn for the reasons identified above with respect to claim 1. Regarding claim 10, Uhll in view if Wynn teaches the method of claim 1. Uhll further discloses: -in response to receiving a request to delete the blinded gift information from the first user, providing the second user with decline information of the first user in response to the gift provision request (Uhll, see at least: “Each wish data field 510 may include a wish action menu 516, which, when expanded provides a list of actions to apply to the wish. For example, the wish action menu 516 may provide options to edit the wish, preview the wish, copy the wish, attach a document to the wish, attach a gift to the wish, rescind the wish, delete the wish from the wish outbox 502 [i.e. in response to receiving a request to delete the blinded gift information from the first user], designate the wish as a favorite and/or schedule the wish for delivery” [0169] and “The wish inbox 504 may also include a search field 518 to search for received wishes by keyword, name, date and so forth. As illustrated in FIG. 40, an expand status box 514 may be opened to display the wish recipient(s) status, for example accepted, rejected, delivered, not delivered, viewed, blocked, and the like [i.e. providing the second user with decline information of the first user in response to the gift provision request]” [0173] and “The wish inbox 504 may include a listing of all the wishes received by the user [i.e. from the first user]” [0171] and Fig. 39 displays that the received wish includes the option to delete the wish and associated gift [i.e. in response to receiving a request to delete the blinded gift information from the first user]). Regarding claim 11, Uhll in view if Wynn teaches the method of claim 1. Uhll further discloses: -providing information on an unblinding available period for the blinded gift information (Uhll, see at least: “the schedule and send page 420 may include a schedule unlock date box 422. As described above, system 10 may be used to create, store and later send wishes at some time in the future. The unlock date may be the date/time when a currently time-locked wish may become unlocked and delivered and/or otherwise made accessible to the recipient [i.e. providing information on an unblinding available period for the blinded gift information]” [0151] and “system 10 may generate and send an e-mail to the recipient(s) including, for example, wish status information such as, date created, unlock date [i.e. i.e. providing information on an unblinding available period for the blinded gift information], lock status date, created by, and/or recipient list” [0161]), and -in response to receiving the unblind request and the delete request from the first user within the unblinding available period, providing the second user with decline information of the first user for the gift provision request (Uhll, see at least: “Each wish data field 510 may include a wish action menu 516, which, when expanded provides a list of actions to apply to the wish. For example, the wish action menu 516 may provide options to edit the wish, preview the wish, copy the wish, attach a document to the wish, attach a gift to the wish, rescind the wish, delete the wish from the wish outbox 502 [i.e. in response to receiving a request to delete the blinded gift information from the first user], designate the wish as a favorite and/or schedule the wish for delivery” [0169] and “the schedule and send page 420 may include a schedule unlock date box 422. As described above, system 10 may be used to create, store and later send wishes at some time in the future. The unlock date may be the date/time when a currently time-locked wish may become unlocked and delivered and/or otherwise made accessible to the recipient [i.e. within the unblinding available period]” [0151] “Through the wish vault GUIs 500, the user may: create new wishes and/or edit existing wishes, search, sort, and/or view existing wishes (for example, by favorites, recipient, sent date, not yet sent, unlock date, accepted, not accepted, viewed, unlocked by not viewed, not yet scheduled, upcoming, past, received and the like), view user's wish dashboard, view wish dates and status notifications” [0163] and “The wish inbox 504 may also include a search field 518 to search for received wishes by keyword, name, date and so forth. As illustrated in FIG. 40, an expand status box 514 may be opened to display the wish recipient(s) status, for example accepted, rejected [i.e. providing the second user with decline information of the first user for the gift provision request], delivered, not delivered, viewed [i.e. in response to receiving the unblind request], blocked, and the like” [0173] and “The wish inbox 504 may include a listing of all the wishes received by the user [i.e. from the first user]” [0171] and Fig. 39 displays that the received wish includes the option to delete the wish and associated gift [i.e. and the delete request from the first user]). Claim 13 recites limitations directed towards a non-transitory computer readable recording medium storing instructions, when executed by one or more processors, configured to perform the method (see, Uhll, [0047]). The limitations recited in claim 13 are parallel in nature to those addressed above for claim 1, and are therefore rejected for those same reasons set forth above in claim 1. Claim 14 recites limitations directed towards a server for providing gift information in a messenger service, the server comprising: a memory storing instructions; and a processor configured to execute the instructions (see, Uhll, [0047]). The limitations recited in claim 14 are parallel in nature to those addressed above for claim 1, and are therefore rejected for those same reasons set forth above in claim 1. Regarding claim 21, Uhll in view if Wynn teaches the method of claim 1. Uhll further discloses: -the gift information (Uhll, see at least: “the GUIs of message creation process 100 may allow a user to add/select wish recipients, view wish idea templates, record and/or upload pictures, videos, audio, search and select stock pictures, videos, audio, create and customize a wish content, preview a wish, save a wish to wish vault, schedule delivery and/or unlock date of a wish, add a gift [i.e. the gift information], select collaborator and receiver permissions, select privacy and sharing settings, delete a wish and other steps” [0074]). Uhll does not explicitly disclose in response to determining that the unblind request is received within an unblinding available period for the blinded portion of the gift information, transmitting to the first user terminal the partial information of the gift information unblocked from the blinded portion of the gift information. Wynn, however, teaches sending messages to a contact (i.e. abstract), including the known technique of, in response to determining that the unblind request is received within an unblinding available period for the blinded portion of the information, transmitting to the first user terminal the partial information of the information unblocked from the blinded portion of the information (Wynn, see at least: “a determination is made as to whether a message meets a restriction condition. The message represents any type of communication which is received and/or sent by the computer host of the monitored user. Examples include e-mail messages, instant messaging messages, telephony messages, messaging from web-based gaming and the like. The restriction can meet various goals. For example, a time/date restriction can be imposed to prevent the monitored user from sending and/or receiving messages at certain times of the day or certain days of the week [i.e. in response to determining that the unblind request is received within an unblinding available period for the blinded portion of the information]” [0043] and “the monitored user requests access to a blocked message. For example, this can be performed using the user interface 900 of FIG. 9 which includes a "Request access" link 925 which appears when a blocked e-mail message is opened [i.e. the unblind request]” [0049] and “if the authorized user decides to allow access, such as by selection of an "Allow access" button 1105 (FIG. 11), the blocked message is retrieved and provided to the monitored user (step 340) [i.e. transmitting to the first user terminal the partial information of the information unblocked from the blinded portion of the information]” [0051]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Uhll with Wynn for the reasons identified above with respect to claim 1. Regarding claim 22, Uhll discloses a method of providing gift information by a server in a messenger service, the server comprising a processor, a memory and a communication unit, the method comprising: -receiving, by the communication unit, from a second user, a gift provision request for sending a gift to a first user, the gift provision request including information on a gift sender and a gift recipient (Uhll, see at least: “home menu 32 may include links to the home page, to give wishes [i.e. receiving from a second user a gift provision request], to get wishes, to a how it works section and to a freebies section” [0065] and “The manner in which other items such as gifts may be attached to a wish or message is now described with reference to FIG. 32. As shown, the create a wish tool bar 106 may include an attach gift icon 134 [i.e. a gift provision request]. By selecting this icon 134, a gift library 380 may be displayed which allows the user to add a gift through the gift manager component 1012 (shown in FIG. 1) [i.e. for sending a gift to a first user]. The types of gifts available may vary” [0138] and “For example, as shown in FIG. 32, the gift library 380 may include images of digital gift cards or gift certificates 382 that a user may add to a wish [i.e. for sending a gift to a first user]. The digital gift cards 382 may include any suitable prepaid stored-value money card issued, for example, by a merchant, retailer, bank, credit card, airline and the like. The user may customize the digital gift card by selecting the merchant and the gift cash value amount” [0139] and “the GUIs of message creation process 100 may allow a user to add/select wish recipients [i.e. the gift provision request including information on a gift recipient], view wish idea templates, record and/or upload pictures, videos, audio, search and select stock pictures, videos, audio, create and customize a wish content, preview a wish, save a wish to wish vault, schedule delivery and/or unlock date of a wish, add a gift, select collaborator and receiver permissions, select privacy and sharing settings, delete a wish and other steps” [0074] and “The system of the invention also includes various databases, servers, connections and/or other infrastructure hardware to provide the appropriate platform from which to send messages and wishes [i.e. receiving, by the communication unit]” [0047] and Fig. 34 shows an example message to be included with the gift request including who the gift is from [i.e. the gift provision request including information on a gift sender]); -generating, by the processor, gift information corresponding to the gift provision request and storing, in the memory, the gift information including the gift sender and the gift recipient, and a status of the gift information, the status being one of a normal state, a blinded state, an unblinded state, or a deleted state (Uhll, see at least: “The schedule and send page 420 may also include one or more of the following: an edit button 450 allowing the user to navigate back in the system to message creation stage 1 in order to edit the wish, a preview button 452 allowing the user to view a wish preview as in preview stage 2, a delete button 454 allowing the user to delete the wish, a save button 456 allowing the user to save the wish to the wish vault [i.e. generating, by the processor, gift information corresponding to the gift provision request and storing, in the memory, the gift information]” [0157] and “the GUIs of message creation process 100 may allow a user to add/select wish recipients [i.e. the gift information including the gift recipient], view wish idea templates, record and/or upload pictures, videos, audio, search and select stock pictures, videos, audio, create and customize a wish content, preview a wish, save a wish to wish vault, schedule delivery and/or unlock date of a wish, add a gift, select collaborator and receiver permissions, select privacy and sharing settings, delete a wish and other steps” [0074] and “system 10 may generate and send an e-mail to the recipient(s) including, for example, wish status information such as, date created, unlock date, lock status date, created by, and/or recipient list [i.e. the gift information including the gift sender and the gift recipient, and a status of the gift information, the status being one of a normal state, a blinded state, an unblinded state, or a deleted state]. It may allow the recipient to create an account, accept/reject a wish, and/or edit wish settings” [0161] and “the system may facilitate selecting, purchasing, storing and sending one or more gifts” [0011] and Fig. 34 shows an example message to be included with the gift request including who the gift is from [i.e. the gift information including the gift sender]); - a blocked friend set by the first user (Uhll, see at least: “Each wish data field 510 may also include one or more wish status icons 512 indicating the status of the wish in terms of whether there was any gift attached, whether the wish is locked or unlocked, whether there are any attachments. The “!” icon may indicate that there is an issue for the user to address. For example, the issue could be that they forgot to “send”, did not yet schedule a send date, or perhaps the recipient rejected their wish, blocked them [i.e. a blocked friend set by the first user] or never opened the e-mail notification” [0167]); -setting the status of the gift information to the blinded state (Uhll, see at least: “the schedule unlock date box 422 may include various options to change the locked/unlocked status of a wish or message [i.e. setting the status of the gift information to the blinded state]” [0153]), -information being gift information and the gift information including at least one of a gift sender, gift details, or a gift sent time (Uhll, see at least: “the GUIs of message creation process 100 may allow a user to add/select wish recipients, view wish idea templates, record and/or upload pictures, videos, audio, search and select stock pictures, videos, audio, create and customize a wish content, preview a wish, save a wish to wish vault, schedule delivery and/or unlock date of a wish, add a gift [i.e. information being gift information], select collaborator and receiver permissions, select privacy and sharing settings, delete a wish and other steps” [0074] and Fig. 39 displays an interface with the sent messages including a gift sender [i.e. gift information including at least one of a gift sender, gift details, or a gift sent time]), and -in response to receiving, from the first user, a delete request for the blinded gift information: -changing the status of the gift information from the blinded state to the deleted state, causing the first user terminal to display information indicating that the gift information has been deleted without showing the partial information not shown in the blinded gift information (Uhll, see at least: “Each wish data field 510 may include a wish action menu 516, which, when expanded provides a list of actions to apply to the wish. For example, the wish action menu 516 may provide options to edit the wish, preview the wish, copy the wish, attach a document to the wish, attach a gift to the wish, rescind the wish, delete the wish from the wish outbox 502 [i.e. in response to receiving, from the first user, a delete request for the blinded gift information, changing the status of the gift information from the blinded state to the deleted state, and causing the first user terminal to display information indicating that the gift information has been deleted without showing the partial information not shown in the blinded gift information], designate the wish as a favorite and/or schedule the wish for delivery” [0169] and “The wish inbox 504 may include a listing of all the wishes received by the user. As shown in FIG. 39, the wish inbox 504 may be arranged much the same as the wish outbox 502 and include many of the same features described above with respect to the wish outbox 502 [i.e. from the first user]” [0171] and “The wish vault module 1030 that support GUIs 500 may be similar in some respects to an e-mail account. For example, it may provide a wish outbox 502, a wish inbox 504, deleted wishes [i.e. causing the first user terminal to display information indicating that the gift information has been deleted without showing the partial information not shown in the blinded gift information] and draft wishes” [0164] and Fig. 39), and -providing, to the second user, decline information indicating that the first user declines the gift in response to the gift provision request, wherein the decline information does not indicate whether the second user is the blocked friend set by the first user or whether the gift information was in the blinded state (Uhll, see at least: “The wish inbox 504 may also include a search field 518 to search for received wishes by keyword, name, date and so forth. As illustrated in FIG. 40, an expand status box 514 may be opened to display the wish recipient(s) status, for example accepted, rejected [i.e. providing, to the second user, decline information indicating that the first user declines the gift in response to the gift provision request], delivered, not delivered, viewed, blocked, and the like” [0173] and “The wish inbox 504 may include a listing of all the wishes received by the user [i.e. in response to receiving, from the first user, a delete request for the blinded gift information:]. As shown in FIG. 39, the wish inbox 504 may be arranged much the same as the wish outbox 502 and include many of the same features described above with respect to the wish outbox 502” [0171] and Fig. 39 displays that the received wish includes the option to delete the wish and associated gift [i.e. in response to receiving, from the first user, a delete request for the blinded gift information:] and Fig. 40 displays that the status of a particular recipient is ‘rejected’ [i.e. wherein the decline information does not indicate whether the second user is the blocked friend set by the first user or whether the gift information was in the blinded state]). Uhll does not explicitly disclose determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; setting the status of the information to the blinded state being in response to determining that the second user is the blocked friend: setting the status of the information to the blinded state; in response to determining that the second user is the blocked friend: generating blinded information in which part of the information, including at least one of a sender, details, or a sent time, is not shown or is replaced with another image or wording; and providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information. Wynn, however, teaches sending messages to a contact (i.e. abstract), including the known technique of determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user (Wynn, see at least: “for a received message, the extracted information can include an identifier of the sender. At step 215, a contact list, such as the shared allow/block contact listed discussed further below, can be checked [i.e. by the processor using information on blocked friends set by the first user], based on the extracted identifier, to determine if the sender is on the contact list, and to determine the allow or block status of the sender if he or she is on the contact list [i.e. determining whether the second user is a blocked friend set by the first user]” [0042] and “At step 1330, the monitored user adds new contacts via an appropriate user interface [i.e. information on blocked friends set by the first user] and, at step 1340, the authorized user adds new contacts via an appropriate user interface” [0073] and “FIG. 13a illustrates a process for obtaining contact information for a shared allow/block contact list [i.e. information on blocked friends set by the first user]” [0022]); the known technique of in response to determining that the second user is the blocked friend: setting the status of the information to the blinded state (Wynn, see at least: “At step 210, information is extracted from messages of the monitored user, such as received and/or sent messages. For example, for a received message, the extracted information can include an identifier of the sender. At step 215, a contact list, such as the shared allow/block contact listed discussed further below, can be checked, based on the extracted identifier, to determine if the sender is on the contact list, and to determine the allow or block status of the sender [i.e. in response to determining that the second user is the blocked friend:] if he or she is on the contact list” [0042] and “if a blocking feature has been configured by the authorized user, the messages which have been found to be restricted are blocked so that the monitored user cannot access them. At step 260, the blocked messages are intercepted and stored under access-control [i.e. setting the status of the gift information to the blinded state], before they can be received and made available to the monitored user” [0045]); the known technique of in response to determining that the second user is the blocked friend: generating blinded information in which part of the information, including at least one of a sender, details, or a sent time, is not shown or is replaced with another image or wording (Wynn, see at least: “At step 210, information is extracted from messages of the monitored user, such as received and/or sent messages. For example, for a received message, the extracted information can include an identifier of the sender. At step 215, a contact list, such as the shared allow/block contact listed discussed further below, can be checked, based on the extracted identifier, to determine if the sender is on the contact list, and to determine the allow or block status of the sender [i.e. in response to determining that the second user is the blocked friend generating blinded information in which part of the information is not shown or is replaced with another image or wording] if he or she is on the contact list” [0042] and “The text "SYSTEM" in the "From" field indicates that the monitoring and restricting functionality has provided the entry 810. The subject "BLOCKED" indicates that an e-mail message has been blocked [i.e. generating blinded information in which part of the information, including at least one of a sender, details, or a sent time, is not shown or is replaced with another image or wording]” [0060] and Fig 9 displays that the blocked message displays when the message was sent but not the content of the message and replaces the sender with ‘SYSTEM’ [i.e. generating blinded information in which part of the information, including at least one of a sender, details, or a sent time, is not shown or is replaced with another image or wording]); and the known technique of in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information (Wynn, see at least: “The text "SYSTEM" in the "From" field indicates that the monitoring and restricting functionality has provided the entry 810. The subject "BLOCKED" indicates that an e-mail message has been blocked [i.e. in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information]” [0060] and Fig 9 displays that the blocked message displays that "SYSTEM" sent the message rather than the blocked sender and “SYSTEM MSG: Blocked e-mail attached” is displayed rather than displaying the content of the message [i.e. providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information]). These known techniques are applicable to the method of Uhll as they both share characteristics and capabilities, namely, they are directed to sending messages to a contact. It would have been recognized that applying the known techniques of determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; in response to determining that the second user is the blocked friend: setting the status of the information to the blinded state; in response to determining that the second user is the blocked friend: generating blinded information in which part of the information, including at least one of a sender, details, or a sent time, is not shown or is replaced with another image or wording; and in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information, as taught by Wynn, to the teachings of Uhll would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar methods. Further, adding the modifications of determining, by the processor using information on blocked friends set by the first user, whether the second user is a blocked friend set by the first user; in response to determining that the second user is the blocked friend: setting the status of the information to the blinded state; in response to determining that the second user is the blocked friend: generating blinded information in which part of the information, including at least one of a sender, details, or a sent time, is not shown or is replaced with another image or wording; and in response to determining that the second user is the blocked friend: providing the blinded gift information to a first user terminal used by the first user such that the first user terminal displays substitute information in place of the partial information, as taught by Wynn, into the method of Uhll would have been recognized by those of ordinary skill in the art as resulting in an improved method that would prevent users from being exposed to inappropriate content (Wynn, [0001]). Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Uhll, in view of Wynn, in further view of Wolfe et al. (US 2014/0258055 A1), hereinafter Wolfe. Regarding claim 3, Uhll in view of Wynn teaches the method of claim 1. Uhll further discloses: -providing the first user with information on an unblinding available period for the blinded gift information (Uhll, see at least: “the schedule and send page 420 may include a schedule unlock date box 422. As described above, system 10 may be used to create, store and later send wishes at some time in the future. The unlock date may be the date/time when a currently time-locked wish may become unlocked and delivered and/or otherwise made accessible to the recipient [i.e. providing the first user with information on an unblinding available period for the blinded gift information]” [0151] and “system 10 may generate and send an e-mail to the recipient(s) including, for example, wish status information such as, date created, unlock date [i.e. providing the first user with information on an unblinding available period for the blinded gift information], lock status date, created by, and/or recipient list” [0161]). Uhll in view of Wynn does not explicitly teach, in response to failing to receive the unblind request and the delete request from the first user within the unblinding available period, changing the gift information to a cancelled state. Wolfe, however, teaches sending a gift to a recipient (i.e. abstract), including the known technique of in response to failing to receive the unblind request and the delete request from the first user within the unblinding available period, changing the gift information to a cancelled state (Wolfe, see at least: “The gift can be redeemable at the merchant using a recipient payment account that is independent of and not in control of a giver payment account, the gift having an associated policy and stored within a gift processing system. If the recipient never redeems the gift using the recipient payment account, then the giver is not charged for the gift and no transaction occurs [i.e. changing the gift information to a cancelled state]. Alternatively speaking, the giver payment account is charged only upon redemption of the gift using the recipient payment account. To avoid accumulation of such outstanding charges, the gift can expire after a certain period of time, such as after 2 years, after a certain number of notices to the recipient [i.e. in response to failing to receive the unblind request and the delete request from the first user within the unblinding available period], and so forth” [0179] and “When the user clicks on one of the gifts, the system can present an openable, electronic card, as shown in example user interface 5979. If the gift is associated with a timer, such as a gift only valid for a limited duration [i.e. within the unblinding available period], the gift tracker application can display a timer indicating a remaining amount of time until expiration of the gift” [0284] and “These alerts can include alerts for upcoming gift-giving events, alerts for received gifts that have gone unused for more than a threshold amount of time, alerts of unopened or unviewed gifts [i.e. in response to failing to receive the unblind request and the delete request from the first user within the unblinding available period], alerts that a recipient has used a gift sent by the user, and so forth” [0286] and Examiner notes that if a recipient fails to open or view a gift, then they haven’t requested to unblind it or delete it). This known technique is applicable to the method of Uhll in view of Wynn as they both share characteristics and capabilities, namely, they are directed to sending a gift to a recipient. It would have been recognized that applying the known technique of, in response to failing to receive the unblind request and the delete request from the first user within the unblinding available period, changing the gift information to a cancelled state, as taught by Wolfe, to the teachings of Uhll in view of Wynn would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar methods. Further, adding the modification of , in response to failing to receive the unblind request and the delete request from the first user within the unblinding available period, changing the gift information to a cancelled state, as taught by Wolfe, into the method of Uhll in view of Wynn would have been recognized by those of ordinary skill in the art as resulting in an improved method that would avoid accumulation of gift card charges for cards that are never redeemed (Wolfe, [0179]). Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Uhll, in view of Wynn, in further view of Rudeegraap et al. (US 2022/0198386 A1), hereinafter Rudeegraap. Regarding claim 12, Uhll in view if Wynn teaches the method of claim 1. Uhll further discloses: -the method further comprises, in response to receiving a request to delete the blinded gift information from the first user, providing the second user with cancellation information (Uhll, see at least: “Each wish data field 510 may include a wish action menu 516, which, when expanded provides a list of actions to apply to the wish. For example, the wish action menu 516 may provide options to edit the wish, preview the wish, copy the wish, attach a document to the wish, attach a gift to the wish, rescind the wish, delete the wish from the wish outbox 502 [i.e. in response to receiving a request to delete the blinded gift information from the first user], designate the wish as a favorite and/or schedule the wish for delivery” [0169] and “The wish inbox 504 may also include a search field 518 to search for received wishes by keyword, name, date and so forth. As illustrated in FIG. 40, an expand status box 514 may be opened to display the wish recipient(s) status, for example accepted, rejected, delivered, not delivered, viewed, blocked, and the like [i.e. providing the second user with cancellation information]” [0173] and “The wish inbox 504 may include a listing of all the wishes received by the user [i.e. from the first user]” [0171] and Fig. 39 displays that the received wish includes the option to delete the wish and associated gift [i.e. in response to receiving a request to delete the blinded gift information from the first user]). Uhll in view of Wynn does not explicitly teach the gift provision request comprises information on a shipping address of the gift, and providing the second user with cancellation information being due to the first user's failing to input shipping address information for the gift provision request. Rudeegraap, however, teaches sending a gift to a contact (i.e. abstract), including the known technique of the gift provision request comprises information on a shipping address of the gift (Rudeegraap, see at least: “step 1410 includes confirming a recipient's address prior to sending the gift package [i.e. the gift provision request comprises information on a shipping address of the gift]. For example, in some embodiments, step 1410 includes sending an electronic message to the recipient to confirm a physical mailing address before delivering the package. In some embodiments, step 1410 may include configuring a variable expiration date for the gift package” [0111]), and the known technique of providing the second user with cancellation information due to the first user's failing to input shipping address information for the gift provision request (Rudeegraap, see at least: “step 1410 includes confirming a recipient's address prior to sending the gift package. For example, in some embodiments, step 1410 includes sending an electronic message to the recipient to confirm a physical mailing address before delivering the package. In some embodiments, step 1410 may include configuring a variable expiration date for the gift package [i.e. providing the second user with cancellation information due to the first user's failing to input shipping address information for the gift provision request]” [0111]). These known techniques are applicable to the method of Uhll in view of Wynn as they both share characteristics and capabilities, namely, they are directed to sending a gift to a contact. It would have been recognized that applying the known techniques of the gift provision request comprises information on a shipping address of the gift; and providing the second user with cancellation information due to the first user's failing to input shipping address information for the gift provision request, as taught by Rudeegraap, to the teachings of Uhll in view of Wynn would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar methods. Further, adding the modifications of the gift provision request comprises information on a shipping address of the gift; and providing the second user with cancellation information due to the first user's failing to input shipping address information for the gift provision request, as taught by Rudeegraap, into the method of Uhll in view of Wynn would have been recognized by those of ordinary skill in the art as resulting in an improved method that would allow for confirmation of a physical mailing address before delivery of a gift package (Rudeegraap, [0038]). Response to Arguments Rejections under 35 U.S.C. §101 Applicant argues that the claims are not directed merely to providing gift information or a social/business interaction. Rather, they recite a specific computer-implemented control architecture for selective disclosure of data based on state and interface conditions. In particular, the claimed subject matter requires: generating blinded gift information with selected fields suppressed or replaced, providing a dedicated information check interface, and in response to an interface request, providing partial information while maintaining the blinded state (i.e., without unblinding). This defines a state-preserving, interface-triggered partial disclosure mechanism that cannot be performed as a mental process. As shown in FIG. 2 and FIGS. 6-7, the system maintains the blinded state at S 140, while allowing selective disclosure at S 150 without state transition (Remarks, page 9). Examiner respectfully disagrees. Providing or suppressing what gift data is provided and maintaining a status as a “blinding state” (i.e. certain data is not provided) recite the concept of providing full or partial gift information to a user from a friend and fall within the “Certain Methods of Organizing Human Activity” groupings of abstract ideas, enumerated in MPEP 2106.04(a), as they encompass advertising, and marketing or sales activities. Merely providing or not providing this data on an interface amounts to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea). Additionally, a ‘states’ in the context of the claims are merely categorizations represented by data, they are not additional elements. Furthermore, the claims do not provide a technical description of how the interface is displayed (e.g. is there an overlay that is generated in a technical way that improves the interface? is a link embedded in a technical way that improves the interface? is data compressed in a technical way that improves the interface? etc.). The amended claims merely state that the interface is displayed and that a request can be received via the interface. Accordingly the claims are ineligible. Applicant further argues that the system enforces coordinated server-side state management and client-side interface behavior, including control of information asymmetry across users. For example, upon deletion, the server provides decline information that does not reveal whether the sender was blocked or whether the gift was blinded. These limitations impose specific constraints on how and when information is revealed, improving system-level control of data visibility and preventing unintended information exposure and inference. Accordingly, the claims integrate any alleged abstract idea into a practical application and recite significantly more than generic computer implementation under Step 2A and Step 2B (Remarks, pages 9-10). Examiner respectfully disagrees. Merely providing or not providing this data on an interface amounts to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea). Additionally, the claims do not recite or describe a “coordinated server-side state management” beyond a server sending, receiving, and updating data (i.e. merely use a computer as a tool to perform an abstract idea). Improving system-level control of data visibility and preventing unintended information exposure and inference are not improvements in the functioning of a computer or an improvement to another technology or technical field. Accordingly, the claims are ineligible. Amended independent Claim 14 includes similar features. Thus, amended Claims 1 and 14, and their dependent claims are patent eligible (Remarks, page 10). Examiner respectfully disagrees. As detailed in response to the arguments above, claim 1 is ineligible. Accordingly, the claim 14 is ineligible. Applicant further argues that new Claim 22 further reinforces patentability under both § § 101 and 103. Under § 101, Claim 22 recites a server-controlled state transition from a blinded state to a deleted state combined with controlled disclosure to different users, including (i) causing the first user terminal to display deletion without revealing suppressed information, and (ii) providing decline information to the second user that omits any indication of blocked status or prior blinding. This defines a technical mechanism for enforcing asymmetric information visibility across users, not a mere business interaction (Remarks, page 12). Examiner respectfully disagrees. Providing or suppressing what gift data is provided and maintaining a status as a “blinding state” (i.e. certain data is not provided) recite the concept of providing full or partial gift information to a user from a friend and fall within the “Certain Methods of Organizing Human Activity” groupings of abstract ideas, enumerated in MPEP 2106.04(a), as they encompass advertising, and marketing or sales activities. Merely providing or not providing this data on an interface amounts to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea). Additionally, the claims do not recite or describe a “server-controlled state transition” beyond utilizing a server and other generic computer components to implement the abstract idea. ‘States’ in the context of the claims are merely categorizations represented by data, they are not additional elements. Providing different information to different users is not a “technical mechanism” it’s an advertising, and marketing or sales activity. Accordingly the claim 22 is ineligible. Rejections under 35 U.S.C. §103 Applicant argues that the cited combination of Uhll and Wynn fails to disclose or suggest the claimed state-preserving partial disclosure architecture. The claims require that partial information be disclosed via a dedicated interface while the underlying gift information remains in a blinded state, with separate interfaces triggering different state transitions. Wynn's "request access" mechanism instead provides access to restricted content and does not maintain a restricted state during disclosure, while Uhll discloses only conventional viewing, editing, or deletion. Additionally, the claims require coordinated multi-interface behavior tied to distinct state outcomes (e.g., partial disclosure without transition, unblinding, deletion). Neither reference discloses or suggests this multi-branch control logic (Remarks, page 10). Examiner respectfully disagrees. Initially, Examiner points out that the claims only recite one interface [i.e. the information check interface], multiple interfaces are not recited in the claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Additionally, Uhll discloses that an actions menu provides an option to preview a message without opening it [i.e. in response to receiving a request for provision of the partial information to the first user terminal such that the first user terminal displays the partial information, without changing the status of the gift information] (see Uhll, [0172], [0171] and Fig. 39). In other words, the status of the gift message remains the same as it is not technically viewed, only previewed. Wynn modified Uhll to teach that the request id received via the information check interface. Specifically, Wynn teaches that the selection of the "Request access" link, which is displayed on a first interface (i.e. receiving, via the information check interface, a request for provision of the partial information), provides the blocked information on a different interface. Accordingly, the cited combination of Uhll and Wynn teach the amended claims. Applicant further argues that the claims further require cross-user information control, such that deletion results in decline information that does not reveal whether the sender was blocked or whether the gift was previously blinded. Uhll' s deletion functionality does not address such inference control, and Wynn similarly fails to teach asymmetric disclosure between users (Remarks, page 10). Examiner respectfully disagrees. Uhll discloses that a user can delete a received wish [i.e. in response to receiving, from the first user, a delete request for the blinded gift information:], as well as, that the status of a wish sent to the recipient is provided to the sender and includes ‘rejected’ [i.e. providing, to the second user, decline information indicating that the first user declines the gift in response to the gift provision request, wherein the decline information does not indicate whether the second user is the blocked friend set by the first user or whether the gift information was in the blinded state] (see Uhll, [0173], [0171] and Fig. 39). Accordingly, the cited combination of Uhll and Wynn teach the amended claims. Applicant further argues that amended independent claim 14 includes similar features as claim 1. Thus, amended claims 1 and 14, and their dependent claims are allowable over the cited references (Remarks, page 11). Examiner respectfully disagrees. As detailed in response to the arguments above, claims 1 is taught by the cited references. Accordingly, claim 14, as well as the dependent claims, are not allowable. Applicant further argues that although Applicant has not addressed all the issues of the dependent claims, Applicant respectfully submits that Applicant does not necessarily agree with the characterization and assessments of the dependent claims made by the Examiner, and Applicant believes that each claim is patentable on its own merits. Applicant respectfully submits that the dependent claims incorporate by reference all the limitations of the claim to which they refer and include their own patentable features and are therefore in condition for allowance. Therefore, Applicant respectfully requests the withdrawal of all claim rejections and prompts allowance of the claims (Remarks, page 11). Examiner respectfully disagrees. As detailed in response to the arguments and the rejections above, the dependent claims are taught by the cited references. Applicant further argues that new claim further reinforces patentability under both § § 101 and 103. Under § 103, the cited references do not disclose or suggest this combination. While Uhll generally allows deletion and Wynn generally addresses blocking, neither reference teaches or suggests coordinating a deletion state transition with selective suppression of system state information in communications to another user. The claimed configuration prevents inference of system state by the sender and thus requires specific server-side control logic beyond conventional message deletion or filtering (Remarks, pages 11-12). Examiner respectfully disagrees. Initially, Examiner points out that the claims do not recite “coordinating a deletion state transition with selective suppression of system state information in communications to another user” or “specific server-side control logic.” Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Additionally, Uhll discloses that a user can delete a received wish [i.e. in response to receiving, from the first user, a delete request for the blinded gift information:], as well as, that the status of a wish sent to the recipient is provided to the sender and includes ‘rejected’ [i.e. providing, to the second user, decline information indicating that the first user declines the gift in response to the gift provision request, wherein the decline information does not indicate whether the second user is the blocked friend set by the first user or whether the gift information was in the blinded state] (see Uhll, [0173], [0171] and Fig. 39). Accordingly, the cited combination of Uhll and Wynn teach claim 22. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. -Tinianow et al. (US 2017/0171141 A1) teaches an option to accept or reject an invitation. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIELLE E WEINER whose telephone number is (571)272-9007. The examiner can normally be reached M-F 8:30-5:00. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Maria-Teresa (Marissa) Thein can be reached at 571-272-6764. 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. /ARIELLE E WEINER/ Primary Examiner, Art Unit 3689
Read full office action

Prosecution Timeline

Show 1 earlier event
Sep 10, 2025
Non-Final Rejection mailed — §101, §103
Dec 04, 2025
Examiner Interview Summary
Dec 04, 2025
Applicant Interview (Telephonic)
Dec 10, 2025
Response Filed
Mar 16, 2026
Final Rejection mailed — §101, §103
Jun 16, 2026
Request for Continued Examination
Jun 23, 2026
Response after Non-Final Action
Aug 03, 2026
Non-Final Rejection mailed — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12705658
SYSTEMS AND METHODS FOR MODIFYING A GRAPHICAL USER INTERFACE BASED ON SEMANTIC ANALYSIS
2y 6m to grant Granted Aug 11, 2026
Patent 12682388
UNATTENDED COMMODITY SELLING ASSISTANCE SYSTEM USING VEHICLE, AND VEHICLE ASSISTING IN UNATTENDED COMMODITY SELLING
2y 4m to grant Granted Jul 14, 2026
Patent 12657619
SYSTEMS AND METHODS OF PRODUCT IDENTIFICATION WITHIN AN IMAGE
2y 8m to grant Granted Jun 16, 2026
Patent 12632896
Computing Devices, Computer Program Products, and Methods for Efficient Rendering Pipeline for Makeup Including VTO UI Option Configuration/Selection and Looks
2y 2m to grant Granted May 19, 2026
Patent 12586112
SYSTEMS, NON-TRANSITORY COMPUTER-READABLE STORAGE MEDIUMS, AND METHODS FOR OBTAINING PRODUCT INFORMATION VIA A CONVERSATIONAL USER INTERFACE
2y 11m to grant Granted Mar 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
44%
Grant Probability
97%
With Interview (+53.1%)
3y 2m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 237 resolved cases by this examiner. Grant probability derived from career allowance 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