Remarks
Claims 21-40 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 .
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 9/16/2026 has been entered.
Response to Arguments
Applicant's arguments filed 9/16/2026 have been fully considered but they are not persuasive.
With respect to Applicant’s allegations on pages 9 through the first full paragraph on page 10, the Examiner briefly notes that a platform does not necessarily include only one single device. Rather, multiple devices may be part of the platform. Clearly, Osterkamp discloses a first service, for example, in the acquiring bank server and a second service, for example, in the facilitating server, each part of the intermediary platform (e.g., between the user device and the digital transactions server in figure 3, for example). The claim mainly discusses communications back and forth between 2 services of an intermediary platform, which is clearly seen in figure 3 of Osterkamp. As Applicant does not yet provide any specific argument, but does provide specific arguments below, this summary is sufficient and further responses will be provided as necessary.
With respect to Applicant’s allegations in the second full paragraph on page 10, since the digital transactions server is not being taken as the intermediary platform of the claims, these allegations appear to be moot.
With respect to Applicant’s allegations in the paragraph spanning pages 10-11, the partition Applicant discusses certainly corresponds to the facilitating server, which is cited with respect to the now-claimed second service. Moreover, as discussed above, a platform may include multiple servers, such as the acquiring bank server and the facilitating server, for example.
With respect to Applicant’s allegations in the first full paragraph on page 11, the current claims appear to be directed to the intermediary platform’s functionality. Thus, arguments pertaining to a client device appear moot. No arguments appear here other than Applicant’s belief that claim 21 is directed to functionality performed by the intermediary platform. Thus, no further response is possible.
With respect to Applicant’s allegations in the paragraph spanning pages 11-12, Applicant fails to identify just where the claims prohibit users or user devices from being members or member platforms. Thus, a user device may correspond to the claimed member platform. Moreover, the member platform of the claim may include, for example, both the POS system and/or user device (as above, a platform could include multiple devices) of Osterkamp (again, see figure 3, which clearly shows the POS system prior to the acquiring bank server). With respect to Applicant’s allegations regarding the token being issued to the member platform, the Examiner notes that this is outside the scope of the claim (e.g., no actual step of the intermediary platform issuing the UUEK is provided in the claim, rather, a wherein clause is provided that defines data and does not define any method step) and also notes that the application states that the UUEKs are issued to users (e.g., paragraph 7: “Interfaces between a member platforms and the intermediary platform may allow (i) a user to present the issued UUEK…”). Thus, the member device of the claims can certainly be a user device.
In fact, claim 28 shows that the member device must be a user device, since claim 21 includes receiving the request indicative of the UUEK from the member platform and claim 28 specifies that the UUEK is received from a client device using NFC. Clearly, the member platform and the user device are the same in claim 28.
With respect to Applicant’s allegations in the first full paragraph on page 12, the Examiner notes that the primary reference, Osterkamp, already discloses member platforms, intermediary platforms, services on the intermediary platforms, and the like. All that Angara is cited for with respect to claim 21 is that the UUEK includes different partitions, which was explicitly described in the previous rejection. It appears as though Applicant is relying on Applicant’s erroneous beliefs from above (e.g., that a user device cannot be a member device and that an intermediary platform cannot include multiple servers, both of which were rebutted by the Examiner above). However, the Examiner notes that Angara shows numerous partitions within an ID and Applicant has failed to show how Applicant’s ID is novel and non-obvious. Actually, an ID cannot be patented. This would likely be a copyright or, perhaps, a trademark situation if Applicant believes Applicant’s UUEK (which is data, and not patentable) is something special. The user specific partition in Angara (e.g., member partitions may be the member’s name, such as Netflix, email.com (or either/both email and/or .com as they are each domains), city, state, zip code, anonymous user identifier, etc.) is clearly the member partition of the claim and the intermediary platform service partition may be company partition, IIN/BIN, etc. (similar to the facilitating server of Osterkamp). Moreover, the claim does not actually state that this one single UUEK includes all of these partitions (e.g., the plurality of member partitions and the plurality of services), but rather, each UUEK may include its own partition.
With respect to Applicant’s allegation “Angara therefore cannot supply the claimed member partition that ‘corresponds to a second service of the plurality of services corresponding to the member platform,’ nor can it supply the step of ‘identifying, by the first service and based at least in part on the member partition, the second service of the plurality of services that corresponds to the member platform’”. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Primary reference, Osterkamp, is cited as disclosing the following:
Regarding Claim 21,
Osterkamp discloses …
…
The member partition corresponds to a second service of the plurality of services corresponding to the 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 12, lines 22-49; Column 14, lines 1-13; and associated figures; 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);
Identifying, by the first service and based at least in part on the member partition, the second service of the plurality of services that corresponds to the 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 12, lines 22-49; Column 14, lines 1-13; and associated figures; determining who to communicate with, for example);
…
Thus, Osterkamp already discloses this subject matter and the secondary reference need not provide a duplicate disclosure.
With respect to Applicant’s allegations in the second full paragraph on page 12, Applicant is again taking an erroneous interpretation of Osterkamp (i.e., Applicant is arguing the digital transactions server as being the intermediary platform of the claim, while the rejection is relying on the acquiring bank server and facilitating server as being the intermediary platform). Osterkamp discloses providing, by the second service, an internal exchange message that identifies the exchange authorization response to the first service in Osterkamp’s disclosure of authentication confirmation, approval, etc., as examples; authentication confirmation, transaction approval, etc., as examples.
Although Applicant discusses Arnold briefly, no argument with respect to what Arnold is cited for is provided. Thus, no response is necessary or possible.
Claim Interpretation
As Applicant notes, for example, on page 8 of the response dated 4/2/2026, “The claims have been amended herein to recite the physical components (i.e., a plurality of member platforms; an intermediary platform associated with a plurality of member platforms) of the computing system as a elements outside of the preamble.” Thus, the following are considered physical components:
member platform(s)
intermediary platform(s)
processor(s)
memory(ies)
Moreover, all non-transitory computer-readable storage media are construed as being limited to statutory storage media.
The claims include subject matter that does not have any effect on the scope of the claims, such as “that is temporarily stored in a user’s virtual wallet” in the first limitation of claim 21, which is directed to “receiving … an exchange request … indicative of a … UUEK” and the intended use of temporary storage in a user’s virtual wallet does not have any effect on the scope of receiving the UUEK. This is simply an example.
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 21-40 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(s) 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.
Claim 21 states that “the intermediary platform executes a plurality of services comprising a separate service for each of the plurality of member platforms” and that “the member partition corresponds to a second service of the plurality of services corresponding to the member platform”. However, the application as originally filed does not appear to have basis for this subject matter of the member partition corresponding to a second service of a plurality of services of the member platform, where the plurality of services are separate services per member platform. Claims 31 and 39 have the same issue and are rejected for the same reasons. Claims 22-30, 32-38, and 40 are rejected at least based on their dependencies.
The application as originally filed also does not have basis for every step performed by or with this second service that does not have basis in the application as originally filed.
Claim 21 states “providing, by the second service, an internal exchange message that identifies the exchange authorization response to the first service” as the penultimate limitation. However, the application as originally filed does not appear to contain basis for this subject matter. Claims 31 and 39 have the same issue and are rejected for the same reasons. Claims 22-30, 32-38, and 40 are rejected at least based on their dependencies.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 21-40 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 21 recites the limitation "the plurality of services corresponding to the member platform" in (iv). There is insufficient antecedent basis for this limitation in the claim. Claims 31 and 39 have the same issue and are rejected for the same reasons. Claims 22-30, 32-38, and 40 are rejected at least based on their dependencies.
Claim 21 states that “the intermediary platform executes a plurality of services comprising a separate service for each of the plurality of member platforms” and that “the member partition corresponds to a second service of the plurality of services corresponding to the member platform”. However, these are mutually exclusive and cannot work together: either the services are separate for each member platform or one member platform has multiple services. It cannot be both ways. Thus, the claim is indefinite. Claims 31 and 39 have the same issue and are rejected for the same reasons. Claims 22-30, 32-38, and 40 are rejected at least based on their dependencies.
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 (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 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 21-25, 27-35, and 37-40 are rejected under 35 U.S.C. 103 as being unpatentable over Osterkamp (U.S. Patent 12,333,533) in view of Angara (U.S. Patent Application Publication 2019/0180053).
Regarding Claim 21,
Osterkamp discloses a computer implemented method comprising:
Receiving, by a first service executed by an intermediary platform associated with a plurality of member platforms and using a partner interface, an exchange request for executing a value based exchange from a partner platform of the plurality of member platforms, wherein the exchange request is indicative of a UUEK that is temporarily stored in a user’s virtual wallet (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 3; Column 10, line 21 to Column 11, line 5; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures; any device receiving a request for a transaction with a token from the user’s wallet, for example. As an example, the first service may be the acquiring bank server (which receives the request from the point of sale system which receives a request from the user device, for example) with the second service below being the facilitating server); wherein:
The intermediary platform executes a plurality of services comprising a separate service for each of the plurality 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; These separate services may be as simple as providing services, such as settlement services, pre-settlement services, authorization services, or the like, to a member, such as a PoS/user device, facilitating server, merchant server, acquiring bank server, or the like, all of which are members/member platforms, and separate services, such as anonymous token generation, 2FA, and the like, for the user, which is also a member and has a member platform (e.g., the device the user uses to access the digital transactions server), for example)
The UUEK is issued to a member platform from the intermediary platform and comprises a UUID and a member partition corresponding to the member platform that is positioned 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); and
The member partition corresponds to a second service of the plurality of services corresponding to the 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 12, lines 22-49; Column 14, lines 1-13; and associated figures; 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);
Identifying, by the first service and based at least in part on the member partition, the second service of the plurality of services that corresponds to the 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 12, lines 22-49; Column 14, lines 1-13; and associated figures; determining who to communicate with, for example);
Identifying, by the second service, an exchange identifier based at least in part on the UUEK, wherein the exchange identifier corresponds to an exchange data object stored in association with the second service and comprising an instrument identifier for a service provider instrument of the member platform (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures; token, portion of token (e.g., the first digit in the token may correspond to the facilitating server and the rest would then correspond to the account), account info, user info, etc., as examples);
Providing, by the second service and using a service provider interface, an exchange authorization request indicative of the instrument identifier to the member platform (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures; sending the token up the line for authorization, determining if enough funds, if the time is prior to expiration of the token, checking geographic area, checking other rules, etc., as examples);
Receiving, by the second service and using the service provider interface, an exchange authorization response that is indicative of at least one of an approval or a denial (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 11, lines 6-53; Column 12, line 50 to Column 13, line 30; Column 14, lines 14-30; and associated figures; response, such as authentication confirmation, transaction approval, etc., as examples);
Providing, by the second service, an internal exchange message that identifies the exchange authorization response to the first service (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 11, lines 6-53; Column 12, line 50 to Column 13, line 30; Column 14, lines 14-30; and associated figures; authentication confirmation, approval, etc., as examples; authentication confirmation, transaction approval, etc., as examples);and
Providing, by the first service and using the partner interface, an exchange response based at least in part on the exchange authorization response, wherein the exchange response is indicative of the approval or the denial (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 11, lines 6-53; Column 12, line 50 to Column 13, line 30; Column 14, lines 14-30; and associated figures; authentication confirmation, approval, etc., as examples; authentication confirmation, transaction approval, etc., as examples);
But does not appear to explicitly disclose that the member partition is one of a plurality of member partitions respectively corresponding to the plurality of member platforms and the plurality of services executed by the intermediary platform.
Angara, however, discloses that the member partition is one of a plurality of member partitions respectively corresponding to the plurality of member platforms and the plurality of services executed within the intermediary platform (Exemplary Citations: for example, Abstract, Paragraphs 31, 40, 43-47, and associated figures; member partitions may be the member’s name, such as Netflix, email.com (or either/both email and/or .com as they are each domains), city, state, zip code, company partition of a credit card number (e.g., the first number is the MMI (e.g., Visa, MasterCard, etc.), IIN/BIN (e.g., Chase Signature Visa, Bank of America Visa Gold, etc.)) included in the next few numbers, and the user’s individual number in the following numbers), as well as anonymous user identifier (e.g., 567), 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 account anonymizing techniques of Angara into the digital wallet system of Osterkamp in order to allow for anonymization of additional pieces of information, to allow for scheduled (re)anonymization of personally identifiable information, to provide for secure storage (e.g., via encryption) of anonymized values, and/or to increase security in the system.
Regarding Claim 31,
Claim 31 is a system claim that corresponds to method claim 21 and is rejected for the same reasons.
Regarding Claim 39,
Claim 39 is a medium claim that corresponds to method claim 21 and is rejected for the same reasons.
Regarding Claim 22,
Osterkamp as modified by Angara discloses the method of claim 21, in addition, Osterkamp discloses that the exchange data object comprises one or more exchange attributes that are indicative of an expiration status, and the computer implemented method further comprises validating the UUEK based at least in part on the expiration status (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; verifying time is within time before token expires, for example).
Regarding Claim 32,
Claim 32 is a system claim that corresponds to method claim 22 and is rejected for the same reasons.
Regarding Claim 23,
Osterkamp as modified by Angara discloses the method of claim 22, in addition, Osterkamp discloses modifying the expiration status to invalidate the UUEK (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).
Regarding Claim 33,
Claim 33 is a system claim that corresponds to method claim 23 and is rejected for the same reasons.
Regarding Claim 24,
Osterkamp as modified by Angara discloses the method of claim 22, in addition, Osterkamp discloses that the expiration status is based at least in part on a valid time period for the UUEK (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).
Regarding Claim 34,
Claim 34 is a system claim that corresponds to method claim 24 and is rejected for the same reasons.
Regarding Claim 25,
Osterkamp as modified by Angara discloses the method of claim 21, in addition, Osterkamp discloses that the UUEK corresponds to a UUEK representation within the user’s virtual wallet (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 3; Column 10, line 21 to Column 11, line 5; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures).
Regarding Claim 35,
Claim 35 is a system claim that corresponds to method claim 25 and is rejected for the same reasons.
Regarding Claim 27,
Osterkamp as modified by Angara discloses the method of claim 25, in addition, Osterkamp discloses that the UUEK representative comprises a virtual widget (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 3; Column 10, line 21 to Column 11, line 5; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures).
Regarding Claim 37,
Claim 37 is a system claim that corresponds to method claim 27 and is rejected for the same reasons.
Regarding Claim 28,
Osterkamp as modified by Angara discloses the method of claim 21, in addition, Osterkamp discloses that the UUEK is received from a client device using a near field communication protocol (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 38,
Claim 38 is a system claim that corresponds to method claim 28 and is rejected for the same reasons.
Regarding Claim 29,
Osterkamp as modified by Angara discloses the method of claim 21, in addition, Osterkamp discloses that the UUEK comprises a partner partition that identifies a partner platform, the instrument identifier comprises an instrument key for the member platform, and the computer implemented method further comprises (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures; token, portion of token (e.g., the first digit in the token may correspond to the facilitating server and the rest would then correspond to the account), account info, user info, etc., as examples):
Identifying a system instrument data object based at least in part on the instrument key (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures; this could be lookup of user info, or lookup of account info using user info, etc., for example); and
Generating the exchange authorization request based at least in part on the system instrument data object (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures; authorization as above based on the just described data, for example).
Regarding Claim 40,
Claim 40 is a medium claim that corresponds to method claim 29 and is rejected for the same reasons.
Regarding Claim 30,
Osterkamp as modified by Angara discloses the method of claim 21, in addition, Osterkamp discloses that the UUEK comprises a service provider partition that identifies a service provider platform and the computer implemented method comprises (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures):
Identifying the member platform based at least in part on the service provider partition (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures);
Identifying a system instrument data object based at least in part on the member platform and the exchange identifier (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures); and
Generating the exchange authorization request based at least in part on the system instrument data object (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 22; Column 10, line 21 to Column 11, line 28; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures).
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 26 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Osterkamp in view of Angara and Arnold (U.S. Patent Application Publication 2022/0076255).
Regarding Claim 26,
Osterkamp as modified by Angara discloses the method of claim 25, in addition, Osterkamp discloses that the UUEK representation comprises a machine readable representation (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 53 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 8, line 59 to Column 9, line 3; Column 10, line 21 to Column 11, line 5; Column 12, line 50 to Column 13, line 20; Column 14, lines 14-30; and associated figures);
But does not explicitly disclose that the machine readable representation comprises a machine readable optical image.
Arnold, however, discloses that the machine readable representative comprises a machine readable optical image (Exemplary Citations: for example, Paragraphs 45, 46, 59, 60, 181, 196, and associated figures; reading QR code including transaction information, 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 QR code usage techniques of Arnold into the digital wallet system of Osterkamp as modified by Angara in order to allow transaction information and tokens to be easily transferred between machines using additional techniques, to increase the extensibility of the system to users that wish to use displayed QR codes to authorize transactions, and/or to increase security in the system. Alternatively, 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 perform a simple substitution of the transfer means (e.g., mag stripe, NFC) in Osterkamp as modified by Angara with another transfer means (QR code of Arnold). Use of QR codes to transfer information between devices is ubiquitous in mobile computing devices and one of ordinary skill in the art would readily use this technique to transfer information between a mobile device and another entity.
Regarding Claim 36,
Claim 36 is a system claim that corresponds to method claim 26 and is rejected for the same reasons.
Conclusion
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
