DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 11, 21, 33, 43, 53, 65, 75, 85, 106 – 108 have been amended and are hereby entered.
Claims 1- 108 are pending and have been examined.
This action is made FINAL.
Response to Arguments
Applicant's arguments filed April 20, 2026 have been fully considered but they are not persuasive.
Regarding to Applicant's arguments for Double-Patenting Rejection: Due to Applicant filing of an Electronic-Terminal Disclosure or e-td, the Obviousness-type Double Patenting (ODP) rejection have been withdrawn.
The drawings amendments have been entered. Therefore, all pending objections have been withdrawn due to Applicant's amendments to the drawings.
Regarding the applicant's arguments against the 101 rejection of pending claims on pages 56-59: Applicant’s arguments directed to Step 2A prong 2 and Step 2B from the 101 analysis were considered. However, these arguments are not persuasive and the examiner respectfully disagrees for the following reasons:
For Step 2A-Prong 2 and Step 2B starting in p. 56: The Applicant alleges that the claims integrate, the judicial exception identified, into a practical application and further alleges that “the claims recite a specific, computer-implemented architecture that manages the state-space of bidirectional connections to solve a problem rooted in computer networking: the consumption of finite bandwidth by high-frequency data packets” and submits an “Appendix A” with equations to explain that the “match limit” is “not a mere social preference, but a functional technical governor” resulting in alleged computer improvements by “reducing unnecessary packet data” and “resource preservation”, as alleged (see Appendix A from Remarks). However, the Examiner finds these arguments unpersuasive and respectfully disagrees. Because firstly, the claims and their claim language don’t seem to focus on this alleged computer improvements and nowhere in the specifications mentions these alleged improvements to the computer. Rather, the claimed feature of implementing “match limit(s)” have been interpreted as computer settings that amount to mere instructions to “apply” the exception using a generic computer component (MPEP 2106 .05(f) and (f)(2)). Further, “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept” at step 2B (see MPEP 2106.05(f)(2); TLC communications).
Secondly, the provided Appendix A (i.e. “technical analysis of network bandwidth optimization via match saturation constraints” authored by an independent expert that is not the inventor) was considered as not being part of the Applicant’s invention claimed and its corresponding disclosure (i.e. there’s no nexus between the invention as claimed and the evidence provided) since the claimed invention is concerned with achieving the concurrent matches limit established to reduce overwhelming number of matches and promote meaningful communications between matches (see ¶0005 – 7 from Applicant disclosure). Even, if the Applicant intended to file this Appendix as part of a declaration (i.e. SMED) under 37 CFR 1.132, such Appendix would be considered not being properly filed based on the compliance of the required formalities (see MPEP 716).
Thus, in response to Step 2B arguments in p. 58, the specific series of technical steps of “maintaining bidirectional connection counters, performing real-time saturation checks at a hardware processing device, and dynamically altering the network visibility and user interface state) to optimize data throughput” is not reflected and does not reflect an improvement to the way the computer is working (i.e. functionality). Specifically, for the computer to achieve the concurrent matches limit established to reduce overwhelming number of matches and promote meaningful communications between matches (see ¶0005 – 7 from Applicant disclosure). Rather, the claim limitations are recited in a high level of generality by disclosing the end result without providing details on how this alleged “improvement” to the computer functioning and/or to the existing technology of “dating applications” in computer environments (i.e. “networked communication systems”) is achieved. Thus, the claims to be invoking the use of a generic computer (e.g. “apply it”) or reciting mere instructions to implement an abstract idea on a computer used as a tool (see MPEP 2106.05 (f)), as already explained above. Finally, the Examiner notes that because this analysis for the claims in this and the previous office actions for Step 2A Prong 2 did not consider any of the additional elements (or combination of additional elements) to be well-understood, routine, conventional activity (see Berkheimer memo and MPEP 2106.05(d)(I)(2)), the Examiner is not required to provide a factual determination for this conclusion that the Applicant alleged.
Thus, for all the reasons stated above, the Examiner respectfully disagrees, and maintains 35 USC § 101 rejection for these pending claims.
Regarding to Applicant's arguments of rejection under 35 USC § 103 for the pending claims on pages 52 – 56: Applicant’s arguments regarding the amended limitation steps in the pending claims are not persuasive and the Examiner respectfully disagrees. Because Applicant is focusing on each prior art teaching, rather than focusing on the actual language claimed in each claim limitation and how their corresponding limitation steps are different from the prior art teachings. Rather, the steps disclose a broader language that the prior art combination of Lim and Ding, still reasonably satisfies and teaches in light of the broadest reasonable interpretation (BRI) of the claim language. Upon review of the pending amended claim limitations, and in response to Applicant arguments for claims 21, 53, 85 and 108 directed the claimed feature of “declining” display of profiles when first user reached the “limit of concurrent matches”, the combination of Lim and Ding, still reasonably teaches this limitation under the broadest reasonable interpretation (BRI). Firstly, because Lim does provide connections that are bidirectional when a user accepts a “goose request” from another user (i.e. which is a “unidirectional indication/expression”) and via a “token” a “match” is established which is directed to the concurrent match or bidirectional connection (see ¶0082 – 83, 89 and ¶0138 – 139; Lim). However, the step of actually “declining” display of profiles of other users when the first user reaches the limit of matches, this is taught by Ding as when the user is informed that they need to remove someone to “make space for a new crush”. Thereby, declining the request until the user removes someone (see Fig. 12A and ¶0043 for more details; Ding). Even if Applicant do not concede with Examiner’s interpretation regarding concurrent matches or bidirectional connections, other prior art found and cited in the conclusion can satisfy such types of connections/matches, as it is the case of Robson (U.S. Pub No. 20110219310 A1) which teaches concurrent connections as “two-way matches” based on each user’s inputted level of interest (see Figs. 1 and 2 as well as ¶0047; Robson).
As for the arguments regarding last interview, The Examiner notes and agrees that Lim’s teaching for “Autoduck” rating was not the representation for a “match” or a “bidirectional expression of interest”, as asserted by Applicant. However, the use of “tokens” which are limited by the system and are charged after both users accepted the “date request” or “goose request”, are at least reasonably teaching the claimed “match” or “bidirectional connection” (see ¶0138 – 139; Lim). Further, Applicant alleges in p. 56 from Remarks that the “overall limit of concurrent matches” imposed is not taught by the prior art references. However, this argument is also unpersuasive based on the combination of the prior art teachings maintained herein and as explained above. Please, refer to the Claim Rejections - 35 USC § 103 section for further details.
Therefore, the Examiner respectfully disagrees, and maintains 35 USC § 103 rejection for these pending claims.
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 - 108 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention recited in the claims begins in view of independent claims 65, 75 and 85 which are the most representative claims of the independent claims set 1, 11, 21, 33, 43, 53, 65, 75, 85, 106, 107 and 108, as follows:
At Step 1: Claims 1, 11, 21 and 106 – 108 falls under statutory category of a process. Claims 65, 75 and 85 are considered a system and claims 33, 43 and 53 are directed to an article of manufacture.
At Step 2A Prong 1: Claims 65, 75 and 85 recites an abstract idea, which is defined by the following underlined elements (e.g. functional steps) while omitting any hardware components (e.g. represented as “…”):
For Claim 65 (representative of claims 1, 33 and 106)
…receive input from the first user; and
…determine whether the first user has reached a limit of concurrent matches, wherein each match represents a bidirectional connection between the first user and another user;
responsive to the first user not having reached the limit of concurrent matches representing bidirectional connections, make the first user visible to other users; and
responsive to the first user having reached the limit of concurrent matches representing bidirectional connections, make the first user invisible to other users.
wherein each bidirectional connection comprises a connection between users that has been previously established in response to an invitation from one user to another user to establish a match, followed by an acceptance of the invitation.
For Claim 75 (representative of claims 11, 43 and 107)
…select a second user as a potential match to be displayed for a first user; and
determine whether the first user has reached a limit of concurrent matches, wherein each match represents a bidirectional connection between the first user and another user;
…responsive to the first user not having reached the limit of concurrent matches representing bidirectional connections: display, for the first user, a profile describing the second user; and
concurrently with displaying the profile describing the second user, display…for initiating transmission of a unidirectional indication of interest in the second user; and
responsive to the first user having reached the limit of concurrent matches:
display, for the first user, the profile describing the second user without displaying any user interface element for initiating transmission of a unidirectional indication of interest in the second user;
…receive input from the first user; and
…receiving input from the first user activating the user interface element,
transmit the unidirectional indication of interest;
wherein each bidirectional connection comprises a connection between users that has been previously established in response to an invitation from one user to another user to establish a match, followed by an acceptance of the invitation.
For Claim 85 (representative of claims 21, 53 and 108)
…receive input from the first user to invoke functionality to view profiles representing other users;
…determine whether the first user has reached a limit of concurrent matches, wherein each match represents a bidirectional connection between the first user and another user;
…responsive to the first user not having reached the limit of concurrent matches
representing bidirectional connections:
display, for the first user, profiles representing other users; and
concurrently with displaying each profile, display a user interface element for initiating transmission of a unidirectional indication of interest in the user represented by the profile; and
…receiving input from the first user activating the user interface element,
transmit the unidirectional indication of interest to a second user;
wherein, responsive to the first user having reached the limit of concurrent matches representing bidirectional connections…decline to display profiles representing other users;
and wherein each bidirectional connection comprises a connection between users that has been previously established in response to an invitation from one user to another user to establish a match, followed by an acceptance of the invitation.
Generally, these limitations, describe a method and a system for selecting and displaying dating profiles based on matching limits determined at a dating application. As disclosed in the specification in ¶0007 and ¶0018, this claimed invention allows to place limits “on the number of matches (also referred to as "strong connections") a user may have at any given time” in a “dating application” in order to make user profiles “be made available and therefore visible to other individuals”, once again. However, the abstract idea(s) of a certain method of organizing human activity (See MPEP 2106.04(a)(2), subsection II) are/is recited in claims 65, 75 and 85 in the form of “commercial or legal interactions”. Specifically, the abstract idea is recited in at least in the steps of “determine whether the first user has reached a limit of concurrent matches…” in order to “make the first user visible or invisible”, display a “second user profile” and display a “user interface element” or not, that when activated by the user transmits “unidirectional indications of interest”. Thus, these steps directed to manage user profile visibility based on concurrent matches limits at least encompasses commercial interactions related to business relations and advertisements of other user profiles as potential matches. Similarly, these steps also fall under the abstract idea sub-group of “managing personal behavior or relationships or interactions between people” since whether to “display” user dating profiles (e.g. visible or invisible) based on concurrent matches limits determination encompasses user social activities.
At least the steps of “determine whether the first user has reached a limit of concurrent matches…” (from claims 65, 75 and 85), “select a second user as a potential match to be displayed…” (from claim 75) and “wherein responsive to the first user having reached the limit of concurrent matches representing bidirectional connections…decline to display profiles representing other users” (from claim 85) fall under the abstract idea of mental processes that can be practically be performed in the human mind or in pen and paper (See MPEP 2106.04(a)(2), subsection III). Because selecting a second user as a potential match, determining concurrent matches limits for a first user and based on these limits being reached decline the display of other user profiles encompass at least evaluation and judgement. Also, these steps can either be done with the help of physical aid such as pen and paper or can be performed by humans without or with the assistance (e.g. tool) a computer. Thus, the steps does not negate and further still reads in the mental nature of the limitation(s), when obtaining such information, as well as the concept is merely claimed to be performed on a generic computer and is merely using a computer as a tool to perform the concept of displaying user profiles based on limits of concurrent matches of the first user to whether display other user profiles in a dating application (see MPEP 2106.04(a)(2)(III)(B & C)).
At Step 2A Prong 2: For independent claims 65, 75 and 85, The judicial exception(s) or abstract idea previously identified is not integrated into a practical application (see MPEP 2106.04 (d)). The claims recite the additional element(s) of an input device, (from claims 65, 75 and 85); a processor (from claims 65, 75 and 85); a first network-connected hardware processing device (from claims 65, 75 and 85), an output device and a network communication component (from claims 75 and 85). These additional elements, individually and in combination, and while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). Specifically, these limitation steps are recited as being performed by the computer. The computer used is recited at a high level of generality that is being used as a tool to perform the generic computer functions for selecting user profiles and displaying user profiles while receiving user inputs and transmitting unidirectional indications. Thus, these steps mentioned above are further describing and applying the abstract idea without placing any limits on how the technological components are being improved, while distinguishing in the claim language, the performing limitations from functions that generic computer components can perform.
Finally, the steps of “…receive input from the first user” (from claims 65, 75 and 85), “…display, for the first user, a profile …” (from claims 65, 75 and 85), “…display a user interface element for initiating transmission of a unidirectional indication of interest in the second user…” (from claims 75 and 85), and “transmit the unidirectional indication of interest to a second user…” (from claim 85) in the representative claim is really nothing more than links to computer for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)). Thus, in these limitation steps, the computer is used to perform an abstract idea, as discussed above in Step 2A, Prong One, such that it amounts to no more than mere instructions to apply the exception using a generic computer.
Therefore, this analysis is indicative of the fact that even when viewed in combination, the claims’ additional elements do not integrate the abstract idea or judicial exception into a practical application.
Step 2B: For independent claims 65, 75 and 85, these claims do not provide an inventive concept. The recited additional elements of the claim(s) are the following: an input device, (from claims 53, 65, 75 and 85); a processor (from claims 65, 75 and 85); a first network-connected hardware processing device (from claims 1, 11, 33, 43, 53, 65, 75, 85 and 106 – 107), an output device and a network communication component (from claims 75 and 85. These additional elements are not sufficient to amount significantly more than the judicial exception or abstract idea (see MPEP 2106.05). Because, as indicated in Step 2A Prong 2, these additional element(s) claimed are merely, instructions to “apply” the abstract ideas, which cannot provide an inventive concept. Also, the recitation of a computer to perform the claim limitations amounts to no more than mere instructions to apply the exception using a generic computer component. Thus, even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer, which do not provide an inventive concept at Step 2B.
For dependent claims 2-10, 12 - 20, 22 - 32, 34 - 42, 44 - 52, 54 - 64, 66 - 74, 76 - 84 and 86 -105, the same analysis is incorporated. Due to their dependency to the independent claims analyzed, these claims cover or fall under the same abstract idea(s) of a method of organizing human activity and mental processes. They describe additional limitations steps of:
Claims 2-10, 12 - 20, 22 - 32, 34 - 42, 44 - 52, 54 - 64, 66 - 74, 76 - 84 and 86 -105: further describes the abstract idea of the method for limiting matches between users wherein user inputs are received, unidirectional indications of interest are transmitted and are responded to prospective matches selected and displayed and establish a match (e.g. bidirectional connections between users) which include incrementing/ match counters and condition limit determinations, by initiating a communication channel. Also, matches are further described when these are indicated to be terminated and while decrementing match counters, and when matching limits are reached making users visible/invisible and unavailable to be matched as well as sending messages with this status to other users. Limits of concurrent matches are further described in three different levels for current status, experience and service tier that can also be changed. Thus, being directed to the abstract idea group of “managing personal behavior or relationships or interactions between people” as it is directed to managing user profile visibility and display based on concurrent matches limits that encompasses commercial interactions related to business relations and advertisements of other user profiles as potential matches as well as mental processes that require determinations that are based on evaluation and judgement.
Step 2A Prong 2 and Step 2B: For dependent claims 3 – 4, 6 – 7, 12 – 13, 15 – 16, 24 – 25, 27 – 28, 34 – 36, 38 – 39, 44 – 45, 47 – 48, 56 – 57, 59 – 60, 66 – 68, 70 – 71, 76 – 77, 79 – 80, 88 – 89 and 91 - 92, these claims recite the additional elements of: an input device, (from claims 34 and 66); a second network-connected hardware processing device (from claims 3, 12, 24, 35, 44, 56, 67, 76 and 88); a communication channel (from claims 4, 6, 13, 15, 25, 27, 36, 38, 45, 47, 57, 59, 68, 70, 77, 79, 89 and 91); a dating software application (from claims 7, 16, 28, 39, 48, 60, 71, 80 and 92). These additional elements recited are invoking computers merely used as a tool to perform or “apply” the abstract idea(s) to the existing process of receiving signals related to responses and user inputs, establish matches and transmit unidirectional indications. Thus, amounting to no more than mere instructions to “apply” the exception using a generic computer component (MPEP 2106.05(f) and (f)(2)). Accordingly, for the same reasons stated above, these additional element(s) claimed cannot provide an inventive concept at Step 2B.
Finally, the additional elements previously mentioned above, are nothing more than descriptive language about the elements that define the abstract idea, and these claims remain rejected under 101 as well.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-108 are rejected under 35 U.S.C. 103 as being unpatentable over Lim (U.S. Pub No. 20100088246 A1) in view of Ding (U.S. Pub No. 20200344214 A1).
Regarding claims 1, 33, 65 and 106:
This independent claim set is represented by claim 65
Lim teaches:
an input device, configured to receive input from the first user; and (In ¶0132 – 133; Fig. 6A (1101); Fig. 6B (1111); Fig. 7 (1211); Fig. 10 (1400 – 1421 and 1407 – 1408): teaches that “a user will first initiate a search for another user by inputting into the system certain criteria data that the user finds desirable” at step 1101 and in step 1111, “a user can input specific rendezvous information including a specific day, time, and/or event for which the searching user wants companionship”, in accordance to ¶0033 from Applicant disclosure. Refer to ¶0081 wherein a “recipient must give a response (goose, duck, or block) to a contact request within a fixed period of time (e.g. 24 hours) otherwise it becomes an Autoduck” which the response is another receiving input example.)
a processor, communicatively coupled to the input device, configured to: determine whether the first user has reached a limit of concurrent matches, wherein each match represents a bidirectional connection between the first user and another user; (In ¶0139; Fig. 9 (1373); Fig. 10 (1401): teaches that the system does not allow a user to “have more than a set number of outgoing date requests 1373 in outgoing request queue 410” and this number can be set and modified by “administrator of the system” based on “the size of the user population” and in step 1401, “the system checks whether the number of pending requests is greater than three”, for example. Refer to ¶0087 also.)
responsive to the first user not having reached the limit of concurrent matches representing bidirectional connections, make the first user visible to other users; (In ¶0139; Fig. 9 (1373 and 1375); Fig. 10 (1404 and 1406): teaches that “If the user does not have more than three pending requests and the user has sufficient tokens to pay for the communication then the system will allow the request” and “In step 1403, the system places the request in the user's outgoing date request queue 410” which is reflected in “step 1406” wherein, “the system presents the request to the receiving user by placing the request in the receiving user's incoming date request queue 412” which is directed to having the first user visible to other users.)
wherein each bidirectional connection comprises a connection between users that has been previously established in response to an invitation from one user to another user to establish a match, followed by an acceptance of the invitation. (In ¶0089; Fig. 10; Fig. 13: teaches the bidirectionality of a connection when the system “charges users only for the goose contacts they establish” with the use of a “token”, since “the requester have a cost associated with the request acceptance (e.g. 1 token charge to the requester for recipient's acceptance)” which makes recipients and requesters to not waste their opportunities freely and without being genuinely interested. Further, “users can't communicate (e.g. email, IM) with each other until a contact is established (goose request is accepted)—this ensures that the operator of the social network gets paid” which is directed to having mutual connection taking place. Moreover, the system teaches an invitation from one user to another to establish a match as “Requesters must present a token (a unit of payment) when they make a contact request” (see ¶0082) (i.e. a “goose request” (see ¶0089) or “when the requester selects “Goose me”” (see ¶0139)). Then, when the user accepts “the request (“goose”)” (see ¶0139) or “a contact request, then both the requester and the recipient are charged one token” (see ¶0083) and in turn, a connection is established between users as shown in step 1409 (see ¶0139). See ¶0120 and ¶0138 - 193 for complete examples. Refer to ¶0157 – 158 for more alternative examples with tokens.)
Lim discloses reaching a limit of matches in ¶0087 wherein “users can only request a limited number (e.g. 3) of contact requests (goose requests) at one time” which “minimizes date spamming and places a value on contact requests as a limited resource that encourages users to carefully evaluate (e.g. compatibility, availability, and/or rating) their contact requests”. However, Lim does not explicitly teach the first user becoming specifically invisible, after reaching such limit of matches. Thus, Ding teaches:
and responsive to the first user having reached the limit of concurrent matches representing bidirectional connections, make the first user invisible to other users; (In ¶0043 – 44; Fig. 12C: teaches that as shown in Figs. 12A – 12C, the user can add a limited number of users or “crushes” into their “concealed list of persons 109”, after the other person add the user “to their own concealed list 117” in order to make the other person aware (e.g. the user is visible; see ¶0043 – 44). But, when the user reaches the limit number of “crushes”, the user has to wait an amount of time before “the user will be able to add a new person to the crush list” which suggests that the user won’t be visible to other users if their list is saturated or completed, based on the system’s “removal rules” that can be applied and configured by an “administrator” that can include how a user is shown (e.g. directed to user being invisible) in other users’ crush list, in accordance to the examples given in ¶0139 and ¶0159 from Applicant disclosure. Also, refer to ¶0045 for an example wherein “the user 113 is made aware of an anonymous crush or lists someone who does not express a mutual interest within a week or a month or some other time period, the indication of interest may expire and those persons may be removed from the anonymous user's or other user's concealed list of persons” which is another example of the user not being visible in other user’s crush lists.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Lim to provide the ability of making the first user invisible after the limit of matches has been reached, as taught by Ding in order to “prohibit the user 113 from simply identifying everyone in their list of friends and may constrain the user to choose only those persons in whom the user is truly interested” as well as “to maintain the privacy of the user's friends” (¶0037 – 38; Ding) through “concealed interactions” that are “encrypted, protected by gating credentials, or otherwise removed from the general public” (¶0016; Ding).
Regarding claims 11, 43, 75 and 107:
This independent claim set is represented by claim 75
Lim teaches:
in a first network-connected hardware processing device operated by a first user: a processor, configured to: (In ¶0105; Fig. 1: teaches “a computer server 101 connected to a database 102 connected to the internet 103” wherein the user can connect and access “the server”: which is “programmed to allow communications in the social network to users actively using mobile devices in a common geographic location” (see ¶0147 – 148), based on examples given in ¶0031 from Applicant disclosure.)
select a second user as a potential match to be displayed for a first user; and (In ¶0134; Fig. 7 (1211 and 1212): teaches that upon searching users filtered by entered criteria a list of profiles is returned, in “step 1211, the searching user selects to view the characteristic data, or “profile,” of another user who was in the list of users returned by the system” and “in step 1212, the system then displays the selected user's profile on the screen”.)
determine whether the first user has reached a limit of concurrent matches, wherein each match represents a bidirectional connection between the first user and another user; (In ¶0139; Fig. 9 (1373); Fig. 10 (1401): teaches that the system does not allow a user to “have more than a set number of outgoing date requests 1373” (e.g. “an initiation of an interaction or communication with another member”) in “outgoing request queue 410” and this number can be set and modified by “administrator of the system” based on “the size of the user population” and in step 1401, “the system checks whether the number of pending requests is greater than three”, for example. Refer to ¶0087 also.)
an output device, communicatively coupled to the processor, configured to: responsive to the first user not having reached the limit of concurrent matches representing bidirectional connections: display, for the first user, a profile describing the second user; and (In ¶0134; Fig. 7 (1212 – 1215); Fig. 9 (1373); Fig. 10 (1403): teaches that the system upon checking if the “does not have more than three pending requests and the user has sufficient tokens to pay for the communication then the system will allow the request” wherein the system “places the request in the user's outgoing date request queue 410” in step 1403 and as shown in Fig. 9 (see ¶0139). Thus, these requests include the display of a second user profile via the “the “view me” page 207 of the selected user” in step 1212 with whom the user initiated a “request to communicate with the selected user by pressing the selected user's “Goose me” button 509” in step 1215. The Examiner notes that the output device claimed is interpreted as a user interface, in accordance to the examples given in ¶0173 from Applicant disclosure.)
concurrently with displaying the profile describing the second user, display a user interface element for initiating transmission of a unidirectional indication of interest in the second user; and (In ¶0134; Fig. 7 (1215); Fig. 5 (509): teaches in “step 1215, the user initiates a request to communicate with the selected user by pressing the selected user's “Goose me” button 509” which is directed to the user interface element as shown in Fig. 5. Refer to ¶0126 and ¶0128 for more details.)
an input device, communicatively coupled to the processor, configured to receive input from the first user; and (In ¶0132 – 133; Fig. 6A (1101); Fig. 6B (1111); Fig. 7 (1211); Fig. 10 (1400 – 1421 and 1407 – 1408): teaches that “a user will first initiate a search for another user by inputting into the system certain criteria data that the user finds desirable” at step 1101 and in step 1111, “a user can input specific rendezvous information including a specific day, time, and/or event for which the searching user wants companionship”, in accordance to ¶0033 from Applicant disclosure. Refer to ¶0081 wherein a “recipient must give a response (goose, duck, or block) to a contact request within a fixed period of time (e.g. 24 hours) otherwise it becomes an Autoduck” which the response is another receiving input example.)
a network communication component, communicatively coupled to the processor, configured to, responsive to the input device receiving input from the first user activating the user interface element, (In ¶0128; Fig.1; Fig. 5 (509); Fig. 7 (1215); Fig. 9 (1373 and 1371): teaches that the user can press the “Goose me” button 509 which “will request a communication exchange with the user who is “goosed” (the person who owns the profile on which the “Goose me” button 509 was pressed)”. See ¶0130 for an example wherein “User A may initiate a “goose” request to User B” and ¶0147 for more details about these communications exchanged in a social network via the internet (see Fig. 1).)
transmit the unidirectional indication of interest. (In ¶0128; Fig. 9 (1374): teaches that the “request will be posted to the requester's outgoing request queue 410 and recipient's incoming request queue 412”. See ¶0130 for an example wherein “User B may accept the request by also selecting to “goose” user A”.)
wherein each bidirectional connection comprises a connection between users that has been previously established in response to an invitation from one user to another user to establish a match, followed by an acceptance of the invitation. (In ¶0089; Fig. 10; Fig. 13: teaches the bidirectionality of a connection when the system “charges users only for the goose contacts they establish” with the use of a “token”, since “the requester have a cost associated with the request acceptance (e.g. 1 token charge to the requester for recipient's acceptance)” which makes recipients and requesters to not waste their opportunities freely and without being genuinely interested. Further, “users can't communicate (e.g. email, IM) with each other until a contact is established (goose request is accepted)—this ensures that the operator of the social network gets paid” which is directed to having mutual connection taking place. Moreover, the system teaches an invitation from one user to another to establish a match as “Requesters must present a token (a unit of payment) when they make a contact request” (see ¶0082) (i.e. a “goose request” (see ¶0089) or “when the requester selects “Goose me”” (see ¶0139)). Then, when the user accepts “the request (“goose”)” (see ¶0139) or “a contact request, then both the requester and the recipient are charged one token” (see ¶0083) and in turn, a connection is established between users as shown in step 1409 (see ¶0139). See ¶0120 and ¶0138 - 193 for complete examples. Refer to ¶0157 – 158 for more alternative examples with tokens.)
Lim discloses reaching a limit of matches in ¶0087 wherein “users can only request a limited number (e.g. 3) of contact requests (goose requests) at one time” which “minimizes date spamming and places a value on contact requests as a limited resource that encourages users to carefully evaluate (e.g. compatibility, availability, and/or rating) their contact requests”. Also, Lim generally teaches the profiles describing the second users, but with user interface elements such as “duck me” (see Fig. 5 and ¶0124; Lim). However, Lim does not explicitly teach the ability of displaying the second user profile, after reaching such limit of matches and specifically, without any user interface element related to unidirectional indication. Thus, Ding further teaches:
responsive to the first user having reached the limit of concurrent matches: display, for the first user, the profile describing the second user without displaying any user interface element for initiating transmission of a unidirectional indication of interest in the second user; (See Figs. 12A – 12C: teaches this negative limitation as the system interface can display the “secret crush list” that is saturated or completed (see Fig. 12A) wherein the user can click the second user’s photo icon to view their “Facebook profile” as shown in Fig. 12B (see ¶0043 for more details) which do not include any user interface element related to unidirectional indication as claimed.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Lim to provide the ability of displaying the second user profile, after reaching such limit of matches and specifically, without any user interface element related to unidirectional indication, as taught by Ding in order to “prohibit the user 113 from simply identifying everyone in their list of friends and may constrain the user to choose only those persons in whom the user is truly interested” as well as “to maintain the privacy of the user's friends” (¶0037 – 38; Ding) through “concealed interactions” that are “encrypted, protected by gating credentials, or otherwise removed from the general public” (¶0016; Ding).
Regarding claims 21, 53, 85 and 108:
This independent claim set is represented by claim 85
Lim teaches:
in a first network-connected hardware processing device operated by a first user: an input device, configured to (In ¶0105; Fig. 1: teaches “a computer server 101 connected to a database 102 connected to the internet 103” wherein the user can connect and access “the server”: which is “programmed to allow communications in the social network to users actively using mobile devices in a common geographic location” (see ¶0147 – 148), based on examples given in ¶0031 from Applicant disclosure.)
receive input from the first user to invoke functionality to view profiles representing other users; (In ¶0133 – 134; Fig. 7 (1211 and 1212): teaches that upon receiving user input to search users filtered by entered criteria (see ¶0133) a list of profiles is returned, in “step 1211, the searching user selects to view the characteristic data, or “profile,” of another user who was in the list of users returned by the system” and “in step 1212, the system then displays the selected user's profile on the screen”.)
a processor, communicatively coupled to the input device, configured to determine whether the first user has reached a limit of concurrent matches, wherein each match represents a bidirectional connection between the first user and another user; (In ¶0139; Fig. 9 (1373); Fig. 10 (1401): teaches that the system does not allow a user to “have more than a set number of outgoing date requests 1373” (e.g. “an initiation of an interaction or communication with another member”) in “outgoing request queue 410” and this number can be set and modified by “administrator of the system” based on “the size of the user population” and in step 1401, “the system checks whether the number of pending requests is greater than three”, for example. Refer to ¶0087 also.)
an output device, communicatively coupled to the processor, configured to: responsive to the first user not having reached the limit of concurrent matches representing bidirectional connections: display, for the first user, profiles representing other users; and (In ¶0134; Fig. 7 (1212 – 1215); Fig. 9 (1373); Fig. 10 (1403): teaches that the system upon checking if the “does not have more than three pending requests and the user has sufficient tokens to pay for the communication then the system will allow the request” wherein the system “places the request in the user's outgoing date request queue 410” in step 1403 and as shown in Fig. 9 (see ¶0139). Thus, these requests include the display of a second user profile via the “the “view me” page 207 of the selected user” in step 1212 with whom the user initiated a “request to communicate with the selected user by pressing the selected user's “Goose me” button 509” in step 1215. The Examiner notes that the output device claimed is interpreted as a user interface, in accordance to the examples given in ¶0173 from Applicant disclosure.)
concurrently with displaying each profile, display a user interface element for initiating transmission of a unidirectional indication of interest in the user represented by the profile; and (In ¶0134; Fig. 7 (1215); Fig. 5 (509): teaches in “step 1215, the user initiates a request to communicate with the selected user by pressing the selected user's “Goose me” button 509” which is directed to the user interface element as shown in Fig. 5. Refer to ¶0126 and ¶0128 for more details.)
a network communication component, communicatively coupled to the processor, configured to, responsive to the input device receiving input from the first user activating the user interface element, (In ¶0128; Fig.1; Fig. 5 (509); Fig. 7 (1215); Fig. 9 (1373 and 1371): teaches that the user can press the “Goose me” button 509 which “will request a communication exchange with the user who is “goosed” (the person who owns the profile on which the “Goose me” button 509 was pressed)”. See ¶0130 for an example wherein “User A may initiate a “goose” request to User B” and ¶0147 for more details about these communications exchanged in a social network via the internet (see Fig. 1).)
transmit the unidirectional indication of interest to a second user; (In ¶0128; Fig. 9 (1374): teaches that the “request will be posted to the requester's outgoing request queue 410 and recipient's incoming request queue 412”. See ¶0130 for an example wherein “User B may accept the request by also selecting to “goose” user A”.)
wherein each bidirectional connection comprises a connection between users that has been previously established in response to an invitation from one user to another user to establish a match, followed by an acceptance of the invitation. (In ¶0089; Fig. 10; Fig. 13: teaches the bidirectionality of a connection when the system “charges users only for the goose contacts they establish” with the use of a “token”, since “the requester have a cost associated with the request acceptance (e.g. 1 token charge to the requester for recipient's acceptance)” which makes recipients and requesters to not waste their opportunities freely and without being genuinely interested. Further, “users can't communicate (e.g. email, IM) with each other until a contact is established (goose request is accepted)—this ensures that the operator of the social network gets paid” which is directed to having mutual connection taking place. Moreover, the system teaches an invitation from one user to another to establish a match as “Requesters must present a token (a unit of payment) when they make a contact request” (see ¶0082) (i.e. a “goose request” (see ¶0089) or “when the requester selects “Goose me”” (see ¶0139)). Then, when the user accepts “the request (“goose”)” (see ¶0139) or “a contact request, then both the requester and the recipient are charged one token” (see ¶0083) and in turn, a connection is established between users as shown in step 1409 (see ¶0139). See ¶0120 and ¶0138 - 193 for complete examples. Refer to ¶0157 – 158 for more alternative examples with tokens.)
Lim discloses reaching a limit of matches in ¶0087 wherein “users can only request a limited number (e.g. 3) of contact requests (goose requests) at one time” which “minimizes date spamming and places a value on contact requests as a limited resource that encourages users to carefully evaluate (e.g. compatibility, availability, and/or rating) their contact requests”. However, Lim does not explicitly teach the ability of declining display of other users profiles when reaching such limit of matches. Thus, Ding teaches:
wherein, responsive to the first user having reached the limit of concurrent matches representing bidirectional connections, the processor is further configured to decline to display profiles representing other users. (See Fig. 12A: shows that the user is informed that they need to remove someone to “make space for a new crush”. Thereby declining the request until the user removes someone (see ¶0043 for more details).)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Lim to provide the ability of declining display of other users profiles when reaching such limit of matches, as taught by Ding in order to “prohibit the user 113 from simply identifying everyone in their list of friends and may constrain the user to choose only those persons in whom the user is truly interested” as well as “to maintain the privacy of the user's friends” (¶0037 – 38; Ding) through “concealed interactions” that are “encrypted, protected by gating credentials, or otherwise removed from the general public” (¶0016; Ding).
Regarding claims 2, 34 and 66:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 1, 33 and 65, respectively.
This dependent claim set is represented by claim 34
Lim further teaches:
further comprising instructions stored thereon, that when performed by the first network-connected hardware processing device, perform the steps of: causing an input device to receive input from the first user requesting that a unidirectional indication of interest in a second user be transmitted; and (In ¶0128; Fig.1; Fig. 5 (509); Fig. 7 (1215); Fig. 9 (1373 and 1371): teaches that the user can press the “Goose me” button 509 which “will request a communication exchange with the user who is “goosed” (the person who owns the profile on which the “Goose me” button 509 was pressed)”. See ¶0130 for an example wherein “User A may initiate a “goose” request to User B” and ¶0147 for more details about these communications exchanged in a social network via the internet (see Fig. 1).)
transmitting the unidirectional indication of interest. (In ¶0128; Fig. 9 (1374): teaches that the “request will be posted to the requester's outgoing request queue 410 and recipient's incoming request queue 412”. See ¶0130 for an example wherein “User B may accept the request by also selecting to “goose” user A”.)
Regarding claims 3, 12, 24, 35, 44, 56, 67, 76 and 88:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 2, 11, 21, 34, 43, 53, 66, 75 and 85, respectively.
This dependent claim set is represented by claim 35
Lim further teaches:
receiving a signal from a second network-connected hardware processing device operated by the second user, the signal comprising a response to the transmitted unidirectional indication of interest; and (In ¶0130; Fig. 7 (1215 – 1220); Fig. 9 (1374): teaches an example for the system receiving second user signals wherein “User B may accept the request by also selecting to “goose” user A”.)
responsive to the response indicating that the second user has an interest in the first user, establishing a match representing a bidirectional connection between the first and second users. (In ¶0120; Fig. 7 (1220): teaches that “a communication exchange is established when a user requests to initiate communication with another user and the receiving user accepts the request”. Refer to ¶0134 wherein at step 1220, “if an actual communication exchange occurs between the two users then the viewing user will have the option to post a comment 520 to the profile page of the displayed user”.)
Regarding claims 4, 13, 25, 36, 45, 57, 68, 77 and 89:
Lim, as shown in the rejection above, discloses the limitations of claims 3, 12, 24, 35, 44, 56, 67, 76 and 88, respectively.
Lim further teaches:
wherein establishing the match representing the bidirectional connection between the first and second users comprises initiating a communication channel between the first and second users. (In ¶0089: teaches that “users can't communicate (e.g. email, IM) with each other until a contact is established (goose request is accepted)”.)
Regarding claims 5, 14, 26, 37, 46, 58, 69, 78 and 90:
Lim, as shown in the rejection above, discloses the limitations of claims 3, 12, 24, 35, 44, 56, 67, 76 and 88, respectively.
Lim further teaches:
establishing the match representing the bidirectional connection between the first and second users comprises incrementing a concurrent match counter for each of the first and second users; and (In ¶0120; Fig. 13 (1722): teaches that “both users are charged for each established communication exchange” and “each user will pay in advance for a number of tokens” that “when a user accepts an incoming request both users will be charged one token”.)
determining whether the first user has reached the limit of concurrent matches representing bidirectional connections comprises determining whether the concurrent match counter for the first user is equal to or greater than the limit of concurrent matches representing bidirectional connections. (In ¶0120; Fig. 13 (1721 and 1724): teaches that the system can determine when a limit or counter of concurrent matches have been reached which is directed to the scenario of “when token counter 431 reaches a zero balance the user cannot send or receive requests (other embodiments may allow requests to be sent but not actual communication until tokens are available)” and “when a user opts to send a token with a request to another user, two tokens are deducted from the requester's token counter 431 and none are deducted from the receiving user”.)
Regarding claims 6, 15, 27, 38, 47, 59, 70, 79 and 91:
Lim, as shown in the rejection above, discloses the limitations of claims 5, 14, 26, 37, 46, 58, 69, 78 and 90, respectively.
This dependent claim set is represented by claim 6
Lim further teaches:
wherein establishing the match representing the bidirectional connection between the first and second users comprises: initiating a communication channel between the first and second users; (In ¶0089: teaches that “users can't communicate (e.g. email, IM) with each other until a contact is established (goose request is accepted)”.)
the method further comprising, responsive to receiving input from at least one of the first and second users to terminate the match: terminating the communication channel between the first and second users; and decrementing the concurrent match counter for each of the first and second users. (In ¶0121; Fig. 13 (1721 and 1724): teaches that “when a request is sent token counter 431 is debited one token and placed into token escrow 432” which “prevents a user from making more requests than the user has paid for” and “Token escrow 432 is not debited until the receiving user accepts the request” that “if the receiving user rejects the request then token counter 431 is re-credited”. Refer to ¶0158 wherein at steps 1721 and 1722, “a receiving user rejecting a request” and “the requester is not charged a token for the request and is not charged for an acceptance”.)
Regarding claims 7 and 39:
Lim, as shown in the rejection above, discloses the limitations of claims 2 and 34, respectively.
This dependent claim set is represented by claim 7
Lim further teaches:
wherein the steps of determining whether the first user has reached the limit of concurrent matches representing bidirectional connections, making the first user visible to other users, making the first user invisible to other users, receiving input from the first user, and transmitting the unidirectional indication of interest are performed by a dating software application. (In ¶0052: teaches that the “preferred embodiments of the present invention” can be directed to “a dating site, however, it is not limited to just a dating site, but applicable to any social network”.)
Regarding claims 16 and 48:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 11 and 43, respectively.
This dependent claim set is represented by claim 16
Lim further teaches:
wherein the steps of selecting the second user as a potential match, determining whether the first user has reached the limit of concurrent matches representing bidirectional connections, displaying the profile, displaying the user interface element for initiating transmission of the unidirectional indication of interest, and transmitting the unidirectional indication of interest are performed by a dating software application. (In ¶0052: teaches that the “preferred embodiments of the present invention” can be directed to “a dating site, however, it is not limited to just a dating site, but applicable to any social network”.)
Regarding claims 28 and 60:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 21 and 53, respectively.
This dependent claim set is represented by claim 28
Lim further teaches:
wherein the steps of receiving input from the first user, determining whether the first user has reached the limit of concurrent matches representing bidirectional connections, and displaying the profiles representing other users are performed by a dating software application. (In ¶0052: teaches that the “preferred embodiments of the present invention” can be directed to “a dating site, however, it is not limited to just a dating site, but applicable to any social network”.)
Regarding claims 8, 18, 30, 40, 50, 62, 72, 82 and 94:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 1, 11, 21, 33, 43, 53, 65, 75 and 85, respectively.
Lim further teaches:
further comprising: responsive to the first user not having reached the limit of concurrent matches representing bidirectional connections, making the first user available to be matched with other users; and (In ¶0139; Fig. 9 (1373 and 1375); Fig. 10 (1403 – 1405): teaches that “If the user does not have more than three pending requests and the user has sufficient tokens to pay for the communication then the system will allow the request” and “In step 1403, the system places the request in the user's outgoing date request queue 410” which is reflected in “step 1406” wherein, “the system presents the request to the receiving user by placing the request in the receiving user's incoming date request queue 412” which is directed to having the first user being available to other users.)
responsive to the first user having reached the limit of concurrent matches representing bidirectional connections, making the first user unavailable to be matched with other users. (In ¶0138; Fig. 10 (1421): teaches that “when the number reaches zero the user cannot send another outgoing date request 1373 or accept an incoming date request 1374 until additional tokens are obtained” which deems the user unavailable for matching.)
Regarding claims 9, 19, 31, 41, 51, 63, 73, 83 and 95:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 1, 11, 21, 33, 43, 53, 65, 75 and 85, respectively.
This dependent claim set is represented by claim 9
Lim further teaches:
further comprising, prior to determining whether the first user has reached the limit of concurrent matches, establishing the limit of concurrent matches based on at least one selected from the group consisting of: a current status level for the user, wherein different status levels are associated with different match limits; a current experience level for the user, wherein different experience levels are associated with different match limits; and a current service tier to which the user has subscribed, wherein different service tiers are associated with different match limits. (In ¶0141: teaches that the system can allow the “administrator” to configure or set the “number of outgoing date requests 1373 in outgoing request queue 410” and the “system may be modified to accept another number (usually depending on the size of the user population) which achieves all of the same objectives of the invention” (see ¶0139). Further, the user can select “a membership level prior to the request to communicate” which is used as a basis by the system to set “the fee for the communication based on the higher of the corresponding membership levels of the communicating users” (e.g. directed to current service tier), in accordance to the examples given in ¶0070 – 71 from Applicant disclosure. Refer to ¶0103 – 104 for user preferences that set the “membership level” with their “economic status” and/or “status level” directed to current status level for the user or choosing “a diamond member but if the goose is accepted, both members pay the higher cost set by the diamond membership level” directed to a current service tier to which the user has subscribed. Refer to ¶0096 wherein a “full contact request inbox of a recipient may also indicate the potential requester that the recipient is extremely popular and that his/her efforts may be more beneficially directed elsewhere” which suggests that current experience level is considered in the matches limits (see ¶0115 also).)
Regarding claims 10, 20, 32, 42, 52, 64, 74, 84 and 96:
Lim, as shown in the rejection above, discloses the limitations of claims 9, 19, 31, 41, 51, 63, 73, 83 and 95, respectively.
This dependent claim set is represented by claim 10
Lim further teaches:
further comprising, responsive to a change in at least one of the status level for the user, the experience level for the user, and the current service tier to which the user has subscribed, changing the limit of concurrent matches. (In ¶0141: teaches that the system can allow the “administrator” to configure or set the “number of outgoing date requests 1373 in outgoing request queue 410” and the “system may be modified to accept another number (usually depending on the size of the user population) which achieves all of the same objectives of the invention” (see ¶0139). Further, the user can select “a membership level prior to the request to communicate” which is used as a basis by the system to set “the fee for the communication based on the higher of the corresponding membership levels of the communicating users” (e.g. directed to current service tier), in accordance to the examples given in ¶0070 – 71 from Applicant disclosure. Refer to ¶0103 – 104 for user preferences that set the “membership level” with their “economic status” and/or “status level” directed to current status level for the user or choosing “a diamond member but if the goose is accepted, both members pay the higher cost set by the diamond membership level” directed to a current service tier to which the user has subscribed. Refer to ¶0096 wherein a “full contact request inbox of a recipient may also indicate the potential requester that the recipient is extremely popular and that his/her efforts may be more beneficially directed elsewhere” which suggests that current experience level is considered in the matches limits (see ¶0115 also).)
Regarding claims 17, 29, 49, 61, 81 and 93:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 11, 21, 43, 53, 75 and 85, respectively.
This dependent claim set is represented by claim 17
Lim further teaches:
further comprising: responsive to the first user not having reached the limit of concurrent matches representing bidirectional connections, making the first user visible to other users; and (In ¶0139; Fig. 9 (1373 and 1375); Fig. 10 (1404 and 1406): teaches that “If the user does not have more than three pending requests and the user has sufficient tokens to pay for the communication then the system will allow the request” and “In step 1403, the system places the request in the user's outgoing date request queue 410” which is reflected in “step 1406” wherein, “the system presents the request to the receiving user by placing the request in the receiving user's incoming date request queue 412” which is directed to having the first user visible to other users.)
Lim discloses reaching a limit of matches in ¶0087 wherein “users can only request a limited number (e.g. 3) of contact requests (goose requests) at one time” which “minimizes date spamming and places a value on contact requests as a limited resource that encourages users to carefully evaluate (e.g. compatibility, availability, and/or rating) their contact requests”. However, Lim does not explicitly teach the first user becoming specifically invisible, after reaching such limit of matches. Thus, Ding teaches:
responsive to the first user having reached the limit of concurrent matches representing bidirectional connections, making the first user invisible to other users. (In ¶0043 – 44; Fig. 12C: teaches that as shown in Figs. 12A – 12C, the user can add a limited number of users or “crushes” into their “concealed list of persons 109”, after the other person add the user “to their own concealed list 117” in order to make the other person aware (e.g. the user is visible; see ¶0043 – 44). But, when the user reaches the limit number of “crushes”, the user has to wait an amount of time before “the user will be able to add a new person to the crush list” which suggests that the user won’t be visible to other users if their list is saturated or completed, based on the system’s “removal rules” that can be applied and configured by an “administrator” that can include how a user is shown (e.g. directed to user being invisible) in other users’ crush list, in accordance to the examples given in ¶0139 and ¶0159 from Applicant disclosure. Also, refer to ¶0045 for an example wherein “the user 113 is made aware of an anonymous crush or lists someone who does not express a mutual interest within a week or a month or some other time period, the indication of interest may expire and those persons may be removed from the anonymous user's or other user's concealed list of persons” which is another example of the user not being visible in other user’s crush lists.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Lim to provide the ability of making the first user invisible after the limit of matches has been reached, as taught by Ding in order to “prohibit the user 113 from simply identifying everyone in their list of friends and may constrain the user to choose only those persons in whom the user is truly interested” as well as “to maintain the privacy of the user's friends” (¶0037 – 38 and ¶0046; Ding) through “concealed interactions” that are “encrypted, protected by gating credentials, or otherwise removed from the general public” (¶0016; Ding).
Regarding claims 22, 54 and 86:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 21, 53 and 85, respectively.
This dependent claim set is represented by claim 22
Lim teaches that when the user reaches a limit of matchings “user cannot send another outgoing date request 1373 or accept an incoming date request 1374 until additional tokens are obtained” and at “step 1421, the soliciting user will be prevented from making any further requests and is informed that he or she must wait until either a pending outgoing date request times out or is accepted by a solicited user” (see ¶0138 and ¶0140; Lim). However, Lim does not teach the ability of specifically displaying a message. Thus, Ding further teaches:
further comprising, responsive to the first user having reached the limit of concurrent matches representing bidirectional connections, displaying a message indicating that functionality to view profiles representing other users is unavailable. (See Fig. 12A: shows that the user is informed that they need to remove someone to “make space for a new crush”. Thereby declining the request until the user removes someone (see ¶0043 for more details). Also, refer to Fig. 12C wherein a message is shown informing the user that they “can’t add more crushes today. Come back tomorrow to add one more” which suggests that the functionality to view profiles representing other users is unavailable.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Lim to provide the ability of ability of specifically displaying a message, as taught by Ding in order to inform and remind the user of the prohibition of “simply identifying everyone in their list of friends and may constrain the user to choose only those persons in whom the user is truly interested” as well as “to maintain the privacy of the user's friends” (¶0037 – 38 and ¶0046; Ding) through “concealed interactions” that are “encrypted, protected by gating credentials, or otherwise removed from the general public” (¶0016; Ding).
Regarding claims 23, 55 and 87:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 21, 53 and 85, respectively.
This dependent claim set is represented by claim 23
Lim further teaches:
wherein displaying profiles representing other users comprises: selecting profiles representing users who are prospective matches for the first user; and displaying the selected profiles. (In ¶0134; Fig. 7 (1211 and 1212): teaches that upon searching users filtered by entered criteria a list of profiles is returned, in “step 1211, the searching user selects to view the characteristic data, or “profile,” of another user who was in the list of users returned by the system” and “in step 1212, the system then displays the selected user's profile on the screen”.)
Regarding claims 71, 80 and 92:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 66, 75 and 85, respectively.
This dependent claim set is represented by claim 71
Lim further teaches:
wherein the input device, the processor, and the network communication component operate under the direction of a dating software application running on the first network-connected device. (In ¶0051 – 52: teaches that the invention that describes “online dating website systems that use internet network architecture and infrastructure” also employs “typical email and instant messaging systems within internet network and other computer network architectures, and includes desktop and laptop computers, smart-mobile phones, PDAs, or any other devices with internet capability”. Also, “preferred embodiments of the present invention” can be directed to “a dating site, however, it is not limited to just a dating site, but applicable to any social network”.)
Regarding claims 97 - 105:
The combination of Lim and Ding, as shown in the rejection above, discloses the limitations of claims 1, 11, 21, 33, 43, 53, 65, 75 and 85, respectively.
Lim further teaches:
wherein the limit of concurrent matches is one concurrent match. (See Figs. 9 – 10: teaches an indication of a match limit as shown in Fig. 9 for “My Token Bank” and in “My Token Bank”; Fig. 10 steps 1442-1445 from Fig. 10 (see ¶0139 and ¶0141 for more details).)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Robson (U.S. Pub No. 20110219310 A1) is pertinent because it “relates to electronic dating and matching techniques in a computer based social networking or electronic dating service.”
Millership (U.S. Pub No. 20170024699 A1) is pertinent because it “relates to a method of setting up online matchmaking meetings between participants and to an online matchmaking system.”
Bapat (U.S. Pub No. 20180234427 A1) is pertinent because it “relates to systems and methods for identifying people in common between two users on a social network service. The present disclosure advantageously provides systems and methods for identifying people in common between a first user and a second user from a perspective of the first user.”
Jackson (U.S. Pub No. 20160112363 A1) is pertinent because it “relates to on-line dating and, more specifically, to a system and method for providing automated reminders to individuals that have expressed mutual interest in one another.”
Wang (U.S. Pub No. 20180262586 A1) is pertinent because it is “related to a social network information match-up system and method thereof.”
Springstroh (U.S. Pub No. 20230368047 A1) is pertinent because it is “directed to systems and methods for facilitating conversation between potential matches in an online dating service.”
Du (U.S. Pub No. 20110040693 A1) is pertinent because it is “a method of restricting access to a user of a social networking website. The method comprises identifying the user of the social networking website as an outstanding user; initiating, with a server computer, a bidding process for the opportunity to contact the outstanding user; and allowing contact with the outstanding user by a high bidder in the bidding process.”
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ivonnemary Rivera Gonzalez whose telephone number is (571)272-6158. The examiner can normally be reached Mon - Fri 9:00AM - 5:30PM.
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, Nathan Uber can be reached at (571) 270-3923. 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.
/IVONNEMARY RIVERA GONZALEZ/Examiner, Art Unit 3626
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights