DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 of the instant application are rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims 1-20 of Bodarenko et al, U.S. Patent 12,335,221 B2 (hereinafter Patent ‘221). Although the conflicting claims are not identical, they are not patentably distinct from each other.
The subject matter claimed in the instant application is technically disclosed in the patent since the patent and the instant application are claiming common and/or overlapping subject matter. Independent claims 1, 11 and 16 of the instant application and independent claims 1, 10 and 16 of the patent both recite, in part,
A computer-implemented method, comprising:
obtaining one or more criteria for identifying potential matches between an individual and one or more other individuals;
identifying potential matches between the individual and one or more individuals from a pool of individuals based on the one or more criteria;
selecting a subset of potential matches from the identified potential matches, the subset of potential matches having up to a predetermined number of potential matches;
determining a next scheduled occurrence of a recurring interval for supplying matches to users; and
supplying, to a client device associated with the individual, profile information for the subset of potential matches at the next scheduled occurrence of the recurring interval for supplying matches to users..
Claims 21-40 of the instant application are drawn to the same invention as Patent ‘266, with the exception of “supplying to a client device data for display in a graphical user interface, the data including a set of prompts to an individual to specify criteria for identification of one or more other individuals; receiving the criteria from the client device…” – as currently recited by Patent ‘221.
The claimed invention in the instant application implements the methodology described by the patent, but is lacking the above aforementioned additional claim feature(s) or limitation(s). Accordingly, Claims 1-20 of Patent ‘221 anticipates all of the limitations of the instant application.
In removing this limitation, the scope of the claim(s) is merely broadened by eliminating elements and their functions. It has been held that omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184 (CCPA). Also note Ex parte Rainu, 168 USPQ 365 (Bd. App. 1969) (omission of a reference element whose function is not needed would be obvious to one skilled in the art).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rad et al (hereinafter Rad), US Patent 11513666 B2 (filing date February 2019) in view of Frolovichev et al (hereinafter Frolovichev), WIPO Publication WO 2020089813 A1 (publication date May 2020)
As per claims 1, 11, 16, Rad discloses particular recited feature(s) of the claimed invention, such as computer-implemented method, comprising:
obtaining one or more criteria for identifying potential matches between an individual and one or more other individuals (Rad: e.g., the method for profile matching includes receiving user ‘preference{s} indication’ for a particular user profile of the plurality of user profiles used in matching a first user with one or more user profile ‘potential match{es}’) [Abstract; Fig. 1a] (e.g., For example, people having ‘similar and/or compatible character traits and values’ {potential match criteria} should be ‘matched’ together ) [col 1, L47-478]
(e.g., As an example only, consider a case where User 14 is interested in participating in an ‘on-line dating’ scenario. User 14 can access the Internet via terminal 10, travel to a web site managed by matching server 20, and begin the registration process. As part of the ‘registration’ process, Matching server 20 may ask user 14 a series of ‘questions’ which identifies ‘characteristics’ about User 14…Matching server 20 may further use the ‘registration’ process to discover what user 14 may be ‘looking for’ in a match, such as ‘age’, ‘weight’, ‘height’, ‘location’, ‘ethnicity’, ‘diet’, ‘education’, etc. {user profile ‘preferences’ / ‘search criteria’}. Further, Matching server 20 may ask User 14 to ‘indicate’ how important certain ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are when looking for a match. For example, Matching server 20 may allow the user to ‘indicate’ which ‘characteristics’ {user profile ‘preferences’ / ‘search criteria’} in a potential match are a ‘necessity’. In another example, Matching server 20 may ask, “How important is it that your match does not smoke?” Matching server 20 may also allow the user to indicate that ‘certain characteristics’ {user profile ‘preferences’ / ‘search criteria’} are ‘not important’ search criteria. For example, when asking User 14 about what ‘height’ or ‘weight’ User 14 is ‘seeking’ in a match, Matching server 20 may be configured to receive “not important” as a response. In yet another example, Matching server 20 may allow User 14 to ‘rate’ which ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are important on a numerical scale. For example, Matching server 20 may ask User 14 the following: “On a scale of ‘1-10’, how ‘important’ is it that your match has ‘the same education level’ as you?” In some embodiments, Matching server 20 may specify that any number of questions or requested descriptions are necessary before registration may be concluded. As an example only, Matching server 20 may require that User 14 communicate the ‘sex’ of user 14 and the ‘sex’ User 14 ‘prefers’ to be matched with. After concluding the registration process, matching server 20 may store the responses of user 14 as a ‘profile’. This same process may be repeated by several different users 14, causing Matching server 20 to contain a ‘plurality of profiles’) [col 5, L9-46];
identifying potential matches between the individual and one or more individuals from a pool of individuals based on the one or more criteria (Rad: e.g., FIG. 1D depicts an embodiment in which Matching server 20 has a database 26a which contains a ‘pool’_30. Each entry in database 26a has a ‘pool entity’ 30a along with information concerning that entity. In one embodiment, each ‘Pool entity’ 30a-e represents a ‘user and their profile’…As discussed further below, Matching server 20 may use a ‘selection’ process for including stored profiles in pool 30. As depicted in FIG. 1D, in this embodiment, the ‘collection of users and profiles’ forms ‘pool’ 30 through which Matching server 20 may perform various functions such as ‘searches for matches’) [col 5, L 47-57, Fig. 1d];
selecting a subset of potential matches from the identified potential matches (Rad: e.g., FIG. 1D depicts an embodiment in which Matching server 20 has a database 26a which contains a ‘pool’_30. Each entry in database 26a has a ‘pool entity’ 30a along with information concerning that entity. In one embodiment, each ‘Pool entity’ 30a-e represents a ‘user and their profile’…As discussed further below, Matching server 20 may use a ‘selection’ process for including stored profiles in pool 30. As depicted in FIG. 1D, in this embodiment, the ‘collection of users and profiles’ forms ‘pool’ 30 through which Matching server 20 may perform various functions such as ‘searches for matches’) [col 5, L 47-57, Fig. 1d] (e.g., As an ‘example’, consider that User 14 has submitted a ‘search request’ to matching server 20. Matching server 20 may ‘search’ through pool 30, “identify results”, and ‘communicate Result list 31 to User 14’ which would contain ‘other users’ {subset of potential matches from Pool 30 of entity / user profiles} for whom Matching server 20 had created a profile and who were ‘identified’ through a ‘search’ and ‘selection’ process. Next, user 14 may be interested in learning more ‘Jane Doe’, ‘Entity_31a’ {one of the identified or selected ‘entities’ / ‘users’ with a matching ‘profile’}; thus, user 14 would click view button 33 associated with Jane Doe. Matching server 20 would receive this request and respond by displaying Jane Doe's profile (stored in memory 26), as depicted in FIG. 1F) [col 6, L24-34; Fig. 1d-f], the subset of potential matches having up to a predetermined number of potential matches (Rad: e.g., expressly discloses / illustrates in one aspect and with reference to Fig. 2, and particularly 12a, Harry’s Results list_31 comprising and presenting at least three potential matches {i.e., ‘Jane Doe’, ‘Jan Boe’, ‘Jane Loe’} as a result of a search conducted by Matching Server_20 ) [col 9, L30-45; Figs. 1a & 2]; and
supplying, to a client device associated with the individual, profile information for the subset of potential matches (Rad: e.g., Matching server 20 may be configured to ‘search’ through pool 30 and ‘present matches’ to user 14. In FIG. 1E, one embodiment of this presentation is depicted as occurring through display 12. In various embodiments, ‘matches’ may be presented to user 14 utilizing other communication schemes, such as electronic messages (i.e., ‘e-mail’) or ‘text messages’ (i.e., utilizing SMS). In the depicted embodiment, a ‘result list’ 31 is presented to user 14. A ‘match’ result entity_31a in a result list 31 may be associated with a view button 33. Using interface 16, User 14 may request that Matching server 20 provide ‘more information’ about an ‘entity’ {entity / user ‘profile information’} in result list 31 by pressing the associated ‘view’ button 33. Matching server 20 may then communicate to user 14 more information about that entity by retrieving the ‘information’ {entity / user ‘profile information’} from memory 26. In FIG. 1F, one embodiment of information that matching server 20 provides for user 14 is shown. Using display 12, user 14 ‘views an entity’ from result list 31. Matching server 20 may also provide user 14 with the ability to contact the entity through a contact button 35. In one embodiment, when contact button 35 is utilized by user 14, Matching server 20 may provide user 14 with ‘contact information’ of the entity such as a telephone number or an e-mail address) [col 5, L58 – col 6, L16; Fig. 1e-f] (e.g., As an ‘example’, consider that User 14 has submitted a ‘search request’ to matching server 20. Matching server 20 may ‘search’ through pool 30, identify results, and ‘communicate Result list 31 to user 14’ which would contain ‘other users’ {subset of ‘potential matches’ from Pool 30 of entity / user profiles} for whom Matching server 20 had created a profile and who were ‘identified’ through a ‘search’ and ‘selection’ process. Next, User 14 may be interested in learning more about ‘Jane Doe’, ‘Entity_31a’ {one of the identified or selected ‘entities’ / ‘users’ with a matching ‘profile’}; thus, user 14 would click view button 33 associated with Jane Doe. Matching server 20 would receive this request and respond by displaying Jane Doe's profile (stored in memory 26), as depicted in FIG. 1F ) [col 6, L24-34; Fig. 1d-f]
Rad discloses claimed features of the invention as above, but does not expressly disclose the additional recited feature{s} of method further comprising ‘determining a next scheduled occurrence of a recurring interval for supplying matches to users’; and
supplying, to a client device associated with the individual, profile information for the subset of potential matches ‘at the next scheduled occurrence of the recurring interval for supplying matches to users’. Nonetheless, the feature{s} is/are expressly disclosed by Frolovichev in a related endeavor.
Frolovichev particularly discloses the additional recited feature{s} of method further comprising ‘determining a next scheduled occurrence of a recurring interval for supplying matches to users’; and supplying, to a client device associated with the individual, profile information for the subset of potential matches ‘at the next scheduled occurrence of the recurring interval for supplying matches to users’ (Frolovichev: e.g., expressly discloses that in general, a User of a client device may create a personal ‘profile’ to participate in a ‘dating application’, ‘social network, etc’.. A user’s personal profile may include a name, age, city, photographs, biographical text, links to social media profiles on other networks, and a range of other fields that allow the user to ‘characterize’ himself or herself….In some embodiments, a User is able to ‘filter’ the profiles of other users that are served to them for viewing through ‘setting’ ‘restrictions upon the ‘age’, ‘location’, or potentially ‘any other personal attribute’ {filtering preferences / criteria}….In some embodiments, a server can invite users to ‘vote’ on a preference for an activity during an “ephemeral time period”. Users have an option to join or not join. The ephemeral ‘time period’ may be a pre-determined ‘time of a day’ {i.e., “Happy Hour between 5 and 7 pm”}. A user may receive ‘profiles of other users’ who have met the ‘filtering criteria’ or who have ‘cast a common vote’, or both. The user is able to explore the personal information that has been added to a profile. Profiles may be served to the user one-by- one, with the option to look through multiple pictures per profile, expand text, and click through to external information and profiles on other social networks) [pg. 9, L24 – pg. 10, L7; pg. 12, L3 – pg. 13, L14 & pg. 12, L25 – pg. 13, L21; Figs. 2-4].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify and/or combine Rad’s invention with the above said additional feature, as expressly disclosed by Frolovichev, for the motivation of providing a computer implemented method that supplies to a client device prompts for a first individual to specify ‘matching criteria’ for a potential matches and/or introduction to a second individual, and wherein the matching criteria includes a ‘filter’ to sort a pool of individuals by a ‘facial feature’ categorized by a facial recognition module, for example, as well as ‘other filters’ or criteria {i.e., ‘votes’ that takes place during an ‘ephemeral time period’ {i.e., such as during ‘Happy Hours’ taking place between 5-7pm at an establishment} [Frolovichev: Abstract, Summary pg. 1, L20-26; Figs. 2-4].
Claim(s) 11, 16, recite(s) substantially the same limitations as claim 1, is/are distinguishable only by its/their statutory category (system, non-transitory CRSM), and accordingly rejected on the same basis.
As per claims 2, 12, 17, Rad discloses the method comprising wherein the one or more criteria are obtained based at least in part on profile information associated with the individual (Rad: e.g., As an example only, consider a case where User 14 is interested in participating in an ‘on-line dating’ scenario. User 14 can access the Internet via terminal 10, travel to a web site managed by matching server 20, and begin the registration process. As part of the ‘registration’ process, Matching server 20 may ask user 14 a series of ‘questions’ which identifies ‘characteristics’ about User 14…Matching server 20 may further use the ‘registration’ process to discover what user 14 may be ‘looking for’ in a match, such as ‘age’, ‘weight’, ‘height’, ‘location’, ‘ethnicity’, ‘diet’, ‘education’, etc. {user profile ‘preferences’ / ‘search criteria’}. Further, Matching server 20 may ask User 14 to ‘indicate’ how important certain ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are when looking for a match. For example, Matching server 20 may allow the user to ‘indicate’ which ‘characteristics’ {user profile ‘preferences’ / ‘search criteria’} in a potential match are a ‘necessity’. In another example, Matching server 20 may ask, “How important is it that your match does not smoke?” Matching server 20 may also allow the user to indicate that ‘certain characteristics’ {user profile ‘preferences’ / ‘search criteria’} are ‘not important’ search criteria. For example, when asking User 14 about what ‘height’ or ‘weight’ User 14 is ‘seeking’ in a match, Matching server 20 may be configured to receive “not important” as a response. In yet another example, Matching server 20 may allow User 14 to ‘rate’ which ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are important on a numerical scale. For example, Matching server 20 may ask User 14 the following: “On a scale of ‘1-10’, how ‘important’ is it that your match has ‘the same education level’ as you?” In some embodiments, Matching server 20 may specify that any number of questions or requested descriptions are necessary before registration may be concluded. As an example only, Matching server 20 may require that User 14 communicate the ‘sex’ of user 14 and the ‘sex’ User 14 ‘prefers’ to be matched with. After concluding the registration process, matching server 20 may store the responses of user 14 as a ‘profile’. This same process may be repeated by several different users 14, causing Matching server 20 to contain a ‘plurality of profiles’) [col 5, L9-46].
As per claims 3, 13, 18, Rad discloses the method further comprising supplying, to the client device, data for display in a graphical user interface, the data including one or more questions for identification of the one or more other individuals and predefined answers for each of the one or more questions; and receiving, from the client device, selection data specifying an answer selected from the predefined answers for each of the one or more questions, wherein the one or more criteria are obtained based at least in part on the selection data (Rad: e.g., As an example only, consider a case where User 14 is interested in participating in an ‘on-line dating’ scenario. User 14 can access the Internet via terminal 10, travel to a web site managed by matching server 20, and begin the registration process. As part of the ‘registration’ process, Matching server 20 may ask user 14 a series of ‘questions’ which identifies ‘characteristics’ about User 14…Matching server 20 may further use the ‘registration’ process to discover what user 14 may be ‘looking for’ in a match, such as ‘age’, ‘weight’, ‘height’, ‘location’, ‘ethnicity’, ‘diet’, ‘education’, etc. {user profile ‘preferences’ / ‘search criteria’}. Further, Matching server 20 may ask User 14 to ‘indicate’ how important certain ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are when looking for a match. For example, Matching server 20 may allow the user to ‘indicate’ which ‘characteristics’ {user profile ‘preferences’ / ‘search criteria’} in a potential match are a ‘necessity’. In another example, Matching server 20 may ask, “How important is it that your match does not smoke?” Matching server 20 may also allow the user to indicate that ‘certain characteristics’ {user profile ‘preferences’ / ‘search criteria’} are ‘not important’ search criteria. For example, when asking User 14 about what ‘height’ or ‘weight’ User 14 is ‘seeking’ in a match, Matching server 20 may be configured to receive “not important” as a response. In yet another example, Matching server 20 may allow User 14 to ‘rate’ which ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are important on a numerical scale. For example, Matching server 20 may ask User 14 the following: “On a scale of ‘1-10’, how ‘important’ is it that your match has ‘the same education level’ as you?” In some embodiments, Matching server 20 may specify that any number of questions or requested descriptions are necessary before registration may be concluded. As an example only, Matching server 20 may require that User 14 communicate the ‘sex’ of user 14 and the ‘sex’ User 14 ‘prefers’ to be matched with. After concluding the registration process, matching server 20 may store the responses of user 14 as a ‘profile’. This same process may be repeated by several different users 14, causing Matching server 20 to contain a ‘plurality of profiles’) [col 5, L9-46].
As per claims 4, 14, 19, Rad discloses the method wherein identifying the potential matches between the individual and the one or more other individuals comprises: identifying a plurality of distinct groups of individuals from the pool of individuals; and applying the one or more criteria to each of the plurality of distinct groups of individuals to identify the potential matches (Rad: e.g., FIG. 1D depicts an embodiment in which Matching server 20 has a database 26a which contains a ‘pool’_30. Each entry in database 26a has a ‘pool entity’ 30a along with information concerning that entity. In one embodiment, each ‘Pool entity’ 30a-e represents a ‘user and their profile’…As discussed further below, Matching server 20 may use a ‘selection’ process for including stored profiles in pool 30. As depicted in FIG. 1D, in this embodiment, the ‘collection of users and profiles’ forms ‘pool’ 30 through which Matching server 20 may perform various functions such as ‘searches for matches’) [col 5, L 47-57, Fig. 1d] (e.g., As an ‘example’, consider that User 14 has submitted a ‘search request’ to matching server 20. Matching server 20 may ‘search’ through pool 30, “identify results”, and ‘communicate Result list 31 to User 14’ which would contain ‘other users’ {subset of potential matches from Pool 30 of entity / user profiles} for whom Matching server 20 had created a profile and who were ‘identified’ through a ‘search’ and ‘selection’ process. Next, user 14 may be interested in learning more ‘Jane Doe’, ‘Entity_31a’ {one of the identified or selected ‘entities’ / ‘users’ with a matching ‘profile’}; thus, user 14 would click view button 33 associated with Jane Doe. Matching server 20 would receive this request and respond by displaying Jane Doe's profile (stored in memory 26), as depicted in FIG. 1F) [col 6, L24-34; Fig. 1d-f].
As per claims 5, Rad in view of Frolovichev, and Frolovichev, in particular, discloses the method wherein identifying the plurality of distinct groups of individuals comprises applying at least one criteria related to use of a social media application to the pool of individuals (Frolovichev: e.g., Implementations may include one or a combination of two or more of the following features. The verified status may be based upon a ‘verified profile’. The verified profile may include a minimum number of ‘profile parameters’. The verified profile may include parameters ‘verified via a social network’….Enabling may include assigning a received message a priority value. The priority value may be associated with one of a plurality of discrete message priority categories. Enabling may include supplying to a client device a ‘designated emoticon’, in which selection of the designated emoticon overrides a communication restriction associated with enabling network communication. The communication restriction may include a feature that a female initiate network communication… in general, in third aspect, combinable with any of the previously listed aspects, a computer implemented method includes receiving from a client device, via a network, a description of a ‘social media’ event. The description of the social media event specifies a ‘video streaming event’ and a ‘level of support’ for initiating the social media event. The description of the social media event is broadcasted via the network to client devices. Support pledges from the client devices are collected via the network. Final event details are established after the level of support for initiating the social media event is received.) [pg. 2, L20 -- pg. 3, L11].
As per claims 6, Rad in view of Frolovichev, and Frolovichev in particular, discloses the method wherein identifying the plurality of distinct groups of individuals comprises applying two or more different matching models to the pool of individuals (Frolovichev: e.g., expressly discloses that in general, a User of a client device may create a personal ‘profile’ to participate in a ‘dating application’, ‘social network, etc’.. A user’s personal profile may include a name, age, city, photographs, biographical text, links to social media profiles on other networks, and a range of other fields that allow the user to ‘characterize’ himself or herself….In some embodiments, a User is able to ‘filter’ the profiles of other users that are served to them for viewing through ‘setting’ ‘restrictions upon the ‘age’, ‘location’, or potentially ‘any other personal attribute’ {filtering preferences / criteria}….In some embodiments, a server can invite users to ‘vote’ on a preference for an activity during an “ephemeral time period”. Users have an option to join or not join. The ephemeral ‘time period’ may be a pre-determined ‘time of a day’ {i.e., “Happy Hour between 5 and 7 pm”}…A user may receive ‘profiles of other users’ who (i) have met the ‘filtering criteria’ or (ii) who have ‘cast a common vote’, or {iii} both. The user is able to explore the personal information that has been added to a profile. Profiles may be served to the user one-by- one, with the option to look through multiple pictures per profile, expand text, and click through to external information and profiles on other social networks) [pg. 9, L24 – pg. 10, L7; pg. 12, L3 – pg. 13, L14 & pg. 12, L25 – pg. 13, L21; Figs. 2-4].
As per claims 7, Rad discloses the method wherein selecting the subset of potential matches from the potential matches comprises selecting at least one potential match from each of the plurality of distinct groups (Rad: e.g., For example, people having ‘similar and/or compatible character traits and values’ {potential match criteria} should be ‘matched’ together ) [col 1, L47-478] (e.g., As an example only, consider a case where User 14 is interested in participating in an ‘on-line dating’ scenario. User 14 can access the Internet via terminal 10, travel to a web site managed by matching server 20, and begin the registration process. As part of the ‘registration’ process, Matching server 20 may ask user 14 a series of ‘questions’ which identifies ‘characteristics’ about User 14…Matching server 20 may further use the ‘registration’ process to discover what user 14 may be ‘looking for’ in a match, such as ‘age’, ‘weight’, ‘height’, ‘location’, ‘ethnicity’, ‘diet’, ‘education’, etc. {user profile ‘preferences’ / ‘search criteria’}. Further, Matching server 20 may ask User 14 to ‘indicate’ how important certain ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are when looking for a match. For example, Matching server 20 may allow the user to ‘indicate’ which ‘characteristics’ {user profile ‘preferences’ / ‘search criteria’} in a potential match are a ‘necessity’. In another example, Matching server 20 may ask, “How important is it that your match does not smoke?” Matching server 20 may also allow the user to indicate that ‘certain characteristics’ {user profile ‘preferences’ / ‘search criteria’} are ‘not important’ search criteria. For example, when asking User 14 about what ‘height’ or ‘weight’ User 14 is ‘seeking’ in a match, Matching server 20 may be configured to receive “not important” as a response. In yet another example, Matching server 20 may allow User 14 to ‘rate’ which ‘factors’ {user profile ‘preferences’ / ‘search criteria’} are important on a numerical scale. For example, Matching server 20 may ask User 14 the following: “On a scale of ‘1-10’, how ‘important’ is it that your match has ‘the same education level’ as you?” In some embodiments, Matching server 20 may specify that any number of questions or requested descriptions are necessary before registration may be concluded. As an example only, Matching server 20 may require that User 14 communicate the ‘sex’ of user 14 and the ‘sex’ User 14 ‘prefers’ to be matched with. After concluding the registration process, matching server 20 may store the responses of user 14 as a ‘profile’. This same process may be repeated by several different users 14, causing Matching server 20 to contain a ‘plurality of profiles’) [col 5, L9-46] (e.g., As an ‘example’, consider that User 14 has submitted a ‘search request’ to matching server 20. Matching server 20 may ‘search’ through pool 30, “identify results”, and ‘communicate Result list 31 to User 14’ which would contain ‘other users’ {subset of potential matches from Pool 30 of entity / user profiles} for whom Matching server 20 had created a profile and who were ‘identified’ through a ‘search’ and ‘selection’ process. Next, user 14 may be interested in learning more ‘Jane Doe’, ‘Entity_31a’ {one of the identified or selected ‘entities’ / ‘users’ with a matching ‘profile’}; thus, user 14 would click view button 33 associated with Jane Doe. Matching server 20 would receive this request and respond by displaying Jane Doe's profile (stored in memory 26), as depicted in FIG. 1F) [col 6, L24-34; Fig. 1d-f].
As per claims 8, 15, 20, Rad discloses the method wherein each of the potential matches are associated with a rank or score, and wherein the potential match selected from each of the plurality of distinct groups comprises the potential match having the highest rank or score within the group (Rad: e.g., In some embodiments, matching server 20 may be configured to apply a relevance algorithm which determines the content and ‘order’ {rank} in which matching server 20 displays potential matches to user 14 ) [col 20, L33-336] (e.g., Applying Scoring Algorithms_66 and Tabulate Scores_68) [Fig. 5].
As per claims 9, Rad discloses the method wherein identifying the potential matches between the individual and the one or more other individuals comprises applying at least one filter to the pool of individuals based on the one or more criteria (Rad: e.g., ‘Generate Pool’_62 and ‘Apply Filter’_64) [Fig. 5].
As per claims 10, Rad discloses the method further comprising collecting a match acceptance from the client device for a second individual identified in the subset of potential matches; and in response to the match acceptance, enabling network communication between the individual and the second individual (Rad: e.g., Matching server 20 may be configured to ‘search’ through pool 30 and ‘present matches’ to user 14. In FIG. 1E, one embodiment of this presentation is depicted as occurring through display 12. In various embodiments, ‘matches’ may be presented to user 14 utilizing other communication schemes, such as electronic messages (i.e., ‘e-mail’) or ‘text messages’ (i.e., utilizing SMS). In the depicted embodiment, a ‘result list’ 31 is presented to user 14. A ‘match’ result entity_31a in a result list 31 may be associated with a view button 33. Using interface 16, User 14 may request that Matching server 20 provide ‘more information’ about an ‘entity’ {entity / user ‘profile information’} in result list 31 by pressing the associated ‘view’ button 33. Matching server 20 may then communicate to user 14 more information about that entity by retrieving the ‘information’ {entity / user ‘profile information’} from memory 26. In FIG. 1F, one embodiment of information that matching server 20 provides for user 14 is shown. Using display 12, user 14 ‘views an entity’ from result list 31. Matching server 20 may also provide user 14 with the ability to contact the entity through a contact button 35. In one embodiment, when contact button 35 is utilized by user 14, Matching server 20 may provide user 14 with ‘contact information’ of the entity such as a telephone number or an e-mail address) [col 5, L58 – col 6, L16; Fig. 1e-f].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-7989. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451
