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 .
Response to Arguments
Regarding the objection of claim 5, the claim amendment is sufficient to overcome the claim objection. Therefore, the claim objection is withdrawn.
Regarding the 35 USC 112(f) claim interpretation, Examiner has fully considered Applicant’s arguments and amendments. With respect to claim 1, the claim has been amended to remove the language that invoked 35 USC 112(f). Therefore, the claim interpretation with respect to claim 1 has been withdrawn. With respect to claim 8, the claim recites limitations that invoke 35 USC 112(f). Therefore, the claims are interpreted in view of 35 USC 112(f). See the claim interpretation section below.
Accordingly, the 35 USC 112(f) interpretation is maintained.
Regarding the 35 USC 101 rejection, Examiner has fully considered Applicant’s arguments and amendments. Examiner has deemed Applicant’s assertions, in view of the broadest reasonable interpretation of the present claims, persuasive. The present claims recite a combination of additional elements that, as drafted, including notifying a terminal, receiving from an entry control terminal installed at an entrance of the event venue, an entry determination request including a face image captured by a camera of the entry control terminal, transmitting a face authentication request including the face image to an authentication apparatus, receiving a face authentication result from the authentication apparatus, and based on the face authentication result indicating success, control the entry control terminal to unlock an entrance gate of the event venue, are more than mere use of a computer as a tool. The combination of additional elements is sufficient to prove integration into a practical application because the claims apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. See MPEP 2106.05(e).
Accordingly, the 35 USC 101 rejection has been withdrawn.
Regarding the 35 USC 102 rejection, Examiner has fully considered Applicant’s arguments and amendments. Applicant’s arguments with respect to the previous prior art combination of the record have been considered but are moot because the new grounds of rejection does not rely on any reference applied in the prior art rejection for any teachings or matter specifically challenged in the argument. The claims are rejected under a new grounds of rejection, which was necessitated by amendment. Examiner has introduced the Sun reference to cure the deficiencies of the prior art combination of the record.
Accordingly, the 35 USC 102 rejection has been withdrawn; however, the present claims are rejected under 35 USC 103.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “storage apparatus” and “storage device” of claim 8.
When looking to the specification, the hardware structure associated with the “storage device” is being interpreted as “memory,” please see at least Figs. 1, 5, 7, 8 and [0037-0038, 0043-0044, 0048-0049] of the instant specification. See MPEP 2181(II)(B).
When looking to the specification, the hardware structure associated with the “storage apparatus” is being interpreted as “memory,” please see at least Figs. 1, 5 and [0019-0021, 0055] of the instant specification. See MPEP 2181(II)(B).
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-11 are rejected under 35 U.S.C. 103 as being unpatentable over Epstein et al. (US 20230099601 A1) in view of Sun et al. (US 11151481 B1).
Regarding claim 1, Epstein teaches a privilege information issuing apparatus comprising (Figs. 1-2, 4, 9):
at least one memory configured to store instructions (Fig. 1 and [0032-0034] teach a venue automation environment, wherein Fig. 4 and [0076-0077] teach an itinerary management system that is a server, wherein the server generates an itinerary, wherein the server contains data storage “416”, wherein [0099] teaches the server comprising a memory subsystem; see also: [0069, 0101], Figs. 8-9); and
at least one processor configured to execute the instructions to (Fig. 1 and [0032-0034] teach a venue automation environment, wherein Fig. 4 and [0076-0077] teach an itinerary management system that is a server, wherein the server generates an itinerary, wherein [0099-0101] teach the server comprises one or more processors that execute a variety of programs; see also: Figs. 8-9):
acquire entry qualification information with which a person with a schedule of entry to an event venue where a predetermined event is held is able to enter the event venue through identity authentication (Fig. 5 and [0079] teach receiving data from a participant including their itinerary information, wherein [0079] teaches receiving itinerary information associated with a participant, wherein as well as in [0110] teaches the participant information includes information about their schedule, which may only include scheduled activities, as well as in [0048-0049] teach the reservation system can access the participant’s itinerary and suggest reservation times adjacent to when the participant is engaging in a nearby activity, wherein the participant identification system can handle automated participant identification by determining an identifier associated with a participant, wherein the identification information is used to identify when a participant is anticipated to soon be at a particular activity, wherein [0041] teaches itinerary generation can be based on schedules associated with a venue and/or activities in a venue, wherein the schedules of reservations from other participants associated with several activities can be accessed so that an optimized schedule can be generated for the participant, wherein an optimized schedule can prioritize location, by performing nearby activities in succession, prioritize duration, by selecting activities to minimize downtime between activities, or other aspects, wherein an activity’s schedule can be assessed to determine potential downtime and try to schedule participants in that downtime to minimize the amount of downtime; see also: [0082-0084, 0152-0153]);
calculate an extra time until a clock time that is attributable to a start of the event from a clock time at which the person with the schedule of entry is scheduled to arrive or arrives in a predetermined region including the event venue on the basis of the entry qualification information ([0041] teaches itinerary generation can be based on schedules associated with a venue and/or activities in a venue, wherein the schedules of reservations from other participants associated with several activities can be accessed so that an optimized schedule can be generated for the participant, wherein an optimized schedule can prioritize location, by performing nearby activities in succession, prioritize duration, by selecting activities to minimize downtime between activities, or other aspects, wherein an activity’s schedule can be assessed to determine potential downtime and try to schedule participants in that downtime to minimize the amount of downtime, wherein [0080-0081] teach accessing activity schedule for the selected venue of venues in order to determine whether an activity is open and available, wherein [0082] teaches a proposed itinerary can be generated for the participant based on activity downtime and participant routing within a venue, wherein [0048] teaches the reservation system can handle automated activity reservation, wherein the automated reservation can include automatically suggested reservation times for a participant to engage in a particular activity, wherein the system can integrate with the itinerary management system to access the participant’s itinerary and suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity; see also: [0034, 0057]);
issue privilege information that is used within the extra time in one or more commercial facilities in a neighborhood of the event venue on the basis of the extra time ([0152] teaches automatically generating the itinerary comprises scheduling a first activity immediately before a subsequent activity, wherein the exit of the first activity is associated with the entrance to a subsequent activity, wherein [0041] teaches itinerary generation can be based on schedules associated with a venue and/or activities in a venue, wherein the schedules of reservations from other participants associated with several activities can be accessed so that an optimized schedule can be generated for the participant, wherein an optimized schedule can prioritize location, by performing nearby activities in succession, prioritize duration, by selecting activities to minimize downtime between activities, or other aspects, wherein an activity’s schedule can be assessed to determine potential downtime and try to schedule participants in that downtime to minimize the amount of downtime, wherein [0034] teaches an itinerary management system that can handle automated itinerary generation, wherein the itineraries can be automatically generated based on participant preferences and additional participant data, wherein a participant identification system, such as an automated participant identification system, can be used to identify a participant at a venue and at an activity to make sure that the participant is authorized to make use of or engage in that venue and activity, wherein [0080-0081] teach accessing activity schedule for the selected venue of venues in order to determine whether an activity is open and available, wherein [0082] teaches a proposed itinerary can be generated for the participant based on the activity schedule information, participant information, activity downtime and participant routing within a venue, wherein [0048] teaches the reservation system can handle automated activity reservation, wherein the automated reservation can include automatically suggested reservation times for a participant to engage in a particular activity, wherein the system can integrate with the itinerary management system to access the participant’s itinerary and suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity; see also: [0057]); and
notify a terminal of the person with the schedule of entry of the issued privilege information (Fig. 5 and [0083] teach the proposed itinerary can be transmitted to the participant digitally, wherein the modifications to the proposed itinerary can be received, wherein this modification can include adding activities, wherein [0048] teaches the reservation system can handle automated activity reservation, wherein the automated reservation can include automatically suggested reservation times for a participant to engage in a particular activity, wherein the system can integrate with the itinerary management system to access the participant’s itinerary and suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity, [0110] teaches the participant information includes information about their schedule, which may only include scheduled activities, or wherein the schedule may display suggested activities for the participant, such as suggested activities located nearby existing itinerary items that also have open time slots, as well as in [0093-0094] teach suggesting an itinerary based on the participant’s current location and receiving confirmation of the proposed schedule modification; see also: [0040, 0079-0082]),
wherein the at least one processor is further configured to execute the instructions to: receive, a face image captured by a camera ([0049] teaches the participant identification system can handle automated participant identification, wherein the identification information includes a recognized facial pattern that can be obtained through cameras, wherein facial recognition can be performed, as well as in [0050] teaches a participant’s biometric data can be used as an identifier, such as a fingerprint, retinal, or facial scan; see also: [0051]).
However, Epstein does not explicitly teach receive, from an entry control terminal installed at an entrance of the event venue, an entry determination request including a face image captured by a camera of the entry control terminal; transmit a face authentication request including the face image to an authentication apparatus; receive a face authentication result from the authentication apparatus; and based on the face authentication result indicating success, control the entry control terminal to unlock an entrance gate of the event venue.
From the same or similar field of endeavor, Sun teaches receive, from an entry control terminal installed at an entrance of the event venue, an entry determination request including a face image captured by a camera of the entry control terminal (Fig. 6 and Col 18 lines 20-32 teach the system may identify a user, determine an account associated with the user, and determine that the user is allowed access to the restricted location, e.g. event, wherein the system needs to be configured to allow access and deny access, which can be done including automated gates that may detect the user as the user approaches, determine whether to allow or deny access to the user, and either open to allow access or remain closed to deny access, wherein the user can be detected using facial recognition, wherein Col 10 lines 13-24 teach capturing image data using cameras and performing facial recognition on the image data to identify a face associated with the user and determine the account associated with the user in order to verify the account associated with the user, wherein Col 9 line 57 to Col 10 line 2 teaches the server can perform multiple functions, wherein Col 20 lines 53-67 teach determining an identity using facial recognition and issuing a radio frequency identification device, wherein the system may receive a first image data corresponding to the entrance of a restricted location, wherein the image data may include a face represented in the first image data, wherein the system may determine a confidence score that the face is associated with an identifier, wherein the system may determine a confidence score associated with the face and the identifier, wherein Col 21 lines 1-19 teach the system may determine that the account is allowed access to the restricted location based on a threshold and may associate the person with a radio frequency identification signal, wherein the system may receive an RFID signal at an automated gate in the entrance and allow entrance to the event, wherein Col 22 lines 25-46 teach the server includes data regarding user accounts, wherein the user profile storage can include information about identities of the user, biometric data including facial recognition data, and other information associated with the individual user associated with the account; see also: Col 13 line 59 to Col 14 line 26, Col 21 lines 20-33);
transmit a face authentication request including the face image to an authentication apparatus (Fig. 6 and Col 18 lines 20-32 teach the system may identify a user, determine an account associated with the user, and determine that the user is allowed access to the restricted location, e.g. event, wherein the system needs to be configured to allow access and deny access, which can be done including automated gates that may detect the user as the user approaches, determine whether to allow or deny access to the user, and either open to allow access or remain closed to deny access, wherein the user can be detected using facial recognition, wherein Col 10 lines 13-24 teach capturing image data using cameras and performing facial recognition on the image data to identify a face associated with the user and determine the account associated with the user in order to verify the account associated with the user, wherein Col 9 line 57 to Col 10 line 2 teaches the server can perform multiple functions, wherein Col 20 lines 53-67 teach determining an identity using facial recognition and issuing a radio frequency identification device, wherein the system may receive a first image data corresponding to the entrance of a restricted location, wherein the image data may include a face represented in the first image data, wherein the system may determine a confidence score that the face is associated with an identifier, wherein the system may determine a confidence score associated with the face and the identifier, wherein Col 21 lines 1-19 teach the system may determine that the account is allowed access to the restricted location based on a threshold and may associate the person with a radio frequency identification signal, wherein the system may receive an RFID signal at an automated gate in the entrance and allow entrance to the event, wherein Col 22 lines 25-46 teach the server includes data regarding user accounts, wherein the user profile storage can include information about identities of the user, biometric data including facial recognition data, and other information associated with the individual user associated with the account; see also: Col 13 line 59 to Col 14 line 26, Col 21 lines 20-33);
receive a face authentication result from the authentication apparatus (Fig. 6 and Col 18 lines 20-32 teach the system may identify a user, determine an account associated with the user, and determine that the user is allowed access to the restricted location, e.g. event, wherein the system needs to be configured to allow access and deny access, which can be done including automated gates that may detect the user as the user approaches, determine whether to allow or deny access to the user, and either open to allow access or remain closed to deny access, wherein the user can be detected using facial recognition, wherein Col 10 lines 13-24 teach capturing image data using cameras and performing facial recognition on the image data to identify a face associated with the user and determine the account associated with the user in order to verify the account associated with the user, wherein Col 9 line 57 to Col 10 line 2 teaches the server can perform multiple functions, wherein Col 20 lines 53-67 teach determining an identity using facial recognition and issuing a radio frequency identification device, wherein the system may receive a first image data corresponding to the entrance of a restricted location, wherein the image data may include a face represented in the first image data, wherein the system may determine a confidence score that the face is associated with an identifier, wherein the system may determine a confidence score associated with the face and the identifier, wherein Col 21 lines 1-19 teach the system may determine that the account is allowed access to the restricted location based on a threshold and may associate the person with a radio frequency identification signal, wherein the system may receive an RFID signal at an automated gate in the entrance and allow entrance to the event, wherein Col 22 lines 25-46 teach the server includes data regarding user accounts, wherein the user profile storage can include information about identities of the user, biometric data including facial recognition data, and other information associated with the individual user associated with the account; see also: Col 13 line 59 to Col 14 line 26, Col 21 lines 20-33); and
based on the face authentication result indicating success, control the entry control terminal to unlock an entrance gate of the event venue (Fig. 6 and Col 18 lines 20-32 teach the system may identify a user, determine an account associated with the user, and determine that the user is allowed access to the restricted location, e.g. event, wherein the system needs to be configured to allow access and deny access, which can be done including automated gates that may detect the user as the user approaches, determine whether to allow or deny access to the user, and either open to allow access or remain closed to deny access, wherein the user can be detected using facial recognition, wherein Col 10 lines 13-24 teach capturing image data using cameras and performing facial recognition on the image data to identify a face associated with the user and determine the account associated with the user in order to verify the account associated with the user, wherein Col 9 line 57 to Col 10 line 2 teaches the server can perform multiple functions, wherein Col 20 lines 53-67 teach determining an identity using facial recognition and issuing a radio frequency identification device, wherein the system may receive a first image data corresponding to the entrance of a restricted location, wherein the image data may include a face represented in the first image data, wherein the system may determine a confidence score that the face is associated with an identifier, wherein the system may determine a confidence score associated with the face and the identifier, wherein Col 21 lines 1-19 teach the system may determine that the account is allowed access to the restricted location based on a threshold and may associate the person with a radio frequency identification signal, wherein the system may receive an RFID signal at an automated gate in the entrance and allow entrance to the event, wherein Col 22 lines 25-46 teach the server includes data regarding user accounts, wherein the user profile storage can include information about identities of the user, biometric data including facial recognition data, and other information associated with the individual user associated with the account; see also: Col 13 line 59 to Col 14 line 26, Col 21 lines 20-33).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Epstein to incorporate the teachings of Sun to include receive, from an entry control terminal installed at an entrance of the event venue, an entry determination request including a face image captured by a camera of the entry control terminal; transmit a face authentication request including the face image to an authentication apparatus; receive a face authentication result from the authentication apparatus; and based on the face authentication result indicating success, control the entry control terminal to unlock an entrance gate of the event venue. One would have been motivated to do so in order to improve a user experience by simplifying the process of entering the event using techniques that do no require direct interaction with the user (Sun, Abstract). By incorporating the teachings of Sun, one would have been able to improve a user experience when attending an event by offering ticketless entry that associates tickets with an account and verifies a user associated with the account through the user of facial recognition (Sun, Col 2 lines 16-33).
Regarding claims 8, 10, and 11, the claims recite limitations already addressed by the rejection of claim 1. Regarding claim 8, Epstein teaches a privilege information issuing system comprising (Figs. 1-2, 4, 9): a storage apparatus that stores entry qualification information with which a person with a schedule of entry is able to enter an event venue where a predetermined event is held through identity authentication, identity authentication information of the person with the schedule of entry who has purchased the entry qualification information, and a terminal that the person with the schedule of entry carries with himself/herself in an associated manner (Fig. 4 and [0076-0077] teach a participant device, such as a smartphone or personal computer, can be used by the participant to interact with the participant device to have the server generate a participant itinerary which can be optionally stored on the participant device, wherein the participant device can store a participant passkey, which is a participant identifier or participant identification information, that is associated with the itinerary, participant, and individual entries of the itinerary, wherein the participant may interact with the device prior to visiting the venue, wherein [0053] teaches the participant identification information includes payment data related to historical purchases; see also: [0096-0099]); and a privilege information issuing apparatus that is connected to the storage apparatus (Fig. 1 and [0032-0034] teach a venue automation environment, wherein Fig. 4 and [0076-0077] teach an itinerary management system that is a server, wherein the server generates an itinerary, wherein the server contains data storage “416”, wherein [0099] teaches the server comprising a memory subsystem and one or more processors; see also: [0069, 0101], Figs. 8-9), and including: at least one storage device configured to store instructions (Fig. 1 and [0032-0034] teach a venue automation environment, wherein Fig. 4 and [0076-0077] teach an itinerary management system that is a server, wherein the server generates an itinerary, wherein the server contains data storage “416”, wherein [0099] teaches the server comprising a memory subsystem; see also: [0069, 0101], Figs. 8-9); and at least one processor configured to execute the instructions to (Fig. 1 and [0032-0034] teach a venue automation environment, wherein Fig. 4 and [0076-0077] teach an itinerary management system that is a server, wherein the server generates an itinerary, wherein [0099-0101] teach the server comprises one or more processors that execute a variety of programs; see also: Figs. 8-9). Regarding claim 10, Epstein teaches a privilege information issuing method comprising, by a computer (Figs. 4-8). Regarding claim 11, Epstein teaches a non-transitory computer-readable medium that stores a privilege information issuing program that causes a computer to execute ([0105] teaches the storage subsystem provides a computer readable storage medium for storing basic programming and data that provides the functionality of the aspects disclosed herein; see also: [0114, 0118]). Accordingly, claims 8, 10, and 11 are rejected as being unpatentable over Epstein in view of Sun.
Regarding claims 2 and 9, the combination of Epstein and Sun teaches all the limitations of claims 1 and 8 above.
Epstein further teaches wherein the at least one processor is further configured to execute the instructions to: select a commercial facility as a target of issuing of the privilege information from among a plurality of commercial facilities in the neighborhood of the event venue on the basis of the extra time ([0041] teaches itinerary generation can be based on schedules associated with a venue and/or activities in a venue, wherein the schedules of reservations from other participants associated with several activities can be accessed so that an optimized schedule can be generated for the participant, wherein an optimized schedule can prioritize location, by performing nearby activities in succession, prioritize duration, by selecting activities to minimize downtime between activities, or other aspects, wherein an activity’s schedule can be assessed to determine potential downtime and try to schedule participants in that downtime to minimize the amount of downtime, wherein [0042] teaches the itinerary generation can be based on activity models that are designed to estimate aspects of activities in the venue including how long a participant will engage in a particular activity before another participant can engage, wherein the activity model can be used to predict how long the length of the queue of participants that have not established itinerary and are waiting in the queue without a schedule timeslot, wherein the venue models can be used as well, wherein the venue model can be used to predict how long it may take a participant to travel from one activity to another and when the busiest times of day of the year occur, wherein [0048] teaches the automated reservation system can suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity, as well as to remove available reservation times that would conflict with the participant’s current itinerary, such that the time it would take to travel between activities is longer than the expected time gap between activities; see also: [0047, 0055]), and
issue the privilege information that is in the selected commercial facility ([0041] teaches itinerary generation can be based on schedules associated with a venue and/or activities in a venue, wherein the schedules of reservations from other participants associated with several activities can be accessed so that an optimized schedule can be generated for the participant, wherein an optimized schedule can prioritize location, by performing nearby activities in succession, prioritize duration, by selecting activities to minimize downtime between activities, or other aspects, wherein an activity’s schedule can be assessed to determine potential downtime and try to schedule participants in that downtime to minimize the amount of downtime, wherein [0042] teaches the itinerary generation can be based on activity models that are designed to estimate aspects of activities in the venue including how long a participant will engage in a particular activity before another participant can engage, wherein the activity model can be used to predict how long the length of the queue of participants that have not established itinerary and are waiting in the queue without a schedule timeslot, wherein the venue models can be used as well, wherein the venue model can be used to predict how long it may take a participant to travel from one activity to another and when the busiest times of day of the year occur, wherein [0048] teaches the automated reservation system can suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity, as well as to remove available reservation times that would conflict with the participant’s current itinerary, such that the time it would take to travel between activities is longer than the expected time gap between activities, wherein [0082-0083] teach the proposed itinerary is generated for the participant using venue information, wherein the itinerary is transmitted to the participant, wherein [0084-0085] teach the itinerary can be finalized in cases where payment is not necessary for the venue, the itinerary can be finalized by receiving a confirmation from the participant; see also: [0047, 0055]).
Regarding claim 3, the combination of Epstein and Sun teaches all the limitations of claim 2 above.
Epstein further teaches wherein the at least one processor is further configured to execute the instructions to: select the commercial facility as the target of issuing of the privilege information from among the plurality of commercial facilities on the basis of a relationship of a first required travel time from a travel start point to the commercial facility ([0042] teaches the itinerary generation can be based on activity models that are designed to estimate aspects of activities in the venue including how long a participant will engage in a particular activity before another participant can engage, wherein the activity model can be used to predict how long the length of the queue of participants that have not established itinerary and are waiting in the queue without a schedule timeslot, wherein the venue models can be used as well, wherein the venue model can be used to predict how long it may take a participant to travel from one activity to another and when the busiest times of day of the year occur, wherein [0048] teaches the automated reservation system can suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity, as well as to remove available reservation times that would conflict with the participant’s current itinerary, such that the time it would take to travel between activities is longer than the expected time gap between activities; see also: [0047, 0055]),
an expected staying time at the commercial facility ([0042] teaches the itinerary generation can be based on activity models that are designed to estimate aspects of activities in the venue including how long a participant will engage in a particular activity before another participant can engage, wherein the activity model can be used to predict how long the length of the queue of participants that have not established itinerary and are waiting in the queue without a schedule timeslot, wherein the venue models can be used as well, wherein the venue model can be used to predict how long it may take a participant to travel from one activity to another and when the busiest times of day of the year occur, wherein [0048] teaches the automated reservation system can suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity, as well as to remove available reservation times that would conflict with the participant’s current itinerary, such that the time it would take to travel between activities is longer than the expected time gap between activities; see also: [0047, 0055]),
and a second required travel time from the commercial facility to the event venue with the extra time of the person with the schedule of entry ([0042] teaches the itinerary generation can be based on activity models that are designed to estimate aspects of activities in the venue including how long a participant will engage in a particular activity before another participant can engage, wherein the activity model can be used to predict how long the length of the queue of participants that have not established itinerary and are waiting in the queue without a schedule timeslot, wherein the venue models can be used as well, wherein the venue model can be used to predict how long it may take a participant to travel from one activity to another and when the busiest times of day of the year occur, wherein [0048] teaches the automated reservation system can suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity, as well as to remove available reservation times that would conflict with the participant’s current itinerary, such that the time it would take to travel between activities is longer than the expected time gap between activities; see also: [0047, 0055]).
Regarding claim 4, the combination of Epstein and Sun teaches all the limitations of claim 2 above.
Epstein further teaches wherein the at least one processor is further configured to execute the instructions to: acquire congestion states of the plurality of commercial facilities in a time zone of the extra time ([0080-0081] teach accessing activity schedule for the selected venue or venues in order to determine whether an activity is open and available, wherein an activity model for the venue can be accessed that is used to generate predictions for individual activities and the venue as a whole, wherein [0082] teaches a proposed itinerary can be generated for the participant based on the activity schedule information, participant information, activity downtime and participant routing within a venue, wherein [0041] teaches itinerary generation is based on schedules associated with the venue and activities within a venue, wherein the schedules of current reservations from other participants associated with several activities can be accessed so that an optimized schedule can be generated that prioritizes location and duration such that downtime is minimized, wherein [0042] teaches itinerary generation is also based on activity models that estimate various aspects of activities at a given venue including how long a participant will engage in a particular activity, predicting the length of the queue, and how long it may take for participants to travel from one activity to another, wherein [0047] teaches the itinerary can include entries for activities across multiple venues that are nearby, wherein [0048] teaches the reservation system can handle automated activity reservation, wherein the automated reservation can include automatically suggested reservation times for a participant to engage in a particular activity, wherein the system can integrate with the itinerary management system to access the participant’s itinerary and suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity; see also: [0050, 0083-0084]), and
select the commercial facility as the target of issuing of the privilege information from among the plurality of commercial facilities on the basis of the congestion states as well ([0080-0081] teach accessing activity schedule for the selected venue or venues in order to determine whether an activity is open and available, wherein an activity model for the venue can be accessed that is used to generate predictions for individual activities and the venue as a whole, wherein [0082] teaches a proposed itinerary can be generated for the participant based on the activity schedule information, participant information, activity downtime and participant routing within a venue, wherein [0041] teaches itinerary generation is based on schedules associated with the venue and activities within a venue, wherein the schedules of current reservations from other participants associated with several activities can be accessed so that an optimized schedule can be generated that prioritizes location and duration such that downtime is minimized, wherein [0042] teaches itinerary generation is also based on activity models that estimate various aspects of activities at a given venue including how long a participant will engage in a particular activity, predicting the length of the queue, and how long it may take for participants to travel from one activity to another, wherein [0047] teaches the itinerary can include entries for activities across multiple venues that are nearby, wherein [0048] teaches the reservation system can handle automated activity reservation, wherein the automated reservation can include automatically suggested reservation times for a participant to engage in a particular activity, wherein the system can integrate with the itinerary management system to access the participant’s itinerary and suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity; see also: [0050, 0083-0084]).
Regarding claim 5, the combination of Epstein and Sun teaches all the limitations of claim 1 above.
Epstein further teaches wherein the at least one processor is further configured to execute the instructions to: acquire a current position of the person with the schedule of entry who has arrived in the predetermined region ([0037] teaches itinerary generation can be based on participant data that is collected and stored by a venue, wherein the participant information includes the current location of the participant, wherein [0093] teaches the participant’s itinerary can be accessed in order to determine if any modifications may be desirable, wherein the modification is based on location information related to the participant’s current location, wherein Fig. 10 and [0110-0111] teach generating a map that includes free time slots and can display suggested activities located nearby existing itinerary items that also have open time slots, wherein [0048] teaches the reservation system can handle automated activity reservation, wherein the automated reservation can include automatically suggested reservation times for a participant to engage in a particular activity, wherein the system can integrate with the itinerary management system to access the participant’s itinerary and suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity; see also: [0112]), and
select the commercial facility as the target of issuing of the privilege information from among the plurality of commercial facilities in the neighborhood of the event venue on the basis of the current position as well ([0037] teaches itinerary generation can be based on participant data that is collected and stored by a venue, wherein the participant information includes the current location of the participant, wherein [0093] teaches the participant’s itinerary can be accessed in order to determine if any modifications may be desirable, wherein the modification is based on location information related to the participant’s current location, wherein Fig. 10 and [0110-0111] teach generating a map that includes free time slots and can display suggested activities located nearby existing itinerary items that also have open time slots, wherein [0048] teaches the reservation system can handle automated activity reservation, wherein the automated reservation can include automatically suggested reservation times for a participant to engage in a particular activity, wherein the system can integrate with the itinerary management system to access the participant’s itinerary and suggest reservation times according to the participant’s itinerary, such as to suggest reservation times adjacent times when the participant is engaging in a nearby activity; see also: [0112]).
Regarding claim 6, the combination of Epstein and Sun teaches all the limitations of claim 1 above.
Epstein further teaches wherein the at least one processor is further configured to execute the instructions to: acquire attribute information associated with the person with the schedule of entry who has succeeded in the identity authentication ([0034] teaches an itinerary management system that can handle automated itinerary generation, wherein the itineraries can be automatically generated based on participant preferences and additional participant data, wherein a participant identification system, such as an automated participant identification system, can be used to identify a participant at a venue and at an activity to make sure that the participant is authorized to make use of or engage in that venue and activity, wherein [0049] teaches the participant identification system can handle automated participant identification that can obtain participant identification information, such as a participant passkey, in order to determine an identifier associated with the participant, wherein the system can automatically identify the participant within a particular zone; see also: [0025, 0068]), and
select the commercial facility as the target of issuing of the privilege information from among the plurality of commercial facilities in the neighborhood of the event venue on the basis of the attribute information as well ([0093] teaches the participant’s itinerary can be accessed in order to determine if any modifications may be desirable, wherein the modification is based on location information related to the participant’s current location, wherein [0034] teaches an itinerary management system that can handle automated itinerary generation, wherein the itineraries can be automatically generated based on participant preferences and additional participant data, wherein a participant identification system, such as an automated participant identification system, can be used to identify a participant at a venue and at an activity to make sure that the participant is authorized to make use of or engage in that venue and activity, wherein [0049] teaches the participant identification system can handle automated participant identification that can obtain participant identification information, such as a participant passkey, in order to determine an identifier associated with the participant, wherein the system can automatically identify the participant within a particular zone; see also: [0025, 0068]).
Regarding claim 7, the combination of Epstein and Sun teaches all the limitations of claim 1 above.
Epstein further teaches wherein the at least one processor is further configured to execute the instructions to: acquire the entry qualification information associated with the person with the schedule of entry who has succeeded in the identity authentication ([0093] teaches the participant’s itinerary can be accessed in order to determine if any modifications may be desirable, wherein the modification is based on location information related to the participant’s current location, wherein [0034] teaches an itinerary management system that can handle automated itinerary generation, wherein the itineraries can be automatically generated based on participant preferences and additional participant data, wherein a participant identification system, such as an automated participant identification system, can be used to identify a participant at a venue and at an activity to make sure that the participant is authorized to make use of or engage in that venue and activity, wherein [0049] teaches the participant identification system can handle automated participant identification that can obtain participant identification information, such as a participant passkey, in order to determine an identifier associated with the participant, wherein the system can automatically identify the participant without them actively providing identification by identifying their presence or detecting their participant smartphone device; see also: [0025, 0068]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kinney et al. (US 10929798 B1) discloses utilizing cameras to perform facial recognition in order to unlock a door
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 Sara G Brown whose telephone number is (469)295-9145. The examiner can normally be reached M-F 8:00 am- 5:00 pm.
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, Brian Epstein can be reached at (571) 270-5389. 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.
/SARA GRACE BROWN/Primary Examiner, Art Unit 3625
Prosecution Insights