Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the pre-AIA first to invent provisions as the present application is claiming a priority to U. S. Provisional Application 61/211, 335, filed on March 30, 2009.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 04, 2026, has been entered.
Status of Claims
Applicant filed an amendment on February 04, 2026. Claims 1-25 were pending in the Application. Claims 1, 10-11, 18-20, 22, and 25 are amended. No new claims have been added. No new claims have been canceled with claims 2, 6, 9, 15, and 21 remaining canceled. Thus claims 1, 3-5, 7-8, 10-14, 16-20, and 22-25 are currently pending. After careful and full consideration of Applicant arguments and amendments, the Examiner finds them to be moot and/or not persuasive.
Claim Objections
Claim 10 is objected to because of the following informalities: “an application platform including a third non-transitory computer-readable medium storing second instructions …” should read “an application platform including a third non-transitory computer-readable medium storing third instructions …”.
Claim 11 is objected to because of the following informalities: “confirming, by the token service platform, that the partner user device …” should read “confirming that the partner user device …”.
Claim 11 is objected to because of the following informalities: “a third non-transitory computer-readable medium storing second instructions that …” should read “a third non-transitory computer-readable medium storing third instructions that …”.
Response to Arguments
In the context of 35 U.S.C. §101, Applicant, without addressing the propriety of the rejections in order to expedite prosecution, claims 1, 10, and 11 have been amended. Applicant is of the opinion that the claims are statutory and respectfully asserts that “without addressing the propriety of the rejection in order to expedite prosecution, claims 1, 10, and 11 have been amended as noted above. Claims 3-5, 7-8 and 23 depend from independent claim 1. Claims 12-14, 16-17 and 24 depend from independent claim 10. Claims 18-20, 22 and 25 depend from independent claim 11; and withdrawal of the rejection under 35 U.S.C. §101 is therefore respectfully requested.”
Initially, the Examiner would like to point out that the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106, which applies a two-step framework, earlier set out in Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012), "for distinguishing patents that claim laws of nature, natural phenomena, and abstract ideas from those that claim patent-eligible applications of those concepts." Alice, 573 U.S. at 217.
Under the two-step framework, it must first be determined if "the claims at issue are directed to a patent-ineligible concept." If the claims are determined to be directed to a patent-ineligible concept, e.g., an abstract idea, then the second step of the framework is applied to determine if "the elements of the claim ... contain an "inventive concept" sufficient to 'transform' the claimed abstract idea into a patent-eligible application." (citing Mayo, 566 U.S. at 72-73, 79).
With regard to step one of the Alice framework, we apply a "directed to" two-prong test: 1) evaluate whether the claim recites a judicial exception, and 2) if the claim recites a judicial exception, evaluate whether the claim "applies, relies on, or uses the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception," i.e., whether the claim integrates the judicial exception into a practical application. (MPEP §2106.04 II.A.1. and II.B.2.).
The Specification, (PG Pub US 20230206234 A1, para 2), provides evidence as to what the claimed invention is directed. In this case, the specification, (‘234 A1, para 2), discloses that the invention generally relates to technology sharing access to a resource, and is grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)” and grouped under “Certain Methods of Organizing Human Activity, fundamental economic principles or practices (including hedging, insurance, mitigating risk)”, in prong one of step 2A. (MPEP §2106.04 II.A.1.).
Claim 1 provides additional evidence, and recites the method limitations of “extracting, by a token service platform, features to define a feature vector from a request to share access to a resource, wherein access to the resource is shareable with a partner user device and limited by a constraint to prevent excessive or unauthorized use of the resource, and wherein the request is associated with a primary user device; transmitting, by the token service platform, the feature vector including a predicted value for the constraint in a resource-sharing configuration that includes a physical access type and a token identifier; generating, by the token service platform, a sharetoken that is linked to the resource, wherein the sharetoken is generated using the token identifier, and wherein the sharetoken represents a limited access credential that provides limited access to the resource; transmitting, by the token service platform, a tokenized provisioning link directly or indirectly to the partner user device; receiving, by the token service platform and via the partner user device, a generated request for the sharetoken, wherein the generated request is in response to the partner user device executing the tokenized provisioning link; confirming, by the token service platform, that the partner user device is authenticated based on the generated request; receiving, by an account management platform, a transaction authorization request associated with an authorized user device, wherein the transaction authorization request includes the sharetoken and an identification of the physical access type; determining, by the account management platform, the constraint is satisfied; suspending, by the account management platform, the sharetoken to prevent unauthorized use of the resource; detecting, by an application platform, the suspended sharetoken; and pushing, by the application platform, an update to the partner user device, wherein the update reflects the suspended sharetoken”, which represent the abstract idea of “sharing access to a resource”. The abstract idea is in italics, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “a token service platform”, “a partner user device”, “the request is associated with a primary user device”, “transmitting, by the token service platform, a tokenized provisioning link directly or indirectly to the partner user device”, “the partner user device executing the tokenized provisioning link”, “associated with an authorized user device”, “an account management platform”, and “an application platform”, amounts to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource”.
Examiner notes the basis of the rejection was, and is not as any mental process covering performance in the mind, but classified as an abstract idea, “sharing access to a resource”, grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”, and grouped under “Certain Methods of Organizing Human Activity, fundamental economic principles or practices (including hedging, insurance, mitigating risk)”.
With respect to the additional elements operating in a non-conventional and non-generic way and reflecting an improvement to a particular technological environment, the cited additional elements represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource.” The claim is not directed to improving computer functionality nor improving another technology or technical field, but improving the method for “sharing access to a resource”. For potential improvement in an abstract idea “sharing access to a resource”, it is important to keep in mind that an improvement in the abstract idea itself (e.g. a sharing access to a resource concept) is not an improvement in technology. (MPEP § 2106.04(d)(1)). Therefore, claim 1 is non-statutory.
Claim 10 also recites the abstract idea of “sharing access to a resource”, as well as the additional elements of “A system comprising: a token service platform including a first non-transitory computer-readable medium storing first instructions that when executed, cause operations to be performed by the token service platform including: …”, “a partner user device”, “a shared-resource application on a primary user device”, “transmitting a tokenized provisioning link directly or indirectly to the partner user device”, “the partner user device executing the tokenized provisioning link”, “an account management platform including a second non-transitory computer-readable medium storing second instructions that when executed, cause operations to be performed by the account management platform including: …”, “an authorized user device”, and “an application platform including a third non-transitory computer-readable medium storing second instructions that when executed, cause operations to be performed by the application platform including: …”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “sharing access to a resource” using computer technology (e.g., “a shared-resource application on a primary user device” and “a first non-transitory computer-readable medium”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 10 is non-statutory.
Claim 11 also recites the abstract idea of “sharing access to a resource”, as well as the additional elements of “A plurality of non-transitory computer-readable mediums comprising: storing instructions that when executed, cause operations to be performed by one or more processors including: a first non-transitory computer-readable medium storing first instructions that when executed by a token service platform, cause operations to be performed by the token service platform including: …”, “a partner user device”, “a shared-resource application on a primary user device”, “transmitting a tokenized provisioning link directly or indirectly to the partner user device”, “the partner user device executing the tokenized provisioning link”, “a second non-transitory computer-readable medium storing second instructions that when executed by an account management platform, cause operations to be performed by the account management platform including: …”, and “a third non-transitory computer-readable medium storing second instructions that when executed by an application platform, cause operations to be performed by the application platform including: …”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “sharing access to a resource” using computer technology (e.g., “a second non-transitory computer-readable medium storing second instructions that when executed by an account management platform, cause operations to be performed by the account management platform including: …” and “the partner user device executing the tokenized provisioning link”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 11 is non-statutory.
Finally, Examiner notes the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106. And, based on this standard, the claims are non-statutory, and correctly rejected under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-5, 7-8, 10-14, 16-20, and 22-25 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1, 3-5, 7-8, and 23 are directed to “a method”; claims 10, 12-14, 16-17, and 24 are directed to “a system”; and claims 11, 18-20, 22, and 25 are directed to “non-transitory computer-readable mediums”. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 1 recites “sharing access to a resource”, which is a form of commercial or legal interactions and a form of fundamental economic principles or practices (i.e., organizing human activity), and therefore, an abstract idea. Specifically, the claim recites “extracting, by a token service platform, features to define a feature vector from a request to share access to a resource, wherein access to the resource is shareable with a partner user device and limited by a constraint to prevent excessive or unauthorized use of the resource, and wherein the request is associated with a primary user device; transmitting, by the token service platform, the feature vector including a predicted value for the constraint in a resource-sharing configuration that includes a physical access type and a token identifier; generating, by the token service platform, a sharetoken that is linked to the resource, wherein the sharetoken is generated using the token identifier, and wherein the sharetoken represents a limited access credential that provides limited access to the resource; transmitting, by the token service platform, a tokenized provisioning link directly or indirectly to the partner user device; receiving, by the token service platform and via the partner user device, a generated request for the sharetoken, wherein the generated request is in response to the partner user device executing the tokenized provisioning link; confirming, by the token service platform, that the partner user device is authenticated based on the generated request; receiving, by an account management platform, a transaction authorization request associated with an authorized user device, wherein the transaction authorization request includes the sharetoken and an identification of the physical access type; determining, by the account management platform, the constraint is satisfied; suspending, by the account management platform, the sharetoken to prevent unauthorized use of the resource; detecting, by an application platform, the suspended sharetoken; and pushing, by the application platform, an update to the partner user device, wherein the update reflects the suspended sharetoken”. The abstract idea is in italics, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “a token service platform”, “a partner user device”, “the request is associated with a primary user device”, “transmitting, by the token service platform, a tokenized provisioning link directly or indirectly to the partner user device”, “the partner user device executing the tokenized provisioning link”, “associated with an authorized user device”, “an account management platform”, and “an application platform”, amounts to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, these additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of “sharing access to a resource” using computer technology (e.g., “a token service platform” and “an account management platform”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 1 is non-statutory.
Claim 10 also recites the abstract idea of “sharing access to a resource”, as well as the additional elements of “A system comprising: a token service platform including a first non-transitory computer-readable medium storing first instructions that when executed, cause operations to be performed by the token service platform including: …”, “a partner user device”, “a shared-resource application on a primary user device”, “transmitting a tokenized provisioning link directly or indirectly to the partner user device”, “the partner user device executing the tokenized provisioning link”, “an account management platform including a second non-transitory computer-readable medium storing second instructions that when executed, cause operations to be performed by the account management platform including: …”, “an authorized user device”, and “an application platform including a third non-transitory computer-readable medium storing second instructions that when executed, cause operations to be performed by the application platform including: …”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “sharing access to a resource” using computer technology (e.g., “a shared-resource application on a primary user device” and “a first non-transitory computer-readable medium”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 10 is non-statutory.
Claim 11 also recites the abstract idea of “sharing access to a resource”, as well as the additional elements of “A plurality of non-transitory computer-readable mediums comprising: storing instructions that when executed, cause operations to be performed by one or more processors including: a first non-transitory computer-readable medium storing first instructions that when executed by a token service platform, cause operations to be performed by the token service platform including: …”, “a partner user device”, “a shared-resource application on a primary user device”, “transmitting a tokenized provisioning link directly or indirectly to the partner user device”, “the partner user device executing the tokenized provisioning link”, “a second non-transitory computer-readable medium storing second instructions that when executed by an account management platform, cause operations to be performed by the account management platform including: …”, and “a third non-transitory computer-readable medium storing second instructions that when executed by an application platform, cause operations to be performed by the application platform including: …”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “sharing access to a resource” using computer technology (e.g., “a second non-transitory computer-readable medium storing second instructions that when executed by an account management platform, cause operations to be performed by the account management platform including: …” and “the partner user device executing the tokenized provisioning link”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 11 is non-statutory.
Dependent claims 3-5, 7-8, 12-14, 16-20, 22, and 23-25 further describe the abstract idea of “sharing access to a resource”, which is insufficient to overcome the rejections of claims 1 and 10-11.
Dependent claims 3-5, 7-8, 12-14, 16-20, and 22 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of “sharing access to a resource”, when analyzed under Step 2A, Prong Two. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
Dependent claims 23-25 recite a new additional element of “terminal devices”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality or improve another technology or technical field.
Hence, claims 1, 3-5, 7-8, 10-14, 16-20, and 22-25 are not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. § 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. § 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-5, 7-8, 10-14, 16-20, and 22-25 are rejected under 35 U.S.C. § 112(a) or 35 U.S.C. § 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. § 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Written Description
The written description requirement is not met. Claim 1 recites, “transmitting, by the token service platform, the feature vector including a predicted value for the constraint in a resource-sharing configuration that includes a physical access type and a token identifier”. In order for the specification to be fully supportive of the limitation “transmitting … the feature vector including a predicted value for the constraint in a resource-sharing configuration that includes a physical access type and a token identifier” as being characterized by the Applicant, then the specification would have to disclose how the limitation “transmitting … the feature vector including a predicted value for the constraint in a resource-sharing configuration that includes a physical access type and a token identifier” is being performed.
The specification, (PG Pub US 20230206234 A1, para 38), recites “… The extracted features may be used to define a feature vector. The feature vector may be a representation of a set of features in a particular order (e.g., such as time a time interval over which the feature occurred, or the like). The feature vector may be used to train a machine-learning model to generate predictions of future resource-sharing requests. If the feature vector is too small ( e.g., insufficient data to train the machine-learning model), then additional resource-sharing requests may be generated (e.g., manually, procedurally, or the like). Features may be extracted from the generated resource-sharing requests and be added to the feature vector …”, which is directed to the feature vector being used to train a machine-learning model to generate predictions of future resource-sharing requests. However, specification, (‘234 A1, para 38), lacks sufficient details so that one skilled in the art would know how “transmitting … the feature vector including a predicted value for the constraint in a resource-sharing configuration that includes a physical access type and a token identifier” is to be performed.
Therefore, the written description requirement is not met. Additionally, similar language is recited in claims 10-11. Dependent claims 3-5, 7-8, and 23, which depend from claim 1; dependent claims 12-14, 16-17, and 24, which depend from claim 10; and dependent claims 18-20, 22, and 25, which depend from claim 11, are also similarly rejected. (MPEP § 2161.01 I and MPEP § 2163.03 V).
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:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-5, 7-8, 10-14, 16-20, and 22-25 are rejected under 35 U.S.C. 103 as being unpatentable over Mehla et al (U. S. Patent Application Publication No. US 20230066397 A1), herein referred to as Mehla, and in further view of Leaman et al (U. S. Patent Application Publication No. US 20220293107 A1), herein referred to as Leaman.
Regarding claims 1 and 10-11, Mehala discloses a computer-implemented method comprising: … by a token service platform (FIG. 1, item 103; para 14, “… The computing environment 103 can include a server computer or any other system providing computing capability … the computing environment 103 can employ a plurality of computing devices that can be arranged … in one or more server banks or computer banks or other arrangements. Such computing devices can be located in a single installation or can be distributed among many different geographical locations … the computing environment 103 can include a plurality of computing devices that together can comprise a hosted computing resource, a grid computing resource and/ or any other distributed computing arrangement … the computing environment 103 can correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time …”), …
…, wherein access to the resource is shareable with a partner user device (FIG. 1, items 103, 106b, 118; para 16, “… The components executed on the computing environment 103 … can include a wallet share application 118, and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. The wallet share application 118 is executed to remotely share a payment instrument of a first user to a client device of a second user. The wallet share application 118 can be used to remotely share a payment instrument of a first user to the second client device 106b of a second user. The wallet share application 118 can enable the first client device 106a to monitor and limit the usage of the payment instrument by the second user …”; FIG. 1, items 122, 133; para 18, “… The beneficiary users 133, who can also be referred to as authorized users, can represent an account for an individual that is receiving access to a temporary payment instrument from the account user 122. The temporary payment instrument is associated with the account user 122, in which the account user will pay for the charges made on the temporary payment instrument. Some non-limiting examples of individuals that can be considered a beneficiary user 133 can include children, elderly parents, friends, employees, agents, and other authorized users of the account user 122. Each beneficiary user 133 can include a beneficiary identifier 134 and beneficiary user data 135. The beneficiary identifier 134 can be a unique identifier for the account of the beneficiary user 133, and the beneficiary user data 135 can include identifying information (e.g., first name, last name), contact information (e.g., email, phone number) and other suitable data for the beneficiary user 133. …”; FIG. 1, items 122, 133, 137; para 19, “… The virtual payment instrument 137 can represent a virtual payment card or a digital token for the beneficiary user 133. The virtual payment instrument 137 can be considered as a temporary payment instrument. The virtual payment instrument 137 can be used by the beneficiary user 133 for purchases … the virtual payment instrument 137 can be presented at a point of sale (POS) terminal or used online in order to complete a transaction. The virtual payment instruments 137 can be created by the account user 122 and assigned to the beneficiary user 133. Purchases made using the virtual payment instrument 137 are charged to the account user 122 …”) and limited by a constraint to prevent excessive or unauthorized use of the resource (FIG. 1, items 122, 137, 138; para 20, “… The account user 122 can monitor spending events (e.g., purchases) generated by the beneficiary user 133 and can limit the spending capability of the virtual payment instrument 137. The account user 122 can apply one or more spending policies 138 to the virtual payment instrument 137. The spending policy 138 can include one or more spending constraints, restrictions, and/or limitations. Some non-limiting examples of a spending policy 138 can include an allocated spending limit, a frequency in which the allocated spending limit is provided (e.g., weekly, monthly, every two months), authorized spending categories (e.g., spending or transactions that are authorized for one or more categories of merchants or transactions, such as medical expenses, travel expenses, office supplies, academic expenses, etc.), prohibited spending categories ( e.g., spending or transactions that are prohibited for certain categories of merchants or transactions, such as prohibiting spending or transactions at bars, liquor stores, casinos, etc.), a start date for the virtual payment instrument 137, an end date for the virtual payment instrument 137, and other suitable spending policy items …”), and wherein the request is associated with a primary user device (FIG. 1, items 103, 106a, 118; para 16, “… The components executed on the computing environment 103 … can include a wallet share application 118, and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. The wallet share application 118 is executed to remotely share a payment instrument of a first user to a client device of a second user. The wallet share application 118 can be used to remotely share a payment instrument of a first user to the second client device 106b of a second user. The wallet share application 118 can enable the first client device 106a to monitor and limit the usage of the payment instrument by the second user …”);
…, by the token service platform (FIG. 1, item 103; para 14), … that includes a physical access type and a token identifier (FIG. 1, items 122, 133, 137; para 19, “… the virtual payment instrument 137 can be presented at a point of sale (POS) terminal or used online in order to complete a transaction. The virtual payment instruments 137 can be created by the account user 122 and assigned to the beneficiary user 133. Purchases made using the virtual payment instrument 137 are charged to the account user 122 …”; FIG. 2H, items 246, 255, 260; para 42, “… FIG. 2H illustrates a terminal interface 255 that can be displayed from an individual clicking the "Pay At POS Terminal" button 246. The terminal interface 255 includes a bar code representation 260 of the virtual payment instrument 137. The bar code representation 260 can include a one-dimensional bar code, a two-dimensional bar code, and other bar code variations. The bar code representation 260 can be presented at the POS terminal in order for the POS terminal to receive the virtual payment instrument 137 … the terminal interface 255 can include other machine-readable formats, such as an alphanumeric code … the client device 106 can implement other payment processing wireless protocols for communicating the virtual payment instrument 137 to a POS terminal …”);
generating, by the token service platform (FIG. 1, item 103; para 14), a sharetoken that is linked to the resource, wherein the sharetoken is generated using the token identifier, and wherein the sharetoken represents a limited access credential that provides limited access to the resource (FIG. 6, item 613; para 74, “… box 613, the wallet share application 118 can generate the virtual payment instrument 137 for the beneficiary identifier 134 based at least in part on the second request. The second request can include one or more spending policies 138, the beneficiary identifier 134, and other suitable data. The virtual payment instrument 137 can be linked to a payment instrument account (e.g., a charge card, a credit card, a debit card) or a funding account number of the account user 122 for the first client device 106a …”);
transmitting, by the token service platform (FIG. 1, item 103; para 14), a tokenized provisioning link directly or indirectly to the partner user device (FIG. 6, item 616; para 75, “… box 616, the wallet share application 118 can transmit a reference notification to the second client device 106b. The reference notification can include a hyper-link for authenticating the beneficiary user 133 and providing access to the virtual payment instrument 137 … the hyperlink can direct the second client device 106b to download the beneficiary wallet application 154 from a computing device (e.g., in the computing envi-ronment 103) … the hyperlink can direct the second client device 106b to one or more web pages for authenticating the beneficiary user 133 …”);
receiving, by the token service platform (FIG. 1, item 103; para 14) and via the partner user device (FIG. 1, items 103, 106a, 118; para 16), a generated request for the sharetoken, wherein the generated request is in response to the partner user device executing the tokenized provisioning link (FIG. 6, item 619; para 76, “… the second client device 106b can activate the reference notification (e.g., a hyper-link) to authenticate the beneficiary user 133. For example, the second client device 106b can transmit user credentials and/or identifying information (e.g., an email address, answers to security questions, temporary password, etc.) to authenticate the beneficiary user 133. After the beneficiary user 133 has been authenticated, the second client device 106b can transmit profile information (e.g., beneficiary user data 135) for completing an account for the beneficiary user 133 …”);
confirming, by the token service platform (FIG. 1, item 103; para 14), that the partner user device (FIG. 1, items 103, 106b, 118; para 16, “… The components executed on the computing environment 103 … can include a wallet share application 118, and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. The wallet share application 118 is executed to remotely share a payment instrument of a first user to a client device of a second user. The wallet share application 118 can be used to remotely share a payment instrument of a first user to the second client device 106b of a second user. The wallet share application 118 can enable the first client device 106a to monitor and limit the usage of the payment instrument by the second user …”) is authenticated based on the generated request (FIG. 6, item 619; para 76, “… the second client device 106b can transmit user credentials and/or identifying information (e.g., an email address, answers to security questions, temporary password, etc.) to authenticate the beneficiary user 133. After the beneficiary user 133 has been authenticated, the second client device 106b can transmit profile information (e.g., beneficiary user data 135) for completing an account for the beneficiary user 133 … the second client device 106b can obtain and transmit to the computing environment 103 a username, password, contact information, a device identifier 140 associated with the second client device 106b, and other suitable identifying information associated with the second client device 106b and the beneficiary user 133 … the device identifier 140 is automatically extracted in association with second client device 106b … the device identifier 140 can be determined based on a native or thirty electronic wallet application executed on the second client device 106 …”);
receiving, by an account management platform (FIG. 1, item 122; para 17; “… The data stored in the data store 115 includes … account user 122, domain controls 125, account mappings 128, and potentially other data. The account users 122 can represent various financial account holders. Each financial account holder can have one or more payment instrument accounts or funding accounts, such as a credit card, a debit card, a charge card, a checking account, a saving account, and other suitable financial accounts with a financial entity. The account user 122 can include various data related to one or more financial accounts for a user. Each account user 122 can include one or more beneficiary users 133, one or more virtual payment instruments 137, and one or more device identifiers 140 …”), a transaction authorization request associated with an authorized user device, wherein the transaction authorization request (FIG. 1, items 137, 138; para 22, “… The domain controls 125 can represent data stored in association with virtual payment instruments 137 and their corresponding spending policies 138. When a purchase transaction is submitted for authorization, the domain controls 125 can be accessed to determine whether to authorize the purchase based at least in part on the spending policies 138 for the virtual payment instrument 13 7 submitted for the transaction …”) includes the sharetoken and an identification of the physical access type (FIG. 1, items 128, 134, 137; para 23, “… account mappings 128 can represent various data stored in association with other relevant data. A non-limiting example of an account mapping 128 can include a virtual payment instrument and device identifier mapping 145 that links a virtual payment instrument 137 to a device identifier 140. Another non-limiting example of an account mapping 128 can include a beneficiary identifier and virtual payment instrument mapping 148 that links a beneficiary identifier 134 and a virtual payment instrument 137. Another example of an account mapping 128 can include a mapping of a virtual payment instrument 137 to a funding account number (e.g., payment instrument account) of an account user 122 …”);
determining, by the account management platform (FIG. 1, item 122; para 17), the constraint is satisfied (FIG. 1, items 125, 137, 138; para 22, “… When a purchase transaction is submitted for authorization, the domain controls 125 can be accessed to determine whether to authorize the purchase based at least in part on the spending policies 138 for the virtual payment instrument 137 submitted for the transaction … a purchase transaction can be submitted for authorization, and the purchase transaction can be declined because the purchase transaction is submitted after the expiration date of the virtual payment instrument 137 … the purchase transaction can be declined because the virtual payment instrument 137 has a spending policy 138 for medical expenses and the product associated with the purchase transaction is not classified as a medical expense …; FIG. 1, items 133, 137, 138, 154; para 33, “… the beneficiary wallet application 154 can be executed on the second client device 106b of the beneficiary user 133. The beneficiary wallet application 154 can display a user interface that includes a card representation of the virtual payment instrument 137, the spending policies 138, and checkout buttons for presenting the virtual payment instrument 137 in different checkout contexts (e.g., at a physical POS terminal or at a checkout web page). As such, the beneficiary user 133 can use the virtual payment instrument 137 to make purchases according to the spending policies 138 …”);
suspending, by the account management platform (FIG. 1, item 122; para 17), the sharetoken to prevent unauthorized use of the resource (FIG. 3, item 315; para 48, “… box 315, the wallet share application 118 can transmit a hyperlink for accessing the virtual payment instrument 137 to the second client device 106b. The hyperlink can be emailed, sent via a text message, and other suitable means of data communication, which have been provided in the beneficiary user data 135. The virtual payment instrument 137 is configured to be restricted for a purchase based at least in part on the spending policy 138 …”);
detecting, by an application platform (FIG. 1, item 118; para 16, “… the computing envi-ronment 103 … can include a wallet share application 118, and other applications, services, processes, systems, engines, or functionality … The wallet share application 118 is executed to remotely share a payment instrument of a first user to a client device of a second user. The wallet share application 118 can be used to remotely share a payment instrument of a first user to the second client device 106b of a second user. The wallet share application 118 can enable the first client device 106a to monitor and limit the usage of the payment instrument by the second user …”), the suspended sharetoken (FIG. 6, item 628; para 79, “… At box 628 … the wallet share application 118 can transmit status notification to the payer wallet application 151 for the virtual payment instrument 137. The status notification can include information, such as a remaining balance for the virtual payment instrument 137, reporting of purchases (items, transaction time, transaction location, etc.), and other suitable purchasing information …”); and
pushing, by the application platform (FIG. 1, item 118; para 16), an update to the partner user device, wherein the update reflects the suspended sharetoken (FIG. 6, item 628; para 79, “… At box 628 … the wallet share application 118 can transmit status notification to the payer wallet application 151 for the virtual payment instrument 137. The status notification can include information, such as a remaining balance for the virtual payment instrument 137, reporting of purchases (items, transaction time, transaction location, etc.), and other suitable purchasing information …”; FIG. 6, items 631, 634; para 80, “… box 631, the payer wallet application 151 can obtain through a user interface a change in the spending policy 138 … the beneficiary user 133 can enter an extension of the time period, add or remove a spending category, and adjust other suitable spending policy items …”; para 81, “… box 634, the wallet share application 118 can transmit the updated spending policies 138 to the beneficiary wallet application 154. The updated spending policies 138 can be displayed on the second client device 106b. Then, the depicted process ends, although the wallet share application 118, the payer wallet application 151, and the beneficiary wallet application 154 could continue execution to perform other functions …”).
With respect to claim 10, Mehla further discloses a system (FIG. 1, item 100; para 13, “… FIG. 1 depicts a networked environment 100 according to various embodiments. The networked environment 100 includes a computing environment 103, a first client device 106a, and a second client device 106b, which are in data communication with each other via a network 112 …”) comprising: …
With respect to claim 11, Mehla further discloses a plurality of non-transitory computer-readable mediums comprising: storing instructions that when executed, cause operations to be performed by one or more processors including (para 87, “… any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system … the logic can include statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system … a "computer-readable medium" can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system. Moreover, a collection of distributed computer-readable media located across a plurality of computing devices (e.g., storage area networks or distributed or clustered filesystems or databases) can also be collectively considered as a single non-transitory computer-readable medium …”; para 88, “… computer-readable medium can include any one of many physical media such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium can be a random access memory (RAM) including static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium can be a read-only memory (ROM), a program-mable read-only memory (PROM), an erasable program-mable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device …”): …
Mehla does not specifically disclose, however, Leaman discloses extracting, …, features to define a feature vector from a request to share access to a resource (FIG. 51, items 5100, 5102, 5104, 5106; para 398, “… the entity resolution system 5100 may include an entity encoding module 5102 that may receive an entity entry, may extract one or more entity features from the received entity entry, and may encode each of at least a portion of the one or more entity features as a vector (e.g., a multidimensional entity feature vector) suitable for use by an artificial intelligence system (e.g., a neural network system) … the entity features may be object properties that may be associated with the core object or custom object. The entity encoding module 5102 may encode the entity features into a vectorized representation … text strings, identifiers, numbers, Boolean connectors, and the like of each entity feature (e.g., each element of the entity feature) of each entity of the entities (e.g., entity entries 5106) … a name feature of a first entity may be encoded into a first multidimensional feature vector of the first entity and an address feature of the first entity may be encoded into a second multidimensional feature vector of the first entity. The entity encoding module 5102 may reference a feature encoding source 5104, which may include one or more feature encoding schemes …”), …
transmitting, …, the feature vector including a predicted value for the constraint in a resource-sharing configuration (FIG. 51, items 5100, 5102, 5108; para 399, “… the entity encoding module 5102 may provide its output entity feature vector(s) to an encoding reduction module 5108 (e.g., that may use a trained neural network and/or trained entity deduplication model) … the encoding reduction module 5108 may be implemented to leverage a neural network (e.g., a Siamese neural network) or a suitable model that may be trained to produce a reduced entity-specific vector by processing the feature vector(s) associated with a specific entity… the reduced entity-specific vector produced from the encoding reduction module 5108 may be suitable for further processing to generate a numeric value indicative of a likelihood that the entity that the reduced entity-specific vector represents may be a duplicate of another entity that is similarly represented by a corresponding reduced entity-specific vector …”) …
Leaman discloses a multi-service business platform system having conversation intelligence systems and methods. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a multi-service business platform system having conversation intelligence systems and methods, as in Leaman, to improve and/or enhance the technology of remotely sharing a payment instrument to a client device, as in Mehler, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide systems and methods transforming data from one native format to another suitable form for use in a different environment (machine learning), synchronizing different data sources when changes are made in different databases, normalizing data, cleansing data, and configuring it for use in marketing activities, sales activities, and service activities in managing and analyzing interactions with customers for businesses.
Regarding claims 3, 12, and 18, Mehler and Leaman disclose the limitations of claims 1 and 10-11. Mehler further discloses the method of claim 1, wherein the request includes a first constraint that limits the use of the sharetoken to a particular location (FIG. 1, items 122, 137, 138; para 20, “… The account user 122 can monitor spending events (e.g., purchases) generated by the beneficiary user 133 and can limit the spending capability of the virtual payment instrument 137. The account user 122 can apply one or more spending policies 138 to the virtual payment instrument 137. The spending policy 138 can include one or more spending constraints, restrictions, and/or limitations. Some non-limiting examples of a spending policy 138 can include …, prohibited spending categories ( e.g., spending or transactions that are prohibited for certain categories of merchants or transactions, such as prohibiting spending or transactions at bars, liquor stores, casinos, etc.) …”).
Regarding claims 4, 13, and 19, Mehler and Leaman disclose the limitations of claims 1 and 10-11. Mehler further discloses the method of claim 1, wherein access to the resource is suspended after the partner user device accesses the resource a quantity of times (FIG. 1, items 122, 137, 138; para 20, “… The account user 122 can monitor spending events (e.g., purchases) generated by the beneficiary user 133 and can limit the spending capability of the virtual payment instrument 137. The account user 122 can apply one or more spending policies 138 to the virtual payment instrument 137. The spending policy 138 can include one or more spending constraints, restrictions, and/or limitations. Some non-limiting examples of a spending policy 138 can include an allocated spending limit, a frequency in which the allocated spending limit is provided (e.g., weekly, monthly, every two months) …”).
Regarding claims 5, 14, and 20, Mehler and Leaman disclose the limitations of claims 1 and 10-11. Mehler further discloses the method of claim 1, wherein access to the resource is suspended after the partner user device accesses a quantity of the resource (FIG. 1, items 122, 137, 138; para 20, “… The account user 122 can monitor spending events (e.g., purchases) generated by the beneficiary user 133 and can limit the spending capability of the virtual payment instrument 137. The account user 122 can apply one or more spending policies 138 to the virtual payment instrument 137. The spending policy 138 can include one or more spending constraints, restrictions, and/or limitations. Some non-limiting examples of a spending policy 138 can include an allocated spending limit, …”).
Regarding claims 7, 16, and 22, Mehler and Leaman disclose the limitations of claims 1 and 10-11. Mehler further discloses the method of claim 1, wherein the sharetoken provides access to the resource through near-field communication (FIG. 2H, items 246, 255, 260; para 42, “… FIG. 2H illustrates a terminal interface 255 that can be displayed from an individual clicking the "Pay At POS Terminal" button 246. The terminal interface 255 includes a bar code representation 260 of the virtual payment instrument 137. The bar code representation 260 can include a one-dimensional bar code, a two-dimensional bar code, and other bar code variations. The bar code representation 260 can be presented at the POS terminal in order for the POS terminal to receive the virtual payment instrument 137 … Further, the client device 106 can implement other payment processing wireless protocols for communicating the virtual payment instrument 137 to a POS terminal. Some non-limiting examples include Near Field Communication (NFC), a Radio Frequency Identification (RFID), and other suitable contactless payment protocols.…”).
Regarding claims 8 and 17, Mehler and Leaman disclose the limitations of claims 1 and 10. Mehler further discloses the method of claim 1, further comprising:
receiving a subsequent request to share access to the resource, the subsequent request including a user identifier (FIG. 3, item 309; para 46, “… box 309, the wallet share application 118 can receive a second request from the first client device 106a to generate a virtual payment instrument 137. The second request can cause the wallet share application 118 to generate the virtual payment instrument 137 for one or more of the beneficiary identifiers 134 associated with the account user 122. The second request can include a reference to one or more beneficiary identifiers 134 and one or more spending policies 138 for the virtual payment instrument 137. Some non-limiting examples of a spending policy 138 can include a monetary limit, a frequency in which the monetary limit will be available to the beneficiary identifier 134, a start date for use of the virtual payment instrument 137, an end date for use of the virtual payment instrument 13 7, and other suitable spending policies 138 …”);
determining that the sharetoken has been suspended (FIG. 3, item 315; para 48, “… box 315, the wallet share application 118 can transmit a hyperlink for accessing the virtual payment instrument 137 to the second client device 106b. The hyperlink can be emailed, sent via a text message, and other suitable means of data communication, which have been provided in the beneficiary user data 135. The virtual payment instrument 137 is configured to be restricted for a purchase based at least in part on the spending policy 138 …”); and
transmitting a notification that activates the sharetoken, wherein activating the sharetoken provides limited access to the resource by the partner user device (FIG. 3, item 318; para 49, “… box 318, the wallet share application 118 can receive an indication of an activation of the hyperlink from the second client device 106b of the beneficiary user 133 (e.g., associated with the beneficiary identifier 134). In response to receiving the indication, the wallet share appli-cation 118 can direct the second client device 106b to download a beneficiary wallet application 154 or display a web page. Either approach can display a user interface ( e.g., via a web page) for authenticating the beneficiary user 133 …”).
Regarding claims 23-25, Mehler and Leaman disclose the limitations of claims 1 and 10-11. Mehler further discloses the method of claim 1, wherein the sharetoken is used by terminal devices that are in physical proximity to the partner user device (FIG. 2H, items 246, 255, 260; para 42, “… FIG. 2H illustrates a terminal interface 255 that can be displayed from an individual clicking the "Pay At POS Terminal" button 246. The terminal interface 255 includes a bar code representation 260 of the virtual payment instrument 137. The bar code representation 260 can include a one-dimensional bar code, a two-dimensional bar code, and other bar code variations. The bar code representation 260 can be presented at the POS terminal in order for the POS terminal to receive the virtual payment instrument 137 … Further, the client device 106 can implement other payment processing wireless protocols for communicating the virtual payment instrument 137 to a POS terminal. Some non-limiting examples include Near Field Communication (NFC), a Radio Frequency Identification (RFID), and other suitable contactless payment protocols.…”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sawant et al (U. S. Patent No. 10692074 B2) – Secure Resource Sharing Between Computing Devices For Electronic Transactions
Sawant recites techniques relating to authorization of asset sharing for transactions by other user accounts. In some embodiments, an apparatus is configured to transmit a request to a mobile device on behalf of a first user account. In some embodiments, the apparatus is configured to receive, from the mobile device in response to the request, an electronic message in a format recognized by an authorization computing system. In some embodiments, the electronic message includes a constraint for a transaction, a replenishment key, and a hash value generated based on at least a portion of other information in the message. In some embodiments, the apparatus is configured to transmit the electronic message for communication to the authorization computing system. In some embodiments, the apparatus is configured to receive transaction authorization based on a comparison of the hash value in the electronic message and a copy of the hash value from the mobile device
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, EST.
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, Ryan D. Donlon can be reached (571) 270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN CHISM/
Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 June 18, 2026
Prosecution Insights