DETAILED ACTION
This Final Office Action is in response to amendment filed on 02/17/2026. Claims 1-20 remain pending in the application.
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 .
Drawings
The drawings filed on 08/04/2022 are accepted.
Response to Arguments
Applicant's arguments filed 02/17/2026 have been fully considered but they are not persuasive.
Applicant started in Page 8 “The rejection rests on a fundamental mischaracterization of what Maxwell actually discloses. When carefully read, Maxwell teaches a biometric-based, user-driven, per-transaction validation framework, in which each individual user controls the sharing of his or her own private data, and in which transaction-specific secure packages are created during an individual transaction. This is architecturally and functionally different from Applicants' claimed invention, in which a
third-party application developer pre-configures age gating logic for its application via a separate API request before any user validation takes place, with that logic stored in association with the application's identifier and applied uniformly to all users of the application in every subsequent validation request.”
Examiner understands the distinctions between Maxwell and the claimed invention in the instant application as argued above, however, Maxwell reads on the claimed invention limitations, as drafted and given the broadest reasonable interpretations (BRIs). For example, there is no were in the claim that distinguish per-transaction validation from a “third-party application developer pre-configures age gating logic for its application”. Examiner recommends clarifying this distinction.
Applicant further stated in page 9 “…the age gating logic established during pre-configuration applies to all users of the application. It is an application-level policy, not a user-specific or transaction-specific artifact. The third-party developer establishes it once, through a distinct AP! request, in advance of any end user interaction.”
Examiner recommends further clarification to the claimed invention to distinguish the claimed invention from Maxwell. For example, the independent claims do not clarify “the age gating logic established during pre-configuration applies to all users of the application. It is an application-level policy… The third-party developer establishes it once, through a distinct AP! request”.
Applicant further stated in Page 9 “In Maxwell's framework, the user-not the service provider-is the initiating party for each validation event. The user sets up access restrictions and data partition configurations for each piece of private data (see Maxwell [0147]-[0150]), and the user generates the "cloaked identifier" that authorizes a specific service provider to seek a validation response for a specific transaction (see Maxwell [0098]-[0099]). Each cloaked identifier is transaction-specific and expires or becomes invalidated according to the access restrictions the user has specified for that transaction.”
Examiner submits that an online service is utilized in the teaching of Maxwell to respond to a validation request from an application 805 in Figure 8. Irrespective of whether the process disclosed by Maxwell is a transaction-specific or not, Maxwell’s teaching reds on the claimed invention outlined in details below. Examiner recommends clarifying the distinction as indicated in the response above.
Applicant further stated in Pages 9-10 “First, and most fundamentally, Maxwell's STP is generated during (not before) the transaction. The STP is created by the trusted entity in response to a specific user request to validate specific private data as part of an ongoing transaction (see Maxwell i-f [0097]: "to enforce the access restrictions applied to a particular transaction, a trusted entity ... may also generate a secure
transaction package"; see also i-f [0130], i-f [0132]). The STP is not established in advance by the service provider through an API request made prior to any user interaction. It is created real-time, as part of the live transaction flow, by the trusted entity. This is structurally the opposite of the separate, prior-in-time API request by the third-party developer that pre-establishes age gating logic before any end-user validation request is made, as required by claim 1.”
Examiner submits that Maxell discloses an STP generated at one time based on a request, interpreted as the request to generate the STP [0015] “The STP is generated based on a request from a record owner to validate certain private data so that relevant private data may then be coded and stored in the STP before it is saved on the secure transaction platform 170”, where the request is saved for future requests as disclosed in [0097] “The STP may be saved for future verification…” Therefore, even if the STP is generated based on a request to validate in a first transaction such that the STP is saved for future requests and future transactions, the claimed limitation would still read on the above transaction based process and the STP generation.
Applicant further stated in Page 10 “Second, the STP is per-transaction, not per-application. The STP specifically captures the identities of the particular transaction parties (the grocery store and the specific shopper), the date and time of creation, and the access restrictions the user has specified for that transaction. Each new
transaction between the same grocery store and same user would generate a new, distinct STP By contrast, claim 1 is age gating logic is application-level configuration: it is established once for a given third-party application and applies uniformly to all end-users of that application across all future validation requests. The STP is not a reusable, application-level policy artifact------it is a transaction-specific, disposable secure package.”
Examiner recommends clarifying the claimed invention according to the above underlined remarks to make a clear distinction of the claimed invention with the teaching of Maxwell. The current claim limitations do not clarify the age gating logic as outlined in the above argument.
Applicant further stated in Page 10 “Third, the STP is not keyed to an application identifier in the sense required by claim 1. The STP is tied to a "cloaked identifier" generated for that transaction (see Maxwell [0092], [0 l 00]), not stored in a database "in association with the identifier for the third-party application for subsequent retrieval during validation requests." The database look-up in Maxwell is driven by the transaction-specific cloaked identifier, not by a persistent application identifier that can be used to retrieve the same policy configuration across all future validations for that application.”
Examiner submits that Maxwell discloses in e.g. [0097] “The STP may be saved for future verification of access restrictions.” Indicating retrieving the restrictions initially outlined in the STP. The clocked ID pertains to the application as disclosed in [0124, 0145], where the clocked ID is associated with authentication and restrictions utilized by the application and accordingly validation is achieved.
Applicant further stated in Page 10 “Fourth, the STP is generated by the trusted entity (e.g., the DMV), not through a separate API request made by the third-party application (the service provider) itself Claim 1 requires that the age gating logic was previously established through a "separate API request" that included the identifier for the third-party application------meaning the third-party developer invoked an API call,
referencing its own application, to set up the logic. In Maxwell, the service provider (grocery store) does not send any request that establishes age verification rules for its own application. Rather, it receives a cloaked identifier pack from the user and then contacts the trusted entity to get a validation response for that specific transaction.”
Examiner submits that Maxwell discloses in [115] a first request for generating the TSP is sent by the application 805, which is construed as a request to generate/create the TSP, where the TSP is saved for subsequent/future requests as disclosed in [0097]. Rosencrantz is relied upon to disclose the concept of API requests. Examiner recommends further clarification such that the claimed invention teaches away from Maxwell n view of Rosencrantz.
Applicant further stated in Pages 10-11 “Fifth, the "first request" in Maxwell's abstract is user-centric, not application-centric. The Examiner's interpretation of Maxwell appears to conflate the initial user setup process (in which the user specifies how his or her data should be managed, stored at the trusted entity) with a developer side
configuration step. Maxwell's abstract states that "a first request is received to set up authentication information with respect to a user, wherein the first request specifies a type of information to be used for future authentication of the user." (Emphasis added.) This first request is made on behalf of or by the record owner (user) to configure how that specific user's data will be handled (see Maxwell i;i[ [0148]---[0150], if [0184]). It is not a request made by a third-party application developer to configure age gating logic that will apply to all users of that application.”
As discussed above, the first request can be the first request of a first transaction, where this generates the TSP as disclosed in [0115], where the TSP is saved for future requests and transactions as disclosed in [0097].
Applicant further states in Pages 11-13 “Notably, the Examiner's analysis at page 22 of the Office Action acknowledges that "Maxwell in view of Rosencrantz does not explicitly disclose the prior approval for activation." Although framed in the context of the dependent claim 8 ( directed to admin approval of age gating logic), this acknowledgment extends to the independent claims as well, because the pre-configuration concept is central to all of them. The Examiner's own admission confirms that neither Maxwell nor Rosencrantz discloses the application-specific, developer-initiated, pre-configuration architecture that is fundamental to the claimed invention…”
Examiner submits that the “application-specific, developer-initiated, pre-configuration architecture that is fundamental to the claimed invention” is not clearly disclosed in the claimed invention. Examiner recommends further clarification to the claimed invention with respect to the gating logic and the developer pre-configuration as discussed by the applicant above to teach away from the currently cited prior arts.
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 5, 6, 7, 9, 11, 13, 14, 15, 17, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Maxwell (US 20200201967 A1), hereinafter Maxwell in view of Rosencrantz (US 20230232217 A1), hereinafter Rosencrantz.
Regarding claim 1, Maxwell teaches a computer-implemented method (Maxwell Figure 4A [0121-0125]) comprising:
at an online service, receiving an (Maxwell Figure 4A [0121-0125] illustrates receiving from service provider 1 120-a and/or transaction engine 150, i.e. third-party computer, a request comprising cloaked ID, interpreted as token authorizing the service provider 1 120-a access for e.g. 1 hour as disclosed in [0096], where the request identifies the user end-and and the service provider 1 120-a as disclosed in [0097-0100] in order for the validator, e.g. transaction engine 150 and/OR trusted entities 160, i.e. online service, respond back to the service provider 1 120-a, where the end user can conduct a transaction online, i.e. online user and online store, as disclosed in e.g. [0078] and [0090] “Assume that a shopper (a record owner) desires to buy beer (either in a Brick & Mortar store or online shopping) from a grocery store (a service provider operating either a Brick & Mortar grocery store or an online store). The grocery store (service provider 120) requests that the shopper (record owner 110) validate that he/she is above the regulated drinking age of 21. The shopper may then send, via his/her personal computing device with a relevant application deployed and running thereon, the request to a relevant trusted entity 160, e.g., a relevant DMV holding necessary information to independently prove the shopper's age, to provide a proof to the grocery store in order for his/her to proceed with the purchase. Alternatively, the shopper may subscribe to a service from the transaction engine 150 that is engaged to act on behalf of the shopper to select an appropriate trusted entity (whoever is capable of providing the proof based on some known distribution of the shopper's information) for the needed validation and request such selected trusted entity to validate that the shopper is above the drinking age.”, [0147] and Figures 8A-B further illustrates application 805, which also can be construed as a third-party application (alternative to service provider 120), subscribing to age validation which can provide the request directly to the trusted entity and receiving validation response, Further illustrated in Figure 13 C 1375-1380, identifiers included in the cloaked ID illustrated in Figure 2E and [0094] pertaining to the relevant parties and parameters),
wherein age gating logic for the third-party application was previously established through a separate the age gating logic stored in a database in association with the identifier for the third-party application for subsequent retrieval during validation requests (Maxwell [0097] “Continuing the previous grocery shopping example, to enforce the access restrictions applied to a particular transaction, a trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) (i.e. age gating logic) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170. The STP may be saved for future verification of access restrictions.”, [0100] “When the DMV receives the cloaked identifier from the grocery store, it may then retrieve the STP previously stored and check against the access restrictions before it proceeds to generate a validation response. Such a STP may be accessed multiple times and each time the access restrictions stored therein may be used to ensure that each access is to comply with the access restrictions. For example, the same shopper may go to different stores to purchase alcohol products (products may differ from store to store) and each store may require him/her to prove the drinking age. In this case, the shopper may directly forward the previously received cloaked identifier related to proving legal drinking age to different stores and all such stores may then contact the same DMV for validating the same personal data. However, each of such requests from a store is subject to the access restriction request…”, where the TSP was previously established though a separate request, as disclosed [0115] “The STP is generated based on a request from a record owner to validate certain private data so that relevant private data may then be coded and stored in the STP before it is saved on the secure transaction platform 170. As disclosed herein, the secure transaction platform is secure with the mechanism of uniquely identifying each smart contract (STP) wherein the data stored therein is immutable. The STP ID may then be sent to the service provider for secure access. In this option, the service provider may provide its secure credential to the trusted entity so that the trusted entity may incorporate the credential of the service provider in the STP so that at the time of access to the STP, authentication is performed on the service provider to minimize the risks.”, where the STP is used for future/subsequent retrieval during validation requests, where the STP is used for validating future/subsequent requests and generating validation response to the future/subsequent requests, as disclosed in [0130, 0132, 0140]);
at the online service, processing the received
i) confirming that the third-party application is authorized to access an age gating service via the (Maxwell [0124] “…When the service provider 120-a sends a request for a validation response to a party (the transaction engine 150 or a trusted party), the request may also incorporate additional information related to the inquiry so that such additional information may be used to check against the access restrictions related to the piece of data to be validated. For example, if an access restriction demands that the validation request has to be made within 0.5 hour after the record owner 110-a requested for the cloaked identifier and the number of inquiries starting from the time of the initial request from the record owner 110-a cannot exceed 5. In this case, the service provider may be required to time stamp its request to a designated party (a trusted entity or the transaction engine) for a validation response so that the time represented by the time stamp may be used to compare against the set access restrictions. If the time stamp indicates that it has exceeded the permitted time period for access, the request for a validation response may be denied.”, where the service provider, i.e. third party, is authorized to make a validation request waiting a specific amount of time, and restrict access to data to one hour, further the service provider 120 is confirmed to be authorized by means of its subscription to a service and accordingly submits age validation requests, as disclosed in [0090] “…the shopper may subscribe to a service from the transaction engine 150 that is engaged to act on behalf of the shopper to select an appropriate trusted entity”, and authenticated as disclosed in [0115]),
ii) obtaining the previously established age gating logic for the third-party application by retrieving the age gating logic stored in association with the identifier for the third-party application (Maxwell [0140] “…the trusted entity accesses, at 775, the STP previously stored so that the access limitations associated with the private data may be evaluated based on the inquiry specified as well as the access information associated with the service provider.”, [0180] “If the request for a validation response meets the access limitations, the access limitation verification unit 1070 invokes the validation response/record generator 1075 to generate the requested validation response. To do so, the validation response/record generator 1075 determines, at 1162, the requested validation response type and then proceeds to generate, at 1164, the validation response based on the private data stored therein. For example, if the request seeks a Boolean response that validates whether the record owner is 21 years old, the validation response/record generator 1075 accesses the private age (or birth date) data stored in the secure database 1010 and compares that with the age (21) indicated in the inquiry. Based on the comparison result, the validation response/record generator 1075 generates the validation response accordingly and sends, at 1166, the validation response to the party who sent the request.”),
iii) obtaining information indicating a birthdate of the end-user (Maxwell [0074] “Via this framework 100, a record owner 110 can conduct a transaction with a service provider 120 across the network 140 so long as required secure or private information (e.g., driver license or date of birth) is validated by a trusted entity 160 (e.g., Division of Motor Vehicle) at a request of either the record owner 110 or the transaction engine 150 on behalf of the record owner 110.”, [0109] “…there are exemplary types of information that can be validated. For example, criminal records, credit scores, age, bank account, . . . , birth related information such as birth date, birth place” further in [0113 and 0180]), and
iv) performing a validation operation to validate the birthdate of the end-user using the age gating logic for the third-party application (Maxwell [0180] “If the request for a validation response meets the access limitations, the access limitation verification unit 1070 invokes the validation response/record generator 1075 to generate the requested validation response. To do so, the validation response/record generator 1075 determines, at 1162, the requested validation response type and then proceeds to generate, at 1164, the validation response based on the private data stored therein. For example, if the request seeks a Boolean response that validates whether the record owner is 21 years old, the validation response/record generator 1075 accesses the private age (or birth date) data stored in the secure database 1010 and compares that with the age (21) indicated in the inquiry. Based on the comparison result, the validation response/record generator 1075 generates the validation response accordingly and sends, at 1166, the validation response to the party who sent the request.”); and
communicating to the third-party application executing on the client computing device a Boolean value indicating whether the end-user is above or below an age threshold specified in the age gating logic (Maxwell [0180] “If the request for a validation response meets the access limitations, the access limitation verification unit 1070 invokes the validation response/record generator 1075 to generate the requested validation response. To do so, the validation response/record generator 1075 determines, at 1162, the requested validation response type and then proceeds to generate, at 1164, the validation response based on the private data stored therein. For example, if the request seeks a Boolean response that validates whether the record owner is 21 years old, the validation response/record generator 1075 accesses the private age (or birth date) data stored in the secure database 1010 and compares that with the age (21) indicated in the inquiry. Based on the comparison result, the validation response/record generator 1075 generates the validation response accordingly and sends, at 1166, the validation response to the party who sent the request.”, [0097] “generate a secure transaction package (STP) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170. The STP may be saved for future verification of access restrictions.”, and further in [0211]).
Maxwell does not disclose the requests are API requests.
Rosencrantz discloses API requests for age check (Rosencrantz [0044] “As shown by reference number 226, the backend system 206 may transmit a validation request (e.g., an API request that includes the authentication/session data (or token)) to the user validation system/database 208. In various embodiments, the validation request may include information regarding the type of validation requested (e.g., age check, vaccination status check, etc.).”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Maxwell to incorporate the teaching of Rosencrantz to utilize the above feature where using API in requests is one of finite options to select from to interface between two different systems, as recognized in (Rosencrantz [0081]).
Regarding claim 9, claim 9 recites similar limitations to claim 1, therefore rejected with the same rationale and motivation applied to claim 1.
Regarding claim 17, claim 17 recites similar limitations to claim 1, therefore rejected with the same rationale and motivation applied to claim 1.
Regarding claim 3, Maxwell in view of Rosencrantz teaches the computer-implemented method of claim 1, wherein the age gating logic specifies a global age threshold for the third-party application executing on the client computing device (Maxwell [0180] “If the request for a validation response meets the access limitations, the access limitation verification unit 1070 invokes the validation response/record generator 1075 to generate the requested validation response. To do so, the validation response/record generator 1075 determines, at 1162, the requested validation response type and then proceeds to generate, at 1164, the validation response based on the private data stored therein. For example, if the request seeks a Boolean response that validates whether the record owner is 21 years old, the validation response/record generator 1075 accesses the private age (or birth date) data stored in the secure database 1010 and compares that with the age (21) indicated in the inquiry. Based on the comparison result, the validation response/record generator 1075 generates the validation response accordingly and sends, at 1166, the validation response to the party who sent the request.”, consistent with [0014] of the instant application “…the age gating logic may be as simple as a global age threshold. In this context, a global age threshold is an age threshold that applies to all end-users, regardless of their geographical location or region, such as their state or country of residence, and so forth.”).
Regarding claim 11, claim 11 recites similar limitations to claim 3, therefore rejected with the same rationale and motivation applied to claim 3.
Regarding claim 19, claim 19 recites similar limitations to claim 3, therefore rejected with the same rationale and motivation applied to claim 3.
Regarding claim 5, Maxwell in view of Rosencrantz teaches the computer-implemented method of claim 1, wherein confirming that the third-party application is authorized to access an age gating service via the (Maxwell [0175] “…the transaction engine 150 may interface with the trusted entity for the service providers (e.g., because the record owners who desire transactions with the service providers use services from the transaction engine)…the trusted entity may even store some authorization information from the record owners to permit the transaction engine to act on behalf of the record owners. In this case, each time, when the trusted entity receives a request from the transaction engine, it may first make sure that the request received from the transaction engine is authorized by the record owner associated with the request.”, [0176] “When the trusted entity receives, at 1134, a validation request from the transaction engine 150, it may first check, at 1136, whether the transaction engine is authorized to represent the record owner associated with the request.”, Rosencrantz discloses API request rationale and motivation in independent claim apply).
Regarding claim 13, claim 13 recites similar limitations to claim 5, therefore rejected with the same rationale and motivation applied to claim 5.
Regarding claim 6, Maxwell in view of Rosencrantz teaches the computer-implemented method of claim 1, wherein obtaining age gating logic for the third-party application comprises: obtaining age gating logic for the third-party application that is stored in association with the identifier for the third-party application associated with the access token received with the (Maxwell [0180] “If the request for a validation response meets the access limitations, the access limitation verification unit 1070 invokes the validation response/record generator 1075 to generate the requested validation response. To do so, the validation response/record generator 1075 determines, at 1162, the requested validation response type and then proceeds to generate, at 1164, the validation response based on the private data stored therein. For example, if the request seeks a Boolean response that validates whether the record owner is 21 years old, the validation response/record generator 1075 accesses the private age (or birth date) data stored in the secure database 1010 and compares that with the age (21) indicated in the inquiry. Based on the comparison result, the validation response/record generator 1075 generates the validation response accordingly and sends, at 1166, the validation response to the party who sent the request.”, consistent with [0014] of the instant application “…the age gating logic may be as simple as a global age threshold. In this context, a global age threshold is an age threshold that applies to all end-users, regardless of their geographical location or region, such as their state or country of residence, and so forth.”, Rosencrantz discloses API request rationale and motivation in independent claim apply).
Regarding claim 14, claim 14 recites similar limitations to claim 6, therefore rejected with the same rationale and motivation applied to claim 6.
Regarding claim 7, Maxwell in view of Rosencrantz teaches the computer-implemented method of claim 1, wherein obtaining information indicating a birthdate of the end-user comprises: obtaining the birthdate of the end-user by issuing a request to an end-user data service, using the identifier of the end-user associated with the access token received with the (Maxwell [0074] “Via this framework 100, a record owner 110 can conduct a transaction with a service provider 120 across the network 140 so long as required secure or private information (e.g., driver license or date of birth) is validated by a trusted entity 160 (e.g., Division of Motor Vehicle) at a request of either the record owner 110 or the transaction engine 150 on behalf of the record owner 110.”, [0109] “…there are exemplary types of information that can be validated. For example, criminal records, credit scores, age, bank account, . . . , birth related information such as birth date, birth place” further in [0113 and 0180], Rosencrantz discloses API request rationale and motivation in independent claim apply).
Regarding claim 15, claim 15 recites similar limitations to claim 7, therefore rejected with the same rationale and motivation applied to claim 7.
Claims 2, 10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Maxwell (US 20200201967 A1), hereinafter Maxwell in view of Rosencrantz (US 20230232217 A1), hereinafter Rosencrantz and Vaneeswaran et. al. (US 20220141213 A1), hereinafter Vaneeswaran.
Regarding claim 2, Maxwell in view of Rosencrantz teaches the computer-implemented method of claim 1, wherein the access token associated with [[an]] the identifier for the third-party application and [[an]] the identifier for [[an]] the end-user of the online service is an (Maxwell [0092] “Because a cloaked identifier can include access restrictions, it serves as a limited use token so that when the access violates the access restrictions specified in the cloaked identifier, the cloaked identifier itself serves as an authorization tool and may be effectively purged when the specified access conditions are not met.” [0093-0094] and Figure 2E illustrates clocked identifier, i.e. access token, associated with service provider, third party, ID, and record owner, user, ID, and associated with previous requests stored).
Maxwell in view of Rosencrantz does not disclose OAuth 2.0 access token
Vaneeswaran discloses OAuth 2.0 access token (Vaneeswaran [0027-0028] discloses OAuth 2.0 token used for age validity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Maxwell in view of Rosencrantz to incorporate the teaching of Vaneeswaran to utilize the above feature, with the motivation of using one of authentication methos for users, as recognized by (Vaneeswaran [027-0028] ).
Regarding claim 10, claim 10 recites similar limitations to claim 2, therefore rejected with the same rationale and motivation applied to claim 2.
Regarding claim 18, claim 18 recites similar limitations to claim 2, therefore rejected with the same rationale and motivation applied to claim 2.
Claims 4, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Maxwell (US 20200201967 A1), hereinafter Maxwell in view of Rosencrantz (US 20230232217 A1), hereinafter Rosencrantz and Smith et. al. (US 20210065267 A1), hereinafter Smith.
Regarding claim 4, Maxwell in view of Rosencrantz teaches the computer-implemented method of claim 1.
Maxwell does not explicitly disclose the below limitations.
Smith discloses wherein the age gating logic specifies a plurality of age thresholds for the third-party application executing on the client computing device, each age threshold of the plurality of age thresholds associated with and relevant with respect to a particular geographical location, wherein performing the validation operation to validate the birthdate of the end-user comprises applying an age threshold specified for a geographical location matching a geographical location associated with the end-user (Smith [0183] “For example, where there is an age restriction to providing a good or service, and the user provides their date of birth, the user has not provided their age however their age can be derived from their date of birth if the date of birth is verified. In other examples, the eligibility requirement for the user to access the restricted good or service depends on their age and also on the location of the terminal 1145 of service provider 1140. The service provider 1140 may derive the age requirement based on the geographic location of the terminal (e.g. the drinking age requirement of the country, province, or state that the terminal is in), in addition to the user's date of birth.”, indicating applying an age requirement in a specific location (state, country, etc.) to match the age requirement at that specific location (state, country, etc.)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Maxwell to incorporate the teaching of Smith to utilize the above feature, with the motivation of enforcing age reequipments based on different regulations in different locations, as recognized by (Smith Abstract and [0183] ).
Regarding claim 12, claim 12 recites similar limitations to claim 4, therefore rejected with the same rationale and motivation applied to claim 4.
Regarding claim 20, claim 20 recites similar limitations to claim 4, therefore rejected with the same rationale and motivation applied to claim 4.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Maxwell (US 20200201967 A1), hereinafter Maxwell in view of Rosencrantz (US 20230232217 A1), hereinafter Rosencrantz and Webber et. al. (US 20110185400 A1), hereinafter Webber.
Regarding claim 8. Maxwell in view of Rosencrantz teaches the computer-implemented method of claim 1.
prior to receiving (Maxwell [0097] “Continuing the previous grocery shopping example, to enforce the access restrictions applied to a particular transaction, a trusted entity (e.g., DMV here) may also generate a secure transaction package (STP) (i.e. age gating logic) that incorporates the transaction information (the identities of the grocery store and shopper, date, time of creation of the STP, etc.), the data to be validated, the nature of the response required (e.g., yes or no to the age instead of sending the age or birth date over the network), and/or access restrictions related to the data and then save the STP at the secure transaction platform 170. The STP may be saved for future verification of access restrictions.”, [0100] “When the DMV receives the cloaked identifier from the grocery store, it may then retrieve the STP previously stored and check against the access restrictions before it proceeds to generate a validation response. Such a STP may be accessed multiple times and each time the access restrictions stored therein may be used to ensure that each access is to comply with the access restrictions. For example, the same shopper may go to different stores to purchase alcohol products (products may differ from store to store) and each store may require him/her to prove the drinking age. In this case, the shopper may directly forward the previously received cloaked identifier related to proving legal drinking age to different stores and all such stores may then contact the same DMV for validating the same personal data. However, each of such requests from a store is subject to the access restriction request…”, where the TSP was previously established though a separate request, as disclosed [0115] “The STP is generated based on a request from a record owner to validate certain private data so that relevant private data may then be coded and stored in the STP before it is saved on the secure transaction platform 170. As disclosed herein, the secure transaction platform is secure with the mechanism of uniquely identifying each smart contract (STP) wherein the data stored therein is immutable. The STP ID may then be sent to the service provider for secure access. In this option, the service provider may provide its secure credential to the trusted entity so that the trusted entity may incorporate the credential of the service provider in the STP so that at the time of access to the STP, authentication is performed on the service provider to minimize the risks.”, where the STP is used for future/subsequent retrieval during validation requests, where the STP is used for validating future/subsequent requests and generating validation response to the future/subsequent requests, as disclosed in [0130, 0132, 0140]);
Maxwell discloses: a separate request for establishing/configuring STP and the aforementioned limitations as discussed above. Rosencrantz discloses utilizing API requests. While Maxwell in view of Rosencrantz disclose the age check, which can be conceived of prior configuration of ana account by the user to activate/subscribe to a service. However, Maxwell in view of Rosencrantz does not explicitly disclose the prior approval for activation.
Webber discloses further comprising: prior to receiving API request for end-user age validation from the third-party application: receiving an API request for configuring age gating logic for the third-party application, the API request specifying the age gating logic for the third-party application and including the identifier for the third-party application; receiving an indication of approval of the age gating logic for the third party application via an admin portal of the online service; storing the age gating logic in a database for subsequent recall; and publishing the third-party application (Webber [0033] “Next, at step 302, a service requester sends a request with user information to the age check system to verify whether a user is of sufficient age to view, sign-up, or make purchases at a service requester. The age check system, an account for which was previously created, is activated through the service requester Internet website. “, [0034] “Service requesters may partner with the age check system by creating an account with the age check system. The account is created with data supplied by the service requester to the age check system. The data required to create an account may include the name, address and contact information for the service requestor as well as information about the type of business that the service requester is engaged in. It may also include payment details and notification details. “, [0043] “…The age check system determines whether setup information that was supplied by a person is correct. The system provides an application programming interface (API) that exposes software functions that other websites, web services and Internet enabled desktop applications can use to enforce age checks when a person attempts to create an online account and/or gain access to an age-sensitive website.”, where the creation of an account and subsequent activation prior to age checking is interpreted as creation via the admin portal).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Maxwell in view of Rosencrantz to incorporate the teaching of Webber to utilize the above feature, with the motivation of establishing an age check account, as recognized by (Webber Abstract ).
Regarding claim 16, claim 16 recites similar limitations to claim 8, therefore rejected with the same rationale and motivation applied to claim 8.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BASSAM A NOAMAN whose telephone number is (571)272-2705. The examiner can normally be reached Monday-Friday 8:30 AM-5:00PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
Prosecution Insights