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 .
Status of Claims
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 01/16/2026 has been entered.
Claims 1, 9, 17 and 20 being independent claims and claims 2-8, 10-16 & 18-22 are dependent claims.
Claims 1-22 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 01/16/2026, with respect to claim rejection under 35 U.S.C. § 101, see pages 2-14, have been fully considered but they are not persuasive.
With respect to Step 2A: Prong One, Applicant argues that the Examiner has overgeneralized the claims and mischaracterized what is recited, asserting that the claims are directed to a specific technological architecture involving dynamic payment card numbers and blockchain-based processing rather than an abstract idea. This argument is not persuasive.
The analysis under Prong One considers whether the claims recite a judicial exception, not whether the claims include additional technical detail. Even when considering the claim as a whole, the recited steps, such as receiving transaction details, identifying payment information (including dynamic payment details), and generating and transmitting blockchain data entries; describe the collection, analysis, and use of information to facilitate a payment transaction, which is a commercial interaction.
Applicant’s argument that the Examiner improperly focused on a generalized “what” instead of the specific “how” is unpersuasive. The additional details identified by Applicant (e.g., use of dynamic payment card numbers and multiple blockchain entries) do not change the fundamental character of the claim, which remains directed to managing payment transactions and associated data. Such activities fall within certain methods of organizing human activity, including commercial or financial interactions.
Further, Applicant’s reliant on Enfish and Ex parte Desjardins is misplaced. Those decisions relate to whether claims are directed to a specific improvement in computer functionality. However, under Prong One, the question is whether the claim recites an abstract idea. Here, the claims recite processing and organizing transaction-related information, regardless of the level of detail or the environment (e.g., blockchain) in which the steps are performed.
Accordingly, the claims recite a judicial exception.
With respect to Step 2A: Prong Two, Applicant argues that the claims integrate the judicial exception into a practical application. These arguments have been considered but are not persuasive.
a. Alleged Incorrect Standard Applied in the Office Action
Applicant contends that the Office Action improperly evaluated the claims by focusing only on “additional elements” rather than considering the claim as a whole. This argument is not persuasive.
The Office Action considered the claim as a whole and as an ordered combination, consistent with the 2019 Revised Guidance. The analysis evaluated whether the additional elements, individually and in combination, integrate the judicial exception into a practical application. The conclusion that the claims do not impose a meaningful limit on the abstract idea was based on the claim as a whole, including the recited processing server, dynamic payment details, and blockchain data entries.
Although Applicant asserts that the Examiner ignored certain limitations, the identified limitations (e.g., generating multiple blockchain entries and transmitting them) were considered and determined to represent data organization and transmission using conventional computer components, which does not integrate the exception into a practical application. For example, the claimed generation of multiple blockchain data entries and transmission to a blockchain network reflects data organization and transmission using known distributed ledger techniques, and does not impose a meaningful limit on the abstract idea.
b. Enfish/Ex parte Desjardins
Applicant argues that the claims are directed to a specific technological improvement and should be found eligible under Enfish and Ex parte Desjardins. This argument is not persuasive.
Unlike Enfish, the claims do not recite a specific improvement to a data structure or computer functionality. The use of blockchain data entries does not improve the functioning of the computer itself or any underlying data structure, but instead uses known data storage mechanisms to record transaction- related information.
Similarly, Ex parte Desjardins involved claims directed to a specific technological improvement. Here, the claims do not recite an improvement to computer or network functionality, but instead describe using generic computing components to manage and organize payment information.
c. BASCOM
Applicant argues that the claims recite a non-conventional arrangement of components, similar to BASCOM, this argument is not persuasive. In BASCOM, the claims recited a specific, non-conventional arrangement that improved network functionality. In contrast, the present claims recite a processing server, blockchain network, and transmission steps performing their ordinary and expected functions.
The alleged arrangement-separating payment information across multiple blockchain entries, amounts to organizing data into different records, which is a conventional data management technique. The claims do not recite any technical improvement arising from this arrangement, nor do they change how the underlying computer or network operates. Nor do the claims recite a non-conventional arrangement of components; rather, the recited elements are arranged to perform their expected functions in a routine sequence.
d. McRO
Applicant argues that the claims recite specific steps that improve a technological process, similar to McRO. This argument is not persuasive.
Unlike McRO, which involved specific rules that improved a technological process, the present claims do not recite particular rules or algorithms that improve computer functionality. Instead, the claims recite result-oriented steps for generating and transmitting transaction-related data. The claims do not include specific rules or algorithms that improve computer functionality. The claimed steps do not improve how the computer perform its operations, but rather use the computer as a tool to implement the abstract idea.
e. Dependent Claims
Applicant argues that the dependent claims recite additional technical features that render the claims eligible. This argument is not persuasive.
The additional limitations recited in the dependent claims, such as authorization messaging, client/server communication, network topology, access control, and inclusion of metadata; represent conventional computer functions and data handling techniques. These limitations further refine the abstract idea but do not provide a technological improvement or impose a meaningful limit on the judicial exception. Even when considered as in combination with the independent claims, these additional elements do not integrate the abstract idea into a practical application.
f. the present claims are not patent eligible under Step 2A – Prong Two.
When considered as an ordered combination, the additional elements do not integrate the judicial exception into a practical application. Accordingly, the claims do not satisfy Step 2A, Prong Two.
Applicant does not present substantive arguments specifically directed to Step 2B, asserting instead that further analysis is not required. This position is not persuasive.
Even if considered, the additional elements recited in the claims; including the processing server, dynamic payment details, blockchain data entries and data transmission to a blockchain network; are well-understood, routine, and conventional computer components and functions performing their ordinary roles of receiving, processing, storing and transmitting data.
There is no indication in the specification that these elements are anything other than well-understood, routine, and conventional. Nor does the specification indicate that these elements are implemented in any unconventional manner.
Applicant’s reliance on BASCOM is not persuasive. Unlike BASCOM, where eligibility was based on a non-conventional and non-generic arrangement of components that improved network functionality, the present claims do not recite such an arrangement. Instead, the claimed elements are arranged in a manner that implements the abstract idea using generic computer and network components, without improving their operation.
When considered individually and as an ordered combination, the additional elements do not amount to significantly more than the judicial exception. The claims therefore do not include an inventive concept sufficient to transform the nature of the claims into patent-eligible subject matter.
Applicant's arguments filed 01/16/2026, with respect to claim rejection under 35 U.S.C. § 103, see pages 14-15, have been fully considered but they are not persuasive.
Applicant argues that Johnson only generates a dynamic card number when a security issue is detected, whereas the present claims generate dynamic payment details for every transaction, and therefore Johnson does not teach or suggest the claimed limitation. This argument is not persuasive.
Johnson teaches generating temporary or dynamic transaction card number for use in a transaction in place of a permanent card number. While Johnson describes generating such a number in response to a detected security issue in certain embodiments, this condition reflects a specific use case, rather than a limitation on the underlying functionality of generating dynamic card numbers.
A person of ordinary skill in the art would have recognized that the generation of dynamic payment details can be applied more broadly, including for all transactions, as a predictable variation to enhance privacy and security. Expanding the use of dynamic card numbers from conditional use (e.g., upon detection of a security issue) to routine use for transactions represents no more than the predictable use of prior art elements according to their established functions.
Further, it would have been obvious to apply Johnson’s dynamic card number generation more broadly in view of known goals in the art, such as improving transaction security and protecting user information, which are well-recognized concerns in electronic payment systems.
Accordingly, Johnson teaches or at least renders obvious the claimed limitation of generating dynamic payment details for transactions, and the difference alleged by Applicant does not render the claims non-obvious.
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-22 are rejected under 35 USC 101 because the claimed invention is directed to an abstract idea without significantly more. The claims do fall within at least one of the four categories of patent eligible subject matter because claims 1 & 17 are directed to a process and claims 9 and 20 are directed to system; Step 1-yes.
Under Step 2A, prong 1, representative claim 1 recites a series of steps for generating and transmitting blockchain data entry including at least a transaction identifier, primary payment details, dynamic payment details, and transaction amount, which is a commercial or legal interaction, i.e. sales activities or behaviors, and thus grouped as “Certain Methods of Organizing Human Activity”. The claim as a whole and the limitations in combination recite this abstract idea. Specifically, the limitations of representative claim 1, stripped of all additional elements, recite the abstract idea as follows:
A method, comprising:
A method for establishing payment via a dynamic card number using blockchain to protect consumer privacy, comprising:
receiving transaction details for a proposed payment transaction, the transaction details including at least a transaction amount and primary payment details for a primary payment card number, wherein the primary payment details are associated with a transaction account;
identifying a transaction identifier for the proposed payment transaction and dynamic payment details for a dynamic payment card number, wherein the dynamic payment details are separate and distinct from the primary payment details;
generating a first blockchain data entry for a first blockchain including at least the transaction identifier, the primary payment details, the dynamic payment details, and the transaction amount;
generating a second blockchain data entry for a second blockchain including at least the transaction identifier, the dynamic payment details, and the transaction amount; and
transmitting at least the first blockchain data entry and the second blockchain data entry.
The claimed limitations, identified above, recite a process that, under its broadest reasonable interpretation, covers performance of a commercial or legal interaction, but for the recitation of generic computer components. There is nothing in the claim element which takes the steps out of the methods of organizing human activity abstract idea grouping. Thus, claims 1, 9, 17 and 20 recite an abstract idea.
Under step 2A, Prong 2, this judicial exception is not integrated into a practical application. In particular, the claim only recites using generic, commercially available, off-the-shelf computing devices, i.e. processors suitably programmed communicating over a generic network, to perform the steps of receiving, identifying, generating and transmitting. The additional elements (i.e. a receiver, a processor, a transmitter, processing server, blockchain node and blockchain network) are recited at a high-level of generality (i.e.as generic processors with memory suitably programmed communication information over a generic network, see at least paragraphs of the specifications) such that it amounts no more than adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses computer as a tool to perform the abstract idea, see MPEP 2106.05(f) and generally linking the use of the judicial exception to a particular technological environment or field of use, see PEPE 2106.05(h). Furthermore, the step for receiving transaction details and transmitting blockchain data are considered adding insignificant extra-solution activity to the judicial exception, see MPEP 2106.05(g). Accordingly, the additional elements claimed do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Claims 1, 9, 17 and 20 are directed to an abstract idea.
Under step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using generic computer processors with memory suitably programmed communicating over a generic network to perform the limitation steps amounts no more than adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform the abstract idea, see MPEP 2106.05(f) and generally linking the use of the judicial exception to a particular technological environment or field of use, see MPEP 2106.05 (h). Furthermore, the step for receiving transaction details and transmitting blockchain data are considered adding insignificant extra-solution activity to the judicial exception, see MPEP 2106.05(g). Mere instructions to apply an exception using generic computer components interacting in a conventional manner cannot provide an inventive concept. Claims 1, 9, 17 and 20 are not patent eligible.
Applicant has leveraged generic computing elements to perform the abstract idea of without significantly more. The dependent claims when analyzed as a whole an in an ordered combination are held to be patent ineligible under 35 USC 101 because the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional recited limitations in the dependent claims only refine the abstract idea. Further refinement of an abstract idea does not convert an abstract idea into something concrete.
The claims merely amount to the application or instructions to apply the abstract idea (i.e. a series of steps for generating and transmitting blockchain data entry including at least a transaction identifier, primary payment details, dynamic payment details, and transaction amount) on one or more computers, and are considered to amount to nothing more than requiring a generic computer system (e.g. processors suitably programmed and communicating over a network) to merely carry out the abstract idea itself. As such, the claims, when considered as a whole, are nothing more than the instruction to implement the abstract idea (i.e. a series of steps for generating and transmitting blockchain data entry including at least a transaction identifier, primary payment details, dynamic payment details, and transaction amount billing) in a particular, albeit well-understood, routine and conventional technological environment.
The dependent claims when analyzed as a whole are held to be patent ineligible under 35 U.S.C. § 101 because the dependent claims are directed to the same abstract idea as the independent claim it depends on, and the additionally recited limitations fail to establish that the claims are not directed to an abstract idea. The first blockchain network of claims 5 and 13, and the second blockchain network of claim 13, recite using a generic blockchain network for blockchain entry. All the limitations of the dependent claims further refine the abstract idea without significantly more.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself or integrate the judicial exception into a practical application.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Susan Lynch et al. (US 2021/0398093 A1, herein Lynch) in view of Johnson and in further view of LE VAN GONG.
As per claim 1, Lynch teaches a method for establishing payment via a dynamic card number using blockchain to protect consumer privacy (see Lynch ¶¶ [30, 36-37 & 62-63] where the examiner interprets the payer’s identified transaction account as the dynamic card number), comprising:
receiving, by a receiver of a processing server, transaction details for a proposed payment transaction, the transaction details including at least a transaction amount and primary payment details for a primary payment card number, wherein the primary payment details are associated with a transaction account (Lynch ¶¶ [35, 37 & 42]);
identifying, by a processor of the processing server, a transaction identifier for the proposed payment transaction and dynamic payment details […], wherein the dynamic payment details are separate and distinct from the primary payment details (Lynch ¶¶ [32, 35, 37, 43, 48 & 50]);
generating, by the processor of the processing server, a first blockchain data entry for a first blockchain including at least the transaction identifier, the primary payment details, the dynamic payment details, and the transaction amount (Lynch ¶¶ [49, 51, & 57-58]);
generating, by the processor of the processing server, a second blockchain data entry […] including at least the transaction identifier, the dynamic payment details, and the transaction amount (Lynch ¶¶ [49, 51, & 57-58]); and
transmitting, by a transmitter of the processing server, at least the first blockchain data entry and the second blockchain data entry to at least one blockchain node of at least one blockchain network (Lynch ¶¶ [26, 35, 52, 57 & 60]).
It can be argued that Lynch does not explicitly teach, however, Johnson further teaches:
identifying, by a processor of the processing server, a transaction identifier for the proposed payment transaction and dynamic payment details [for a dynamic payment card number], wherein the dynamic payment details are separate and distinct from the primary payment details (Johnson ¶¶ [54, 61, 70 & 85]);
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the method and system for payment integration with provenance supply chain events of Lynch with the security devices, systems, and methods for dynamic transaction cards of Johnson in order to provide a real time decision tool for a user to choose one or more accounts from which to withdraw currency or other funds in order to utilize a temporary card number in lieu of its permanent card number (see Johnson ¶ [54]).
It can be argued that the combination of Lynch and Johnson do not explicitly teach, however, LE VAN GONG further teaches:
generating, by the processor of the processing server, a second blockchain data entry [for a second blockchain] including at least the transaction identifier, the dynamic payment details, and the transaction amount (LE VAN GONG Fig. 2 at 130a and 130b depict a first and second blockchain network, also the pages 8, 32-33, 41 & 44-45 of the specifications disclose generating, by the processor of the processing server, a second blockchain data entry for a second blockchain including at least the transaction identifier, the dynamic payment details, and the transaction amount);
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the combination of Lynch and Johnson with the multi-party computing in a computer fragmentation environment of LE VAN GONG in order to provide a real time decision tool for a user to choose one or more accounts from which to withdraw currency or other funds in order to improve the security, protect the integrity of the account book and improve the performance of the operating blockchain (see LE VAN GONG pages 7, 30, 34 & 37-38).
As per claims 9, 17 and 20, the claims recite analogous limitations as claim 1 above and rejected under the same premise.
As per claim 2, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 1, Lynch further teaches: further comprising: receiving, by the receiver of the processing server, a transaction authorization message, wherein the first blockchain data entry and the second blockchain data entry are transmitted in response to receipt of the transaction authorization message (Lynch ¶¶ [20, 25 & 37]).
As per claims 10 & 19, the claims recite analogous limitations as claim 2 above and rejected under the same premise.
As per claim 3, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 1, Lynch further teaches: wherein the transaction details are received from a computing device, and the method further comprises: transmitting, by the transmitter of the processing server, the identified dynamic payment details to the computing device (Lynch ¶¶ [37, 44, 52-53 & 61]).
As per claim 11, the claim recites analogous limitations as claim 3 above and rejected under the same premise.
As per claim 4, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 3, Lynch further teaches: further comprising: receiving, by the receiver of the processing server, a transaction authorization message from the computing device in response to transmitting the identified dynamic payment details, wherein the first blockchain data entry and the second blockchain data entry are transmitted in response to receipt of the transaction authorization message (Lynch ¶¶ [20, 25 & 37]).
As per claim 12, the claim recites analogous limitations as claim 4 above and rejected under the same premise.
As per claim 5, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 1, Lynch further teaches: wherein the first blockchain data entry is transmitted to a first blockchain node in a first blockchain network, and the second blockchain data entry is transmitted to a second blockchain node in a second blockchain network (Lynch ¶¶ [22, 26, 28, 31, 52-53 & 57]).
As per claim 13, the claim recites analogous limitations as claim 5 above and rejected under the same premise.
As per claim 6, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 1, LE VAN GONG further teaches: wherein the first blockchain is a private blockchain, and the second blockchain is a permissioned blockchain (LE VAN GONG Fig. 7B discloses a first and second blockchain, a private blockchain and a public blockchain).
The motivation to combine the references is the same as seen above in claim 1.
As per claim 14, the claim recites analogous limitations as claim 6 above and rejected under the same premise.
As per claim 7, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 1, Lynch further teaches: wherein the first blockchain data entry and the second blockchain data entry further include a time and/or date (Lynch ¶¶ [23 & 31-32]).
As per claim 15, the claim recites analogous limitations as claim 7 above and rejected under the same premise.
As per claim 8, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 1, Lynch further teaches: further comprising: transmitting, by the transmitter of the processing server, at least the primary payment details and the dynamic payment details to an issuing financial institution associated with the transaction account (Lynch ¶¶ [29-30, 37-38, 52-53, 55 & 64]).
As per claim 16, the claim recites analogous limitations as claim 8 above and rejected under the same premise.
As per claim 18, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 17, Lynch further teaches: wherein the transaction details are received from a computing device, and the method further comprises: verifying, by the processor of the processing server, the dynamic payment details; and transmitting, by the transmitter of the processing server, an approval of the dynamic payment details to the computing device (Lynch ¶¶ [20, 22, 25, 26, 50, 57 & 61]).
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Lynch in view of Johnson in view of LE VAN GONG and in further view of Edison U. Ortiz et al. (US 2018/0293573 A1, herein Ortiz).
As per claim 21, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 1, it can be argued that the combination of Lynch, Johnson and LE VAN GONG do not explicitly teach, however, Ortiz further teaches:
wherein the dynamic payment details for the dynamic payment card number are identified from a pool of available dynamic card numbers, each dynamic card number in the pool of available dynamic card numbers having one or more usage restrictions including a predetermined period of time between each use of each dynamic card number in the pool of available dynamic card numbers (Ortiz ¶¶ [119, 164, 222, 368 & 406]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the combination of Lynch, Johnson and LE VAN GONG with the system and method for location-based token transaction processing of Ortiz in order to provide a real time decision tool for a user to choose one or more accounts from which to withdraw currency or other funds in order to enable selection by the user of payment using a virtual or electronic wallet installed on the user's request communication device. Such an option may be presented in addition to or in lieu of other types and/or method(s) of payment that may be available, and may appear in any desirable or otherwise suitable location, such as in a list of payments options (see Ortiz ¶¶ [90, 222 & 314]).
As per claim 22, the combination of Lynch, Johnson and LE VAN GONG teach the method of claim 17, it can be argued that the combination of Lynch, Johnson and LE VAN GONG do not explicitly teach, however, Ortiz further teaches:
wherein the dynamic payment details for the dynamic payment card number are user-generated, and wherein the dynamic payment details are designated for use with a specific merchant (Ortiz ¶¶ [220, 314, 322 & 441]).
The motivation to combine the references is the same as seen above in claim 21.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TONY P KANAAN whose telephone number is (571)272-2481. The examiner can normally be reached Monday- Friday 7:30am - 3:30 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matthew Gart can be reached at 5712723955. 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.
/T.P.K./Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696