Remarks
Claims 1-20 are pending.
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 .
Examiner’s Note
It is noted that the IDSes filed 10/22/2025 contain a large number of references for consideration by the Examiner. If the applicant and/or applicant’s representative is aware of any particular reference or portion of a reference in the list which the examiner should pay particular attention to, it is requested that it be specifically pointed out in response to this office action.
Information Disclosure Statement(s)
The information disclosure statements filed 10/22/2025 fail to comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 because of the reasons noted below. It has been placed in the application file, but the information referred to therein has not been considered as to the merits. Applicant is advised that the date of any re-submission of any item of information contained in this information disclosure statement or the submission of any missing element(s) will be the date of submission for purposes of determining compliance with the requirements based on the time of filing the statement, including all certification requirements for statements under 37 CFR 1.97(e). See MPEP § 609.05(a).
Mooney v. Brunswick Corp. (Mooney v. Brunswick Corp., 663 F.2d 724, 212 U.S.P.Q. 401, 407 (7th Cir. 1981)) states the following:
Mooney's reissue application cited 56 prior art references (including the Kiekhaefer drawing and the Gale Products drawing) but in no purported order of importance. The letter which accompanied the application similarly failed to disclose which references were most relevant to the patentability of the gear structure. Ordinarily, an examiner specifies the pertinent prior art references in the Office Action, but neither the Kiekhaefer drawing nor the Gale Products drawing were listed by the examiner in the Office Action in this case. Considering the large number of references which were included on the patent examiner's list, we do not think it unreasonable for the district court to have concluded that the examiner failed to consider these drawings as relevant prior art. As a result, the statutory presumption of validity which may be enhanced when prior art has been considered and rejected by the Patent Office is dissipated in Mooney's case with respect to the Kiekhaefer drawing and the Gale Products drawing. Compare Ortho Pharmaceutical Corp. v. American Hospital Supply Corp., 534 F.2d 89 (7th Cir. 1976) and Tracor, Inc. v. Hewlett-Packard Co., 519 F.2d 1288 (7th Cir. 1975) with Chicago Rawhide Manufacturing Co. v. Crane Packing Co., supra.
Thus, 56 references has been found by the U.S. Court of Appeals for the Seventh Circuit to be large enough to be considered a “large number of references” and that it is not “unreasonable … to have concluded that the examiner failed to consider these drawings as relevant prior art” with respect to 2 drawings buried within the 56 references. It is noted that “these drawings” could be any portion of any document within an IDS.
Therefore, the IDS or set of IDSes in the current application that contains at least 56 references is clearly also considered to have a large number of references and it is not unreasonable to conclude that the examiner cannot consider everything within these documents.
As discussed in Ecto World, LLC v. RAI Strategic Holdings, Inc. (Ecto World, LLC v. RAI Strategic Holdings, Inc., IPR2024-01280, Paper 13 (May 19, 2025)):
Most IDS submissions contain fewer than 25 references. See Setting and Adjusting Patent Fees During Fiscal Year 2025, 89 FR 91898 at 91924 (Nov. 20, 2024) (“Approximately 87% of applications contain 50 or fewer applicant-provided items of information, and approximately 77% contain fewer than 25 . . . [O]nly 4% of applications contain more than 200 applicant-provided items of information.”).
It was decided in Ecto World, LLC v. RAI Strategic Holdings, Inc. that, since the IDS was large, even though the Examiner signed the IDS as considered (please see PTAB response referenced therein as well as file history for the application), the size of the IDS warranted further consideration since the Examiner may not have fully considered everything therein. Indeed, Examiners do not have time to review every reference in a large IDS.
Therefore, for the above reasons that the current IDS or set of IDSes is considered large and the fact that the USPTO as well as Federal Circuit believe that examiners cannot review every reference in a large IDS, this IDS or set of IDSes cannot be considered.
Applicant is hereby requested to call the Examiner’s attention to particular references and portions of references that the Examiner should pay particular attention to.
Claim Interpretation
As Applicant notes, for example, on page 8 of the response dated 9/29/2025, “The claims have been amended herein to recite the physical components (i.e., an intermediary platform; a network of member platforms associated with the intermediary platform; and a client device comprising one or more processors; and one or more memories storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations) of the computing system as a elements outside of the preamble.” Thus, the following are considered physical components:
an intermediary platform;
a network of member platforms associated with the intermediary platform;
a client device;
one or more processors; and
one or more memories
Moreover, all non-transitory computer-readable storage media are construed as being limited to statutory storage media.
Response to Arguments
Applicant's arguments filed 9/29/2025 have been fully considered but they are not persuasive.
With respect to Applicant’s allegations on page 9 of the response dated 9/29/2025, it is noted that Osterkamp certainly does disclose a UUEK that is an external representation of an exchange identifier and is issued to the first member platform from the intermediary platform and the UUEK comprises the exchange identifier and a member partition, corresponding to the first member platform, arranged in accordance with a key format, for example, in Osterkamp’s disclosure of receiving token(s), which is associated with the user’s account identifier and is associated therewith for later server lookup, and is also associated with the user’s credentials, such as user identifier, including the exchange identifier (e.g., the whole thing, or any portion thereof), partitions, such as facilitating server partition (e.g., first digit), rest of token, etc., as examples, for example. Moreover, despite Applicant alleging that “It does not include multiple identifiers, such as the exchange identifier and the member partition of the UUEK”, the claim does not require such. In fact, the claim requires that the UUEK is a representation of the exchange identifier. Therefore, the entire UUEK can be the identifier. Moreover, as noted above, Osterkamp actually does disclose multiple partitions of the token, even though this is not actually required by the claim.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 4-11, and 14-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Osterkamp (U.S. Patent 12,333,533).
Regarding Claim 1,
Osterkamp discloses a computer implemented method comprising:
Receiving, by one or more processors of a client device, user input to an icon corresponding to a software container within a central interface repository, wherein the software container corresponds to a first member platform of a network of member platforms associated with an intermediary platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; receiving user input (e.g., an application with a user interface component including a command to request tokens for a wallet), with wallet on the client device, temporary authorization file on server, account in database, all associated with the user/client as well as the server, for example);
Providing, by the one or more processors and using a member client interface and to the first member platform, a container activation request based on the user input (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; sending request to server to generate wallet/token(s), for example);
Receiving, by the one or more processors and using the member client interface and from the first member platform, a UUEK for the software container, wherein the UEEK is an external representation of an exchange identifier that is issued to the first member platform from the intermediary platform and the UUEK comprises the exchange identifier and a member partition, corresponding to the first member platform, arranged in accordance with a key format (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; receiving token(s), which is associated with the user’s account identifier and is associated therewith for later server lookup, and is also associated with the user’s credentials, such as user identifier, including the exchange identifier (e.g., the whole thing, or any portion thereof), partitions, such as facilitating server partition (e.g., first digit), rest of token, etc., as examples);
Storing, by the one or more processors, the UUEK within the software container for a temporary time period (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; storing token(s) in wallet for a time, for example); and
Providing, by the one or more processors, a message transmission that identifies the UUEK and initiates an exchange request from a receiving device associated with a second member platform of the network of member platforms, wherein the exchange request comprises the UUEK and is provided by the receiving device to the intermediary platform (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 4 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 10, lines 21-42; Column 12, lines 50-63; Column 14, lines 14-30; and associated figures; sending token to PoS and on for a transaction, for example).
Regarding Claim 11,
Claim 11 is a system claim that corresponds to method claim 1 and is rejected for the same reasons.
Regarding Claim 18,
Claim 18 is a medium claim that corresponds to method claim 1 and is rejected for the same reasons.
Regarding Claim 4,
Osterkamp discloses that the message transmission comprises a NFC message and the receiving device comprises an NFC terminal (Exemplary Citations: for example, Abstract, Column 3, line 60 to Column 4, line 9; Column 4, lines 35-51; Column 6, line 4 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 10, lines 21-42; Column 12, lines 50-63; Column 14, lines 14-30; and associated figures).
Regarding Claim 14,
Claim 14 is a system claim that corresponds to method claim 4 and is rejected for the same reasons.
Regarding Claim 5,
Osterkamp discloses that the central interface repository comprises a plurality of software containers that respectively correspond to a subset of the network of member platforms (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; multiple wallets, temporary authorization files, and the like, for example).
Regarding Claim 15,
Claim 15 is a system claim that corresponds to method claim 5 and is rejected for the same reasons.
Regarding Claim 6,
Osterkamp discloses that the container activation request is provided based on an activation status of the software container and the computer implemented method further comprises (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; status, such as whether or not the token has been used, expiration time for the token, etc., as examples):
Modifying the activation status of the software container to indicate that the UUEK is stored within the software container (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; storing expiration time, or storing token making it available for use, as examples);
Receiving a subsequent user input to the icon (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; using a token, for example); and
In response to the subsequent user input, providing the message transmission (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures).
Regarding Claim 16,
Claim 16 is a system claim that corresponds to method claim 6 and is rejected for the same reasons.
Regarding Claim 7,
Osterkamp discloses responsive to a determination that the temporary time period has lapsed (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 11, lines 29-53; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; time expired, for example):
Removing the UUEK from the software container (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 11, lines 29-53; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; expiring the token, removing the account, removing the token, etc., as examples); and
Modifying the activation status of the software container to indicate that the software container is empty (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 11, lines 29-53; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; expiring the token, removing the account, removing the token, deleting a temporary wallet, deleting a temporary authorization file, etc., as examples).
Regarding Claim 17,
Claim 17 is a system claim that corresponds to method claim 7 and is rejected for the same reasons.
Regarding Claim 8,
Osterkamp discloses that the software container is previously generated according to an initialization protocol comprising (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures):
Receiving, via an enrollment user interface overlayed to a member user interface or a central user interface, enrollment user input comprising selection data that identifies a service provider instrument of the second member platform, wherein the enrollment user input is provided directly to the intermediary platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; user requesting wallet generation for a particular account, for example);
Receiving, using the member client interface, a matching code from the second member platform, wherein the matching code originates from the intermediary platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; authenticating user, for example);
Receiving, via the enrollment user interface, a matching code input, wherein the matching code input is provided directly to the intermediary platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; authenticating user, for example); and
Generating the software container in response to a match between the matching code input and the matching code (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; generating wallet and temporary authorization file, for example).
Regarding Claim 19,
Claim 19 is a medium claim that corresponds to method claim 8 and is rejected for the same reasons.
Regarding Claim 9,
Osterkamp discloses that the icon corresponding to the software container is rendered within the central user interface and the enrollment user interface is overlayed to the central user interface in response to an initial user input to an initialization icon within the central user interface (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-49; Column 13, lines 53-67; Column 14, lines 1-13; and associated figures; command within application within phone’s UI, for example).
Regarding Claim 20,
Claim 20 is a medium claim that corresponds to method claim 9 and is rejected for the same reasons.
Regarding Claim 10,
Osterkamp discloses that the enrollment user interface is overlayed to the member user interface in response to the initial user input to the initialization icon within the member user interface and the initialization icon is rendered within the member user interface using the member client interface (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-49; Column 13, lines 53-67; Column 14, lines 1-13; and associated figures; requesting wallet as above using command in application in phone’s UI and/or authentication UI within application and phone’s UI, as examples).
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 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.
Claims 2, 3, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Osterkamp in view of RestCase (RestCase, “Internal vs External APIs”, 3/25/2017, 14 pages, retrieved from https://blog.restcase.com/internal-vs-external-apis/).
Regarding Claim 2,
Osterkamp discloses that the member client interface is an external interface that defines one or more endpoints within a software application hosted by the first member platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 10, line 43 to Column 11, line 5; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; endpoints, such as servers; identifying facilitating server or digital transactions server, as examples);
But does not explicitly disclose that the interface comprises an application programming interface.
RestCase, however, discloses that the interface comprises an external application programming interface (Exemplary Citations: for example, Pages 1-2, 5-6, 9-11, external APIs, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the APIs of RestCase into the digital wallet system of Osterkamp in order to allow for use of both public and private APIs, to increase efficiency, to speed up application development, to reduce required resources, to make interfaces accessible by a wider population, and/or to increase the production of new ideas and decrease costs.
Regarding Claim 12,
Claim 12 is a system claim that corresponds to method claim 2 and is rejected for the same reasons.
Regarding Claim 3,
Osterkamp discloses that the member client interface is an internal interface that defines one or more endpoints within a client side application corresponding to a software application hosted by the first member platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 10, line 43 to Column 11, line 5; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures).
But does not explicitly disclose that the interface comprises an application programming interface.
RestCase, however, discloses that the interface comprises an internal application programming interface (Exemplary Citations: for example, Pages 2-4, 6-9, 11-12, internal APIs, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the APIs of RestCase into the digital wallet system of Osterkamp in order to allow for use of both public and private APIs, to increase efficiency, to speed up application development, to reduce required resources, to make interfaces accessible by a wider population, and/or to increase the production of new ideas and decrease costs.
Regarding Claim 13,
Claim 13 is a system claim that corresponds to method claim 3 and is rejected for the same reasons.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeffrey D Popham whose telephone number is (571)272-7215. The examiner can normally be reached Monday through Friday 9:00-5:30.
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, Jeffrey Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jeffrey D. Popham/Primary Examiner, Art Unit 2432