DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
This action is in reply to the response and/or arguments filed for Application 19/086,767 filed on 21 March 2025.
Claims 1-22 have been previously canceled.
Claims 23-32 of Group I have been elected in the response.
Claims 33-42 of Group II have been withdrawn/canceled.
Claims 23-32 are currently pending and have been examined.
Information Disclosure Statement
The Information Disclosure Statement filed 9 June 2025 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
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 23-32 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, representative method claim 23 is directed towards facilitating content (data) exchange between computing systems operated by different entities. Claim 23 recites the abstract idea of using rules and/or instructions to implement an economic- /commercial-related concept/practice of secure data transfer using associated identifiers between financial institutions associated with a financial-related transaction in an automatic manner utilizing existing technology, grouped under the certain methods of organizing human activity – fundamental economic principles, practices or concepts; sales activity; following set of instructions; commercial or legal interactions (agreements in the form of contracts; business relations); managing interactions between people (including social activities, teachings, following rules or instructions) grouping, in step 2A, prong one.
Claim 23 recites:
“receiving, from a sending financial institution system, a request for a session token;
generating the session token with a predetermined active period;
validating the session token for subsequent requests from the sending financial institution system;
receiving, within the predetermined active period, a registration request for a content item;
verifying credentials in a registration request header, the credentials comprising:
the session token;
a financial institution identifier; and
a sender identifier;
encrypting the content item;
storing the encrypted content item in a content database;
generating a globally unique identifier (GUID) associated with the encrypted content item; and
returning the GUID to the sending financial institution system”.
Based on the underlined elements above, abstract ideas and/or concepts are identified. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because, when analyzed under step 2A, prong two, the additional elements of the claim such as a “encrypting the content item”, “storing the encrypted content item in a content database”, represent the use of a computer as a tool (intermediary) to perform an abstract idea and/or does no more than generally apply the abstract idea to a particular field of use. 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 (i.e. automate) implement the acts of using rules and/or instructions to implement an economic- /commercial-related concept/practice of secure data transfer using associated identifiers between financial institutions associated with a financial-related transaction in an automatic manner utilizing existing technology. As such, none of the limitations integrate the abstract idea of certain methods of organizing human activity into a practical application as the claims as a whole merely uses instructions to implement the abstract idea on a computer or, alternatively, merely uses a computer as a tool to perform the abstract idea.
When analyzed under step 2B, 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 using rules and/or instructions to implement an economic- /commercial-related concept/practice of secure data transfer using associated identifiers between financial institutions associated with a financial-related transaction in an automatic manner utilizing existing technology. Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Hence, the claim is not patent eligible.
Dependent claims 24-32 add further details and contain limitations that narrow the scope of the invention. However, these details do not result in significantly more than the abstract idea itself. As explained in the December 16, 2014 Interim Eligibility Guidance from the USPTO (in reference to the BuySAFE, Inc. v. Google, Inc. decision), further narrowing the details of an abstract idea does not change the § 101 analysis since a more narrow abstract idea does not make it any less abstract.
Viewed individually and in combination, these additional elements do not provide meaningful limitations to transform the abstract idea such that the claims amount to significantly more than the abstraction itself.
Accordingly, the present pending claims are not patent eligible and are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections – 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office Action:
A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 23-32 are rejected under U.S.C. 103 as being unpatentable over Narayan et al., US 11,127,016 B2 (“Narayan”), in view of Subbarayan et al., US 2017 /0262842 A1 (“Subbarayan”).
Re Claim 1-22: (Canceled)
Re Claim 23: (New) Narayan discloses a method for secure content exchange, comprising:
receiving, from a sending financial institution system, a request for a session token; (FIG. 2: “TOKEN REQUEST MODULE 130E”)
generating the session token with a predetermined active period; (FIG. 3: “TOKEN PROCESSING MODULE 150F”)
validating the session token for subsequent requests from the sending financial institution system; (FIG. 9, S530 – “VALIDATE VERIFICATION VALUE”)
receiving, within the predetermined active period, a registration request for a content item; (C19 L59-61: “user may provide payment credentials for a transaction, or during an account registration process”; C26 L40-43: “enabler computer 625 may allow the resource provider to conduct ecommerce transactions through a third-party mobile application or website, such as through content published by the content publisher computer 622.”)
verifying credentials in a registration request header, the credentials comprising: (FIG. 9, S530 – “VALIDATE VERIFICATION VALUE”)
the session token; a financial institution identifier; a sender identifier; (C24 L61-64: “verification value can be generated based on the dynamic data element, the payment token, the token expiration date, the token requestor ID, and/or any other suitable information”)
encrypting the content item; (C12 L1-5: “Embodiments allow any other information and messages to be encrypted, such as communications between the resource provider computer 130 and token provider computer 170”)
storing the encrypted content item in a content database; (C11 L12-15: “token request module 130E may also include instructions for associating a received token with the user 110 and storing the received token in the token database 130C.”)
Regarding the limitation(s) comprising:
generating a globally unique identifier (GUID) associated with the encrypted content item;
returning the GUID to the sending financial institution system.
Subbarayan, however, makes this teaching in a related endeavor ([0043] “payment message can include a consumer identifier, a merchant identifier, a payment amount, product details, a payment authorization number, and/ or other information that allows the payment system 108 to begin the payment transaction process”; [0041] “merchant commerce platform 106 can then send the network payment token, along with other payment transaction information to the payment gateway system 114 to process the payment transaction. In one or more embodiments, the payment gateway system 114 also communicates with the card network system 118 to transmit the payment transaction information, including the network payment token to the card network system 118 in connection with the payment transaction”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbarayan with the invention of Narayan as disclosed above for the motivation of enabling network tokenization
of payment authorization numbers for processing payment transactions.
Re Claim 24: (New) Narayan in view of Subbarayan discloses the method of claim 23.
receiving an availability request for the content item; determining a status of the content item, wherein the status comprises: an active status indicating the content item is available for retrieval; an inactive status indicating the content item is not available for retrieval; or an expired status indicating the content item has been deleted from the content database; validating the session token associated with the availability request; and returning the status of the content item.
Re Claim 25: (New) Narayan in view of Subbarayan discloses the method of claim 23. Narayan further discloses:
receiving a retrieval request including the GUID from a recipient financial institution system; (C8 L50-55: “authorization response message may include, by way of example only, one or more of the following status indicators: Approval transaction was approved; Decline-transaction was not approved; or Call Center-response pending more information”)
verifying retrieval credentials through an access interface, wherein the retrieval credentials comprise a retrieval token providing authorization to perform specific retrieval actions during a particular session; validating that the recipient financial institution system matches recipient metadata associated with the encrypted content item; and determining that both: the retrieval credentials are successfully verified through the access interface; and the recipient financial institution system is successfully validated as matching the recipient metadata; and returning the encrypted content item upon the determination that both the verification and validation are successful. (FIG. 9, S530 – “VALIDATE VERIFICATION VALUE”)
Re Claim 26: (New) Narayan in view of Subbarayan discloses the method of claim 25. Narayan further discloses:
wherein verifying the retrieval credentials comprises: receiving a token request from the recipient financial institution system; generating the retrieval token with a predetermined configuration comprising at least one of: a specified time period for token validity; a maximum number of retrieval requests; or authorization for a specific retrieval action; and validating the retrieval token before processing the retrieval request. (FIG. 2: “TOKEN REQUEST MODULE 130E”)
Re Claim 27: (New) Narayan in view of Subbarayan discloses the method of claim 23. Regarding the limitation(s) comprising:
wherein storing the encrypted content item comprises: validating metadata associated with the content item, wherein the metadata comprises: a sender financial institution identifier; a recipient financial institution identifier; content type information; content size information; and content format specifications; and storing the validated metadata with the encrypted content item in the content database.
Subbarayan, however, makes this teaching in a related endeavor ([0162] “memory 604 may be used for storing data, metadata, and programs for execution by the processor(s)”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbarayan with the invention of Narayan as disclosed above for the motivation of enabling network tokenization of payment authorization numbers for processing payment transactions.
Re Claim 28: (New) Narayan in view of Subbarayan discloses the method of claim 23. Narayan further discloses:
wherein the predetermined active period comprises at least one of: a specified time duration; a maximum number of requests; or completion of a specific request. (C7 L25-27: “token expiry date can be expressed as an time duration as measured from the time of issuance.
Re Claim 29: (New) Narayan in view of Subbarayan discloses the method of claim 23. Narayan further discloses:
executing one or more process flows in communication with the secure content exchange platform within the predetermined active period using the session token. (C7 L25-27: “token expiry date can be expressed as an time duration as measured from the time of issuance.
Re Claim 30: (New) Narayan in view of Subbarayan discloses the method of claim 23. Regarding the limitation(s) comprising:
wherein the content item comprises at least one of: a document; a data file; an image; or a media file.
Subbarayan, however, makes this teaching in a related endeavor (C12 L9-11: “data management circuit 140 is structured to gather data about the user 102 from any accounts associated
with the platform 120”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbarayan with the invention of Narayan as disclosed above for the motivation of enabling network tokenization of payment authorization numbers for processing payment transactions.
Re Claim 31: (New) Narayan in view of Subbarayan discloses the method of claim 23. Narayan further discloses:
validating file size of the content item against predetermined size limits prior to storage, wherein: the predetermined size limits are configured according to content exchange platform capacity; content items exceeding size limits are rejected or compressed; and size limit validation occurs during conformance checks by the exchange gateway interface. (C3 L46-47: “… determine the format or size of the dynamic data element”; C4 L61-62: “token provider computer may validate the verification value”)
Re Claim 32: (New) Narayan in view of Subbarayan discloses the method of claim 23. Narayan further discloses:
maintaining the content item in an encrypted state: during initial transmission from the sending financial institution system; throughout storage in the content database; during retrieval transmission to a recipient financial institution system; and until decryption by the recipient financial institution system or retrieval interface. (C12 L1-5: “Embodiments allow any other information and messages to be encrypted, such as communications between the resource provider computer 130 and token provider computer 170”)
Conclusion
The prior art(s) made of record and not relied upon is/are considered pertinent to applicant's disclosure.
Dolezal (US 2024/0037544 A1) discloses cloud-based transaction processing. An invoice-centric, payee-centric, and/or payer-payee neutral transaction service is provided. Subsets of the transaction data for the transaction can be received separately from the parties to the transaction. The subsets of transaction data are linked to the transaction and containerized within a hierarchy. Each container within the hierarchy can include its own separate and independent encryption, encoding, and/or access rights. An invoice associated with the transaction is presented to a payer for approval before the transaction is processed, and upon payer approval, the transaction is processed on behalf of the parties using one or more selected containers from the hierarchy. Both the payee and payer may be notified when the transaction is completed.
Nagel et al. (US 7,181,017 B1) discloses a system and method for secure three-party communications. A system and method for communicating information between a first party and a second party, comprising identifying desired information, negotiating, through an intermediary, a comprehension function for obscuring at least a portion of the information communicated between the first party and the second party, communicating the encrypted
information to the second party, and decrypting the encrypted information using the negotiated comprehension function. Preferably, the intermediary does not itself possess
sufficient information to decrypt the encrypted information, thus allowing use of an "untrusted" intermediary. The comprehension function may be dynamic with respect to its response to the negotiated comprehension function, and thus permit limitations on the use of the information by the second party. For example, the decryption of the encrypted information may be time limited.
Claims 23-32 are rejected.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Clifford Madamba whose telephone number is 571-270-1239. The examiner can normally be reached on Mon-Thu 7:30-5:00 EST Alternate Fridays.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon, can be reached at 571-272-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 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.
/CLIFFORD B MADAMBA/Primary Examiner, Art Unit 3692
Prosecution Insights