Detailed Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgments
The submission filed on 05/27/25 is acknowledged.
Status of Claims
Claims 1-20 are pending.
In the Amendment filed on 05/27/25, claims 1, 2, 7, 9, 11 and 13-20 were amended, and no claims were cancelled or added.
Claims 1-20 are rejected.
Response to Arguments
Regarding the double patenting rejections
In view of the claim amendments, the double patenting rejections have been withdrawn.
Regarding the rejection under 35 U.S.C. 112
In view of the claim amendments, the rejections have been withdrawn.
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
The Office responds to Applicant's arguments below.
Note: Applicant’s Response does not have page numbers, so citations thereto below are referenced by section letter/heading.
Applicant argues that the claims recite a messaging scheme that facilitates secure communications / improves data security over a network. For example, Applicant states:
As amended, the claims are directed to a messaging scheme between multiple computing platforms that leverages new data structures to facilitate secure communications between the different platforms. (Response, D.)
… claim 1 recites a message scheme for improving data security over a network. (Response, Step 2A - Prong One)
However, the independent claims squarely encompass a value exchange in which exchange objects are found valid or invalid and the exchange is approved or denied.
Applicant further argues that the claimed messaging scheme may be used in different domains, not merely transaction processing. For example, Applicant states:
More specifically, the recited messaging scheme may be used in multiple different domains, or "value systems", including for transaction processing, because it solves technical problems underlying any network communication. For example, the Specification describes that persistent credentials, computing platforms, and other aspects of the claimed invention could include payment credentials for transaction processing or any other sensitive information, such as subscription account numbers in an information value system, healthcare numbers in a healthcare value system, for any other network-based action. See e.g., Specification ¶¶ [0143] - [0145]. (Response, Step 2A - Prong One)
While Applicant’s disclosure does reference healthcare and information in addition to financial transactions, these too are described as value exchanges (e.g., 0143-0145), suggesting these too are financial/monetary exchanges. In any event, as best understood, the only concrete examples/particular scenarios described in Applicant’s disclosure involving the claimed ‘invalidated objects” pertain to financial transactions (0052, 0289, 0308). Thus, the instant claims are understood as directed to allegedly improving the security of financial transactions – in other words, mitigating the risk of financial loss in financial transactions, whereby the claims fall under the abstract idea category of certain methods of organizing human activity, specifically, fundamental economic practices or principles (e.g., mitigating risk) and/or commercial or legal interactions (e.g., sales activities or behaviors).
Applicant further argues that the claimed messaging scheme improves the functioning of a computer or other technology. For example, Applicant states:
… the messaging scheme recited by claim 1 is specifically designed to improve the functioning of a computer, not simply use the computer in its traditional capacity to automate a conventional process. (Response, Step 2A – Prong Two)
… This messaging scheme, including each of the specific identifiers, platforms, and messages, recited by claim 1, improves data security and communication flexibility by enabling the secure use of APIs and eliminating persistent credentials from network communications entirely without storing the credentials within an intermediary platform. (Response, Step 2A – Prong Two)
The Office respectfully disagrees. The claims recite off-the-shelf computer elements (e.g., processor, platform, API) at a high level of generality used in their conventional capacity (e.g., receiving data, storing data). Absolutely no improvement in the actual functioning or hardware of a computer or other technology is seen in the claims. Any putative improvement provided by the claims would be a matter of the data elements – their characteristics and/or their being processed or exchanged by generic computers.
Further in regard to improvements, Applicant cites alleged additional elements:
… claim 1 recites additional elements (e.g., a configuration of platforms, messaging scheme, and identifiers) that improves a technical field such that the claim as a whole integrates any alleged abstract idea into a practical application. (Response, Step 2A – Prong Two)
The Office respectfully disagrees. As best understood, the alleged additional elements quoted above are not additional elements but elements of the abstract idea. (It is not clear what claim limitations Applicant is referring to by “configuration of platforms.”)
Finally, Applicant argues that the instant claims are analogous to Bascom. (Response, Step 2B)
The Office respectfully disagrees. While Bascom’s filtering content was found to be a “method of organizing human behavior,” the claim in the Subject Matter Eligibility Examples: Business Methods (Dec. 2016) (Ex. 34) was found to be an improvement in the computer technology of filtering, albeit a close call. In contrast, Applicant’s claims merely send messages using identifiers to register and enroll a user, and then to approve or deny a user’s transaction involving invalidated exchange objects (e.g., a restricted product such as alcohol, see Applicant’s specification, 0308)
Regarding the rejections under 35 U.S.C. 103
In view of the claim amendments, the rejections have been withdrawn.
Subject Matter Free of Prior Art
The cited prior art of record, either alone or in combination, fails to expressly teach or suggest the features found in the independent claims. Fitzpatrick, Drunsic, Bennett and Skiba teach processing a transaction including determining whether transaction attributes conform to a policy (e.g., whether objects for purchase are valid or invalid based on a policy). Mullaney and Niehaus teach the generation and use of identifiers/tokens (e.g., account number proxies) for use in transactions (e.g., for authorization), which promote security/privacy. In particular, the cited prior art of record fails to expressly teach or suggest all of the features in independent claims 1, 14 and 19 and more specifically the limitations of: (1) at a first time, during a registration process: (i) receiving, by one or more processors of an intermediary platform and from a service provider platform, an instrument reference that comprises a unique identifier for referencing a member instrument identifier for a service provider instrument maintained by the service provider platform, wherein the instrument reference is (a) a different value than the member instrument identifier and (b) is mapped to the member instrument identifier; (ii) generating, by the one or more processors, an instrument key that corresponds to the service provider instrument by wrapping a universally unique identifier (UUID) with a service provider partition that corresponds to the service provider platform; (iii) storing, by the one or more processors, the UUID and the instrument reference within a system instrument data object; and (iv) providing, by the one or more processors, the instrument key to the service provider platform; (2) at a second time, in response to a successful enrollment with a partner platform: (i) generating, by the one or more processors, a universally unique ephemeral key (UUEK) comprising an exchange identifier and a partner partition, the partner partition identifying the partner platform, wherein the exchange identifier and the partner partition are positioned in accordance with a key format; and (ii) providing, by the one or more processors, the UUEK to the partner platform; (3) at a third time subsequent to the first time and the second time: (i) receiving, by the one or more processors, from the partner platform, and through a first application programming interface (API), an exchange request for executing a network-based exchange that comprises the UUEK; (ii) identifying, by the one or more processors, a partner-specific exchange data object based at least in part on the exchange identifier of the UUEK, wherein the partner-specific exchange data object comprises the instrument key; (iii) identifying, by the one or more processors, the system instrument data object based at least in part on the instrument key within the partner-specific exchange data object, in combination with the other claim limitations.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-20 are directed to a method, system, or product, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1, 14 and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method, system, and computer-readable storage media for transaction (exchange) processing, including applying transaction rules (e.g., determining whether exchange objects are valid) and avoiding disclosure of sensitive information (e.g., by the use of identifying data). For claims 1, 14 and 19 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
(1) at a first time, during a registration process:
(i) receiving, by one or more processors of an intermediary platform and from a service provider platform, an instrument reference that comprises a unique identifier for referencing a member instrument identifier for a service provider instrument maintained by the service provider platform, wherein the instrument reference is (a) a different value than the member instrument identifier and (b) is mapped to the member instrument identifier;
(ii) generating, by the one or more processors, an instrument key that corresponds to the service provider instrument by wrapping a universally unique identifier (UUID) with a service provider partition that corresponds to the service provider platform;
(iii) storing, by the one or more processors, the UUID and the instrument reference within a system instrument data object; and
(iv) providing, by the one or more processors, the instrument key to the service provider platform;
(2) at a second time, in response to a successful enrollment with a partner platform:
(i) generating, by the one or more processors, a universally unique ephemeral key (UUEK) comprising an exchange identifier and a partner partition, the partner partition identifying the partner platform, wherein the exchange identifier and the partner partition are positioned in accordance with a key format; and
(ii) providing, by the one or more processors, the UUEK to the partner platform;
(3) at a third time subsequent to the first time and the second time:
(i) receiving, by the one or more processors, from the partner platform, and through a first application programming interface (API), an exchange request for executing a network-based exchange that comprises the UUEK;
(ii) identifying, by the one or more processors, a partner-specific exchange data object based at least in part on the exchange identifier of the UUEK, wherein the partner-specific exchange data object comprises the instrument key;
(iii) identifying, by the one or more processors, the system instrument data object based at least in part on the instrument key within the partner-specific exchange data object;
(iv) identifying, by the one or more processors, a member policy corresponding to the service provider platform based at least in part on the service provider partition of the instrument key;
(v) determining, by the one or more processors, one or more validated objects and one or more invalidated objects for the exchange request based at least in part on the member policy;
(vi) providing, by the one or more processors and through a second API, an exchange authorization request to the service provider platform, wherein the exchange authorization request comprises the instrument key, the instrument reference, and the one or more validated objects for the exchange request;
(vii) receiving, by the one or more processors, from the service provider platform, and through the second API, an exchange authorization response that is indicative of at least one of an exchange approval or an exchange denial; and
(viii) providing, by the one or more processors, to the partner platform, and through the first API, an exchange response based at least in part on the exchange authorization response, wherein the exchange response is indicative of (a) the exchange approval or the exchange denial and (b)the one or more invalidated objects for the exchange request.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components. The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1, 14 and 19 recite an abstract idea. (Step 2A - Prong 1: YES. The claims recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 1, 14 and 19 recite the additional elements of one or more processors of an intermediary platform (claim 1), a service provider platform (claims 1, 14 and 19), a partner platform (claims 1, 14 and 19), a first application programming interface (API) (claims 1, 14 and 19), a network(-based exchange) (claims 1, 14 and 19), a second API (claims 1, 14 and 19), an intermediary platform comprising memory and one or more processors communicatively coupled to the memory (claim 14), and one or more non-transitory computer-readable storage media (claim 19), that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions), such that they amount to no more than mere instructions to apply the exception using generic computer elements. Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of one or more processors of an intermediary platform (claim 1), a service provider platform (claims 1, 14 and 19), a partner platform (claims 1, 14 and 19), a first application programming interface (API) (claims 1, 14 and 19), a network(-based exchange) (claims 1, 14 and 19), a second API (claims 1, 14 and 19), an intermediary platform comprising memory and one or more processors communicatively coupled to the memory (claim 14), and one or more non-transitory computer-readable storage media (claim 19), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements. Mere instructions to apply an exception using generic computer elements cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1, 14 and 19 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 2-13, 15-18 and 20 are similarly rejected because they further define/narrow the abstract idea of independent claims 1, 14 and 19 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Claims 2 and 15 merely describe wherein the exchange request comprises one or more request resolution flags that are indicative of a partial exchange authorization or a full exchange authorization, and wherein providing the exchange authorization request to … comprises: determining that the one or more request resolution flags are indicative of the partial exchange authorization; and providing the exchange authorization request to … in response to the determination that the one or more request resolution flags are indicative of the partial exchange authorization.
Claims 3 and 16 merely describe wherein the exchange request comprises a plurality of object identifiers corresponding to a plurality of objects associated with the …-based exchange.
Claims 4 and 17 merely describe wherein an object identifier is a stock keeping unit.
Claims 5 and 18 merely describe wherein the member policy comprises a plurality of authorized object identifiers and determining the one or more validated objects and the one or more invalidated objects for the exchange request comprises: determining the one or more validated objects based at least in part on a comparison between the plurality of object identifiers and the plurality of authorized object identifiers; and determining the one or more invalidated objects based at least in part on a comparison between the one or more validated objects and the plurality of objects associated with the …-based exchange.
Claim 6 merely describes wherein the member policy comprises a plurality of authorized object attributes and determining the one or more validated objects and the one or more invalidated objects for the exchange request comprises: identifying a plurality of recorded data objects corresponding to the plurality of object identifiers, wherein a recorded data object comprises a plurality of object attributes for an object; determining the one or more validated objects based at least in part on a comparison between the plurality of recorded data objects and the plurality of authorized object attributes; and determining the one or more invalidated objects based at least in part on a comparison between the one or more validated objects and the plurality of objects associated with the …-based exchange.
Claim 7 merely describes wherein the plurality of object attributes comprises at least one of a spatial attribute, a count attribute, a value attribute, a source attribute, a composition attribute, or a categorical attribute.
Claim 8 merely describes further comprising incrementing the count attribute for the object in response to the exchange request.
Claim 9 merely describes wherein the member policy is identified based at least in part on … and … associated with the exchange request.
Claim 10 merely describes wherein … and the exchange request is indicative of ….
Claim 11 merely describes wherein … and the …-implemented method further comprises: determining a user identifier associated with the …-based exchange based at least in part on the UUEK; determining … based at least in part on a system user data object corresponding to the user identifier; and identifying the member policy based at least in part on … and ….
Claim 12 merely describes wherein the exchange request is indicative of … and the member policy is indicative of …, and wherein the …-implemented method further comprises: determining the one or more validated objects and the one or more invalidated objects for the exchange request based at least in part on a comparison between ….
Claims 13 and 20 merely describe wherein the exchange request comprises a plurality of object values corresponding to a plurality of objects associated with the …-based exchange and an initial exchange value for the plurality of objects, and wherein the …-implemented method further comprises (claim 13) / wherein … are further caused to (claim 20): determining an exchange value for the network-based exchange by modifying the initial exchange value based at least in part on one or more of the plurality of object values that correspond to the one or more validated objects; and providing the exchange authorization request to …, wherein the exchange authorization request is indicative of the exchange value.
As for additional elements:
Claims 2 and 15 merely recite that a request is provided to “the service provider platform.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 3, 5, 6, 16 and 18 merely recite that an exchange is based on a “network.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 9 merely recites that a policy is identified based on “the service provider platform and a location.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element or generally linking the use of a judicial exception to a particular technological environment or field of use. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 10 merely recites “wherein the location comprises an exchange location” and a request is indicative of “the exchange location.” This recitation is at a high level of generality such that it amounts to no more than generally linking the use of a judicial exception to a particular technological environment or field of use. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 11 merely recites “the location comprises a user location,” that the method is “computer”-implemented, that the exchange is based on a “network,” (determining) “the user location,” and that a policy is identified based on “the service provider platform and the user location.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element or generally linking the use of a judicial exception to a particular technological environment or field of use. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 12 merely recites that a request is indicative of “an exchange location,” that a policy is indicative of “one or more authorized locations,” that the method is “computer”-implemented, and that objects are determined based on a comparison between “the exchange location and the one or more authorized locations.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element or generally linking the use of a judicial exception to a particular technological environment or field of use. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 13 and 20 merely recite that the exchange is based on a “network,” that the method is “computer”-implemented (claim 13), that “the one or more processors” are caused to perform operation (claim 20), and that a request is provided to “the service provider platform.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 4, 7, 8 and 17 do not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 2-13, 15-18 and 20 are not patent eligible.
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure. Among the cited references, note that WO-2014011691-A1 (SHRIVASTAVA ABHINAV) is enclosed as two separate parts because the document file size is too large; accordingly, it is required to list the two parts separately on the Notice of References Cited (PTO-892).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571)272-4131. The examiner can normally be reached on 8:30 am – 5:30 pm ET.
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, Jessica Lemieux can be reached on 571-270-3445. 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 http://pair-direct.uspto.gov. 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.
/DWP/
Examiner, Art Unit 3626A
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights