DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgments
The submission (Amendment) filed on 01/30/26 is acknowledged.
Status of Claims
Claims 21-22, 25-29, 31, 33-35 and 38-41 are pending.
In the Response filed on 01/30/26, claims 21, 34 and 40 were amended, claims 23, 36 and 43-45 were cancelled, and no claims added. (Claims 24, 30, 32, 37 and 42 were cancelled in one or more previous papers.)
Claims 21-22, 25-29, 31, 33-35 and 38-41 are rejected.
Response to Arguments
Regarding the double patenting rejection
In view of the claim amendments, the rejection is withdrawn.
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
The Examiner responds as follows. In the discussion below, page numbers refer to Applicant's Response unless otherwise indicated.
Applicant argues:
I. Step 2A, Prong One
The Office Action asserts that claim 21 "covers certain methods of organizing human activity" in the form of "fundamental economic practices" or "commercial or legal interactions." This abstraction disregards the concrete, technical operations expressly required by the claim. Claim 21 does not recite a method of organizing human activity. Instead, the claim is directed to a processor-implemented, security-driven data-processing workflow, requiring:
receipt of a communication including both (i) a security element and (ii) an encrypted representation of a graphic object;
protocol compliance determination; and
conditional display of the graphic object only upon protocol compliance and user selection of a payment device.
These steps cannot be performed mentally, nor do they resemble the "economic practices" or "commercial interactions" identified in MPEP 2106.04(a)(2). Rather, they are technical data-processing operations, involving encryption, security-element handling, and protocol parsing. See Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016) (rejecting oversimplification of claims to abstract concepts).
Claim 21 focuses on a specific, security and protocol-constrained processing flow: a mobile/portable payment system receives an encrypted payload with a security element, validates a user-created graphic object against an acceptable protocol (including application identifiers, graphic-type identifiers, size and begin/end fields), and conditionally displays the graphic only upon both protocol acceptance and payment-device selection. Such concrete steps and defined data structures are integral to the improvement of the payment system, not a mere business practice. See Enfish, LLC v. Microsoft, 822 F.3d 1327 (Fed. Cir. 2016); McRO, Inc. v. Bandai, 837 F.3d 1299 (Fed. Cir. 2016); 2019 PEG and Oct. 2019 Update (requiring analysis of the claim as a whole and recognition of specific improvements in computer functionality). Accordingly, claim 21 does not recite an abstract idea. (pp. 6-7; emphasis in original)
The Examiner responds:
With the exception of "processor-implemented," all of the claimed subject matter highlighted in bold above represents part of the abstract idea. For example, the limitations pertaining to security, communication, encryption, graphic object, protocol compliance, conditional display, and payment-device selection are all part of the abstract idea. Thus, the putative "concrete steps" and "defined data structures" would reflect merely a narrowing of the abstract idea, which does not indicate a practical application, significantly more, or eligibility in any other way. As for "processor-implemented," this simply amounts to generic computer elements (e.g., processor of mobile computing device) applying the abstract idea.
As for Applicant's statement, "These steps cannot be performed mentally, nor do they resemble the "economic practices" or "commercial interactions" identified in MPEP 2106.04(a)(2).":
First, for clarification of the record, the claims were not rejected as being mental processes.
Second, the claim steps do resemble the examples in MPEP 2106.04(a)(2), e.g.:
i. mitigating settlement risk (compare claim 21, security element, encryption; "security-driven; a security element and (ii) an encrypted representation …; security; receives an encrypted payload with a security element")
ii. rules for conducting a wagering game (compare claim 21, determining whether the graphic object is formatted according to multiple acceptable protocols; "protocol compliance determination; conditional display …only upon; protocol-constrained; acceptable protocol (… application identifiers, graphic-type identifiers, size and begin/end fields), … conditionally displays … only upon … protocol acceptance")
iii. financial instruments that are designed to protect against the risk of investing in financial instruments (compare claim 21, security element, encryption; "security-driven; a security element and (ii) an encrypted representation …; security; receives an encrypted payload with a security element; payment-device")
vi. using a marking affixed to the outside of a mail object to communicate information about the mail object (compare claim 21, displaying graphic object formatted according to protocols; "display of the graphic object; displays the graphic")
vii. placing an order based on displayed market information (compare claim 21, payment-device selection in conjunction with the graphic object being formatted according to multiple acceptable protocols; "display of the graphic object; displays the graphic")
i. hedging (compare claim 21, security element, encryption; "security-driven; a security element and (ii) an encrypted representation …; security; receives an encrypted payload with a security element")
ii. mitigating settlement risk (compare claim 21, security element, encryption; "security-driven; a security element and (ii) an encrypted representation …; security; receives an encrypted payload with a security element")
i. structuring a sales force or marketing company, which pertains to marketing or sales activities or behaviors (compare claim 21, displaying graphic object corresponding to payment device, created by holder of payment device; "display of the graphic object; displays the graphic"; payment-device")
Moreover, the examples set forth in MPEP 2106.04(a)(2) are not meant to be exhaustive.
As for Applicant's statement, "See Enfish, LLC v. Microsoft, 822 F.3d 1327 (Fed. Cir. 2016); McRO, Inc. v. Bandai, 837 F.3d 1299 (Fed. Cir. 2016);": The claimed subject matter of Enfish and McRO are not analogous to the instant claims.
As for Applicant's statement, "2019 PEG and Oct. 2019 Update (requiring analysis of the claim as a whole and recognition of specific improvements in computer functionality)": the claim as a whole has been analyzed, and no improvement in computer functionality/other technology is found. The claims merely recite, at a high level of generality and without description, off-the-shelf computer elements used in their ordinary capacities.
Applicant further argues:
II. Step 2A, Prong Two
Even assuming arguendo, that claim 21 recites an abstract idea, the claim, viewed as a whole, integrates the alleged concept into a practical, technological application. The claim provides a concrete improvement in the way a mobile device securely processes user-generated graphical content by requiring:
encrypted transmission of graphical payloads;
use of a security element; and
protocol-compliance evaluation before any display.
This protocol-based validation ensures that only authenticated, properly formatted graphic objects are rendered. This is a technical improvement.
Further, the claims impose meaningful limits that apply any alleged abstraction in a mobile wallet technological context. First, an improvement to technology/computer functionality: The claims improve security and integrity of mobile wallet UI by ensuring only protocol-validated, security-vetted payment graphics are displayed in response to a verified selection. (2019 PEG; MPEP §2106.04(d).) Second, claim 21 provides a technical effect: Encrypted intake and security element, protocol validation using defined fields, and conditional rendering of the image to yield a display of the image that is conditioned to validated content and selection events. Third, claim 21 is constrained to a defined protocol, security structures, and dual-predicate gating, not any and all ways of selecting/displaying payment information. These limitations reflect integration into a practical application under MPEP §2106.04(d), the 2019 PEG, the Oct. 2019 Update, and the 2024Al SME Update (89 FR 58128)
The claim transforms an encrypted graphic object into a validated, display-ready representation only when machine-state conditions are satisfied. This is a concrete, non-abstract technical effect in the field of secure mobile computing. The encryption requirements, the mandatory security element, the protocol-validation logic, and the conditional display based on device state impose significant and meaningful limitations. For at least these reasons, claim 21 satisfies Step 2A, Prong Two and is not directed to a judicial exception. (pp. 7-8; emphasis in original)
The Examiner responds:
With the exception of "mobile wallet," all of the claimed subject matter highlighted in bold above represents part of the abstract idea. For example, the limitations pertaining to security, encryption, conditional rendering of an image, protocol compliance, graphic object, validation, and selection are all part of the abstract idea. Thus, the putative "technical improvement/effect" and "significant and meaningful limitations" would reflect merely a putative improvement to the abstract idea and a narrowing of the abstract idea, neither of which indicates a practical application, significantly more, or eligibility in any other way. As for "mobile wallet," this simply amounts to generic computer elements (e.g., processor of mobile computing device) applying the abstract idea.
Further, Applicant's own words confirm that the content of the operations of claim 21 amount to an abstract idea, and any putative improvement is an improvement in the abstract idea, not in computer functioning or technology. See Applicant's argument set forth below with emphasis revised relative to the original. The underlined portions below represent abstract idea content. (Note: while claim 21 recites displaying by a mobile device processor, it does not recite a display apparatus (e.g., user interface, screen, display, etc.) itself, rather only a "display area." In any event, such display apparatus if recited would be merely a generic computer element applying the abstract idea.)
Note also that, for clarification of the record, the Examiner submits that claim 21 does not recite or involve "machine-state conditions" or "device state." Rather, claim 21 recites "formatting [a graphic object] in an acceptable protocol," which involves conditions on the formatting of the graphic object (application used to create it; type of graphic; size of message to be received; begin and end data indicating begin and end of graphic).
Below is the re-presentation of Applicant's argument with revised emphasis:
II. Step 2A, Prong Two
Even assuming arguendo, that claim 21 recites an abstract idea, the claim, viewed as a whole, integrates the alleged concept into a practical, technological application. The claim provides a concrete improvement in the way a mobile device securely processes user-generated graphical content by requiring:
encrypted transmission of graphical payloads;
use of a security element; and
protocol-compliance evaluation before any display.
This protocol-based validation ensures that only authenticated, properly formatted graphic objects are rendered. This is a technical improvement.
Further, the claims impose meaningful limits that apply any alleged abstraction in a mobile wallet technological context. First, an improvement to technology/computer functionality: The claims improve security and integrity of mobile wallet UI by ensuring only protocol-validated, security-vetted payment graphics are displayed in response to a verified selection. (2019 PEG; MPEP §2106.04(d).) Second, claim 21 provides a technical effect: Encrypted intake and security element, protocol validation using defined fields, and conditional rendering of the image to yield a display of the image that is conditioned to validated content and selection events. Third, claim 21 is constrained to a defined protocol, security structures, and dual-predicate gating, not any and all ways of selecting/displaying payment information. These limitations reflect integration into a practical application under MPEP §2106.04(d), the 2019 PEG, the Oct. 2019 Update, and the 2024Al SME Update (89 FR 58128)
The claim transforms an encrypted graphic object into a validated, display-ready representation only when machine-state conditions are satisfied. This is a concrete, non-abstract technical effect in the field of secure mobile computing. The encryption requirements, the mandatory security element, the protocol-validation logic, and the conditional display based on device state impose significant and meaningful limitations. For at least these reasons, claim 21 satisfies Step 2A, Prong Two and is not directed to a judicial exception. (pp. 7-8; emphasis revised)
To reiterate for the sake of completeness of the Step 2A, Prong Two, analysis, no improvement in computer functionality/other technology is found in Applicant's claims. The claims merely recite, at a high level of generality and without description, off-the-shelf computer elements used in their ordinary capacities.
Applicant further argues:
III. Step 2B
Assuming in arguendo, that claim 21 were deemed to recite an abstract idea and to be directed to it, the claim still recites an inventive concept under Step 2B. The Office Action asserts, without citation, that all technical elements are "generic." Under the 2019 PEG, the October 2019 Update, and the 2024 Al SME Update, unsupported assertions cannot satisfy Step 2B. The Office Action provides no evidence that the encrypted receipt of a graphic payload, presence of a security element, processor-based protocol validation, or conditional display logic based on dual machine conditions were well-understood, routine, or conventional.
Further, claim 21 recites a specific security and protocol driven ordered sequence: receiving an encrypted graphic object containing a security element; performing protocol-compliance validation; displaying the graphic object only upon successful validation and device-selection conditions. This security-focused flow represents a non-conventional architecture, not a generic computer application of an idea. Under BASCOM Global (827 F.3d 1341), such a structured, non-generic ordered combination supplies an inventive concept. The claims recite a non-conventional ordered combination: (1) receive an encrypted payload with a security element carrying a user-created payment graphic; (2) validate the graphic against an acceptable protocol with specific identifiers/fields; and (3) display the graphic only upon both protocol pass and payment-device selection. This structured pipeline constitutes an inventive concept under BASCOM (827 F.3d 1341), even if individual components were known, because the particular arrangement and gating yields a security-integrity improvement in mobile wallet operation. Accordingly, the claim provides an inventive concept and satisfies Step 2B.
Furthermore, consistent with USPTO Example 47 (Al SME Update, July 17, 2024). The claims parallel Example 47, Claim 3, where eligibility turned on applying analysis to a technical security improvement (improving network security). Here, the claim likewise applies processing to a device-security function: the mobile/portable payment system (i) receives an encrypted communication with a security element, (ii) performs protocol compliance validation (with defined identifiers/fields), and (iii) a payment graphic is rendered only when both protocol validation and payment selection are accomplished. This security-constrained, protocol-driven control of the device UI is a practical application (MPEP §2106.04(d)), not a mere organization of human activity. As in Example 47, this integration supports Step 2A (Prong Two) and, alternatively, provides "significantly more" at Step 2B via the ordered combination of encryption and security element to protocol validation to conditional display of the graphic. (pp. 8-9; emphasis in original)
The Examiner responds:
In respect of Step 2B, Applicant calls out generally the same claimed content as Applicant cited with respect to Step 2A, Prongs One and Two, above, arguing here that this content amounts to "an inventive concept" or "significantly more" under Step 2B. Specifically, Applicant asserts this content is not well-understood, routine or conventional, and that this content is analogous to Example 47, claim 3, of the USPTO's subject matter eligibility guidance.
As has already been explained in respect of Step 2A, Prongs One and Two, above, the claimed content in question amounts merely to an abstract idea applied using generic computer elements. As such, Applicant is effectively arguing that the abstract idea is not well-understood, routine or conventional (e.g., "The claims recite a non-conventional ordered combination: (1) receive an encrypted payload with a security element carrying a user-created payment graphic; (2) validate the graphic against an acceptable protocol with specific identifiers/fields; and (3) display the graphic only upon both protocol pass and payment-device selection."). However, eligibility under step 2B turns on "whether the additional elements contribute an 'inventive concept'. MPEP 2106.05.II. "An inventive concept 'cannot be furnished by the unpatentable law of nature (or natural phenomenon or abstract idea) itself." MPEP 2106.05.I. Therefore, even assuming arguendo that the abstract idea of claim 21 is not well-understood, routine or conventional, this would not indicate eligibility under Step 2B or in any other way.
Furthermore, the claims were not rejected as being well-understood, routine and conventional. Rather, the claims were rejected under Step 2B because, when the additional elements are included in the consideration of the claims as a combination, they are merely generic computer elements recited at a high level of generality, that are used to apply the abstract idea. However, "adding the words 'apply it' (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer" and "generally linking the use of the judicial exception to a particular technological environment or field of use" are "[l]imitations that the courts have found not to be enough to qualify as 'significantly more' when recited in a claim with a judicial exception." MPEP 2106.05. (Eligibility Step 2B: Whether a Claim Amounts to Significantly More), I. (THE SEARCH FOR AN INVENTIVE CONCEPT), A.(Relevant Considerations For Evaluating Whether Additional Elements Amount To An Inventive Concept).
As for Example 47, claim 3 was found eligible based on finding that “the additional elements of “(d) detecting a source address associated with the one or more malicious network packets,” “(e) dropping the one or more malicious network packets,” and “(f) blocking future traffic from the source address” “improved network security” and thus “reflects [an] improvement in the technical field of network intrusion detection.” July 2024 Subject Matter Eligibility Examples, p. 12. These additional elements are not comparable to Applicants’ additional elements (indicated above, e.g., processor of a mobile device), and this improvement/technical field is not comparable to Applicant’s
personalizing (in a secure manner) a payment device by means of a graphic object that is created by the user and that complies with a protocol. Accordingly, Applicant’s putative analogy between the instant claims and Example 47 is not persuasive.
Regarding the rejections under 35 U.S.C. 103
Applicant's arguments have been fully considered but are not persuasive or are moot in view of the new combination of prior art references currently being used in the rejection of the independent claims, including additional portions of the previously applied prior art.
Note the limitations added to independent claims 21, 34 and 40 by the instant amendments were, in significant part, previously recited in former claims 23, 36, and 43-45, which were cancelled in the instant Response. As such, the instant amendments to independent claims 21, 34 and 40 are taught, in significant part, by the prior art cited against dependent claims 23, 36, and 43-45 in the previous Office Action.
Regarding Applicant's argument:
At page 10, Applicant argues that Kunz does not teach "whether the graphic is formatted according to a protocol" but rather merely "determines which art is available for selection." Response, p. 10. In response, the Examiner points out that Applicant's reading of Kunz is selective. Applicant omits that Kunz explicitly explains that the determination of what art is available for selection follows directly from "payment instrument art guidelines." Kunz, 0057. These guidelines teach Applicant's recited "protocol." As such, Kunz teaches the limitation in question, viz., "determining whether the graphic object is formatted in in an acceptable protocol."
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 21-22, 25-29, 31, 33-35 and 38-41 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 21-22, 25-29, 31, 33-35 and 38-41 are directed to a method or a system, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 21, 34 and 40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method and system for personalizing (in a secure manner) a payment device by means of a graphic object that is created by the user and that complies with a protocol. For claims 21, 34 and 40 (claim 21 being deemed representative), the limitations (indicated below in bold) of:
receiving, by the processor of the portable computer payment system, a communication comprising a security element and a representation of a graphic object corresponding to a payment device wherein the graphic object is created by a holder of the payment device, wherein the graphic object is communicated through the communication using encryption, wherein the security element comprises an electronic token that encloses the representation of the graphic object, wherein the graphic object is formatted according to a protocol;
determining using logic on the processor whether the graphic object is formatted in an acceptable protocol, wherein the acceptable protocol includes an application identifier to identify an application used to create the graphic object, a graphic type identifier to identity the type of graphic, a size field indicating the size of message to be received, begin data indicating a start of the graphic, and end data to identify an end of the graphic; and
in response to determining that the graphic object is formatted in the acceptable protocol and in response to receiving a selection of the payment device corresponding to payment device data,
displaying, by the processor of the portable computer payment system, the graphic object in a display area.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components. The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 21, 34 and 40 recite an abstract idea. (Step 2A - Prong 1: YES. The claims recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 21, 34 and 40 recite the additional elements of a processor of a mobile computing device and electronic (claim 21); a processor, a memory, a display, and an input output circuit, the processor being physically configured for: and electronic (claim 34); and a processor and a memory, wherein the memory stores instructions executable by the processor to cause the processor to: and electronic (claim 40) that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions), such that they amount to no more than mere instructions to apply the exception using generic computer elements. Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a processor of a mobile computing device and electronic (claim 21); a processor, a memory, a display, and an input output circuit, the processor being physically configured for: and electronic (claim 34); and a processor and a memory, wherein the memory stores instructions executable by the processor to cause the processor to: and electronic (claim 40), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements. Mere instructions to apply an exception using generic computer elements cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 21, 34 and 40 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 22, 25-29, 31, 33, 35, 38-39 and 41 are similarly rejected because they further define/narrow the abstract idea of independent claims 21, 34 and 40 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Claims 22 and 35 merely describe wherein the graphic object comprises text.
Claim 25 merely describes creating the graphic object.
Claim 27 merely describes the graphic object comprises data.
Claims 28 and 39 merely describe pulling data … to create the graphic object.
Claim 29 merely describes wherein receiving the graphic object includes receiving the graphic object from input.
Claim 31 merely describes wherein displaying the graphic object includes displaying the graphic object in response to receiving selection of a payment account for the payment device.
Claim 33 merely describes wherein the graphic object is communicated.
Claim 35 merely describes wherein the graphic object comprises at least one of: text, graphics ….
Claim 38 merely describes creating the graphic object.
Claim 41 merely describes creating the graphic object.
As for additional elements:
Claim 25 recites “wherein an application on the mobile computing device." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 26 recites “wherein the application is in communication with other applications on the mobile computing device." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 27 recites “other applications on the mobile computing device." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 28 and 39 recite “wherein the application [pulls data from] other applications." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 29 recites “a digital wallet application at the mobile computing device." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 31 recites "a digital wallet application executing at the mobile computing device." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 33 recites "a portable payment device using wireless communication." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 35 recites "videos." This recitation is at a high level of generality such that it amounts to no more than generally linking the use of a judicial exception to a particular technological environment or field of use. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 38 recites "an application on a mobile computing device … is in communication with other applications on the portable computer payment system." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 41 recites “an application." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 22 does not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 22, 25-29, 31, 33, 35, 38-39 and 41 are not patent eligible.
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 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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 21, 22, 25-29, 31, 33-35 and 38-41 are rejected under 35 U.S.C. 103 as being unpatentable over Kunz et al. (U.S. Patent Application Publication No. 2014/0040125 A1), hereafter Kunz, in view of Read et al. (U.S. Patent Application Publication No. 2015/0371201A1 A1), hereafter Read, further in view of Tushie et al. (U.S. Patent Application Publication No. 2003/0050899 A1), hereafter Tushie, further in view of Mathew (U.S. Patent Application Publication No. 2014/0300556 A1), and further in view of Banin et al. (WO 2019/055894 A1), hereafter Banin.
Regarding Claims 21, 34 and 40
Kunz teaches:
receiving, by a processor of a mobile computing device (portable computer payment system) (user device 110), a communication comprising … a representation of a graphic object corresponding to a payment device (0065-0066, Fig. 3, 315-320 per 0066 user submits customized art to proxy card application 115 on user device 110 (this will be referred to as scenario 1); alternatively, 0063-0064, Fig. 3, 310 options for art are presented to user via proxy card application 115 on user device 110, see also 0057, 0059, image files of available art provided to user device 110 (this will be referred to as scenario 2);
wherein the graphic object is created by the holder of the payment device; (0024, 0065-0066, Fig. 3, 315-320 customized art indicates the user customizes -- creates the art; alternatively, 0024, 0063-0064 user’s selection of art is deemed to teach creation, e.g., user may select and combine different elements such as colors, words, placement, font)
…
wherein the graphic object is formatted according to a protocol (The following applies to scenario 1, where the user directly creates the art, see “receiving” step, above: Fig. 3, 325, 0067 proxy card system 140 receives verification of selected art from the user (i.e., from the user device), i.e., determines that the user verifies the representation of the user-selected art (determines that the user confirms that the representation is acceptable) – if the representation of the art is acceptable, this indicates that the art is formatted in an acceptable protocol. The following applies to scenario 2, where the user selects the art, see “receiving” step, above: Fig. 2, 220, Fig. 3, 305, 0056-0057 proxy card system 140 accesses guidelines (protocol) to determine appropriate art depending on various factors, see also 0023, 0061-0062 and receives the appropriate art (electronic image files thereof) from payment instrument system 170, also 0059, 310 proxy card system 140 may query payment instrument system 170 to determine/ obtain appropriate art.)
determining, using logic in the processor, whether the graphic object is formatted in an acceptable protocol; and (The following applies to scenario 1, where the user directly creates the art, see “receiving” step, above: Fig. 3, 325, 0067 proxy card system 140 receives verification of selected art from the user (i.e., from the user device), i.e., determines that the user verifies the representation of the user-selected art (determines that the user confirms that the representation is acceptable) – if the representation of the art is acceptable, this indicates that the art is formatted in an acceptable protocol. Note since proxy card system 140 receives verification from the user device, the determination is performed by both proxy card system 140 and the user device, i.e., the determination uses logic in the processor of the mobile computing device. The following applies to scenario 2, where the user selects the art, see “receiving” step, above: Fig. 2, 220, Fig. 3, 305, 0056-0057 proxy card system 140 accesses guidelines (protocol) to determine appropriate art depending on various factors, see also 0023, 0061-0062 and receives the appropriate art (electronic image files thereof) from payment instrument system 170, also 0059, 310 proxy card system 140 may query payment instrument system 170 to determine/ obtain appropriate art. Note: although systems 140, 170 are indicated as performing the determining, 0104-0105 provides that the determining could instead be performed by user device 110 as an equivalent component (note per 0091-0092 computing machine 2000 corresponds to any of the various computers, etc. disclosed in Kunz, e.g., either user device 110 or systems 140 or 170; therefore, user device 110 may be equivalent to systems 140 or 170))
…
in response to determining that the graphic object is formatted in the acceptable protocol, and in response to receiving a selection of the payment device corresponding to payment device data, displaying, by the processor of the mobile computing device (portable computer payment system), the graphic object in a display area. (The following applies to scenario 1, where the user directly creates the art, see “receiving” step, above: Fig. 3, 325, 0067 in response to receiving the verification (determining that graphic object is formatted in acceptable protocol), the graphic object (representation of how the instrument will appear) is provided to user device 110 via application 115 or via website. The following applies to scenario 2, where the user selects the art, see “receiving” step, above: in response to Fig. 2, 220, (determining that graphic object is formatted in acceptable protocol), the art is displayed on user device 110 as per 0069, 225 (proxy card system 140 stores the (verified) art on server, transmits art to user device 110, etc., for display on user device) and 0075-0078, 245 (the art is displayed on user device 110); regarding and in response to receiving a selection of the payment device corresponding to payment device data: 0075 "In block 245, the proxy card application 115 on a user device 110 can display to the user 101 the payment instrument that is selected to conduct the transaction." ; 0078 "In an alternate example embodiment the blocks 240, 245, and block 250 can be conducted in any order. For example, the user 101 can select a payment instrument before initiating a transaction. In another example, the user 101 selects the payment instrument from a list and the associated art is not displayed until after a selection is made. The steps can be conducted in any other suitable order."; 0077 "In block 250, the user 101 selects the payment instrument for use in the transaction. … After a selection is made by the user 101, the selected payment instrument and the associated art can be displayed on the user device 110."; 0025 "The art can be displayed on the user device while the user is choosing a payment instrument for a proxy card or other transaction before, during, or after the transaction with the merchant. Additionally or alternatively, the art can be displayed to indicate to the user which card is being used for a particular transaction." (see 0072 "The user 101 may choose one financial account to be the active account and the selected financial account can become the backing instrument for the proxy card."); regarding corresponding to payment device data: 0046 "The user 101 associates one or more registered financial card accounts, … with a payment account of the user 101. The proxy card system 140 also may function as the issuer for the associated financial payment instrument." -- i.e., payment instrument (payment device) is associated with (corresponds to) card account (payment device data); 0075 "In block 245, the proxy card application 115 on a user device 110 can display to the user 101 the payment instrument that is selected to conduct the transaction. The selection by the proxy card application 115 can be based on rules established by the user 101 during configuration. For example, the proxy card rules can select a payment instrument based on the location of the user device 110, …." -- i.e., payment instrument (payment device) is associated with (corresponds to) location of the user device (payment device data))
(claim 34) a processor (e.g., 2010), a memory (e.g., 2030), a display (e.g., 0098), and an input output circuit (e.g., 2060), the processor being physically configured for: (0091-0098, Fig. 7)
(claim 40) a processor and a memory, wherein the memory stores instructions executable by the processor to cause the processor to: (0091-0096, Fig. 7)
Kunz does not explicitly disclose the following limitations in their entirety but Read teaches:
… a communication comprising a security element (wrapping) and a representation of a graphic object …; (0012, 0016, 0060, 0063, 0067, 0069, 0104, 0277-0278 in a payment context, a communication includes image/graphical content wrapped in a wrapping (security element) such that the graphical content is hidden so as to restrict access to only the second party (receiving party) in order to improve privacy and security)
wherein the graphic object is communicated through the communication using encryption; (0041)
wherein the security element comprises an electronic token that encloses the representation of the graphic object, (0060, 0063, 0067, 0069, 0104, 0277-0278 under broadest reasonable interpretation the wrapping comprises an electronic token that encloses the representation of the graphic object; see also 0012, 0016 re security purpose of wrapping)
wherein the acceptable protocol includes … a size field indicating the size of message to be received (0201, 0218, 0259)
Regarding the security-related and encryption-related limitations, it would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Kunz’s systems and methods for displaying payment instrument art, by incorporation therein of Read's teachings regarding a security element (wrapping) and encryption in the communication of image/graphical content, because it would provide increased security. See Read, 0012, MPEP 2143.I.G.
Regarding the limitation relating to size as one of the protocols, it would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Kunz’s systems and methods for displaying payment instrument art, by incorporation therein of Read's teachings regarding a size limit with respect to the communication of images, in order to comply with bandwidth limitations (or conserve bandwidth) for communications, or to mitigate transmission delays that would be incurred by transmitting files having a large size. MPEP 2143.I.G.
Kunz in view of Read does not explicitly disclose but Tushie teaches:
wherein the acceptable protocol includes an application identifier to identify an application used to create the graphic object, (0011, 0015 "application program identifier" (application identifier) is used to create personalization, which per 0005 may include "graphic representation” (graphic object). Specifically, the application program identifier is used as per 0011 to "acquire commands" and "application data" to carry out the personalization, and as per 0015 to "determine which type(s) of application program is to be placed on the card" so that the "the specified application code and variables [can be acquired]." As per 0011, the application program identifier (application identifier) is included in the protocol, which is indicated by the bolded portion as follows: "The smart card personalization system issues portable programmed data carriers, or smart cards, by first acquiring a data format identifier, a card operating system identifier, a personalization equipment identifier, an application program identifier or identifiers, and personalization data for a cardholder from a card issuer management system. The identifiers permit the system to address data stored in a data structure, such as a database, and specify the particular data needed by the system for each card to be issued. Because each card issuer formats its personalization data differently and may have multiple data formats, the smart card personalization system has a database of data format templates that enable it to interface with multiple card issuer management systems.)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Kunz’s systems and methods for displaying payment instrument art, as modified by Read's teachings regarding a security element (wrapping) and encryption in the communication of image/graphical content and regarding a size limit with respect to the communication of images, by incorporation therein of Tushie's teachings regarding an application identifier as part of the protocol, because it facilitates creation of the graphic object on the card by streamlining the identification of / the directing to data/commands necessary to create the graphic object on the card. See Tushie, 0011, 0015.
Kunz in view of Read and Tushie does not explicitly disclose but Mathew teaches:
wherein the acceptable protocol includes … a graphic type identifier to identity the type of graphic, (0029-0030, Fig. 3, image rule (protocol) is associated with (includes) image identifier (graphic type identifier that identifies a type of graphic object); see also 0039, Fig. 12)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Kunz’s systems and methods for displaying payment instrument art, as modified by Read's teachings regarding a security element (wrapping) and encryption in the communication of image/graphical content and regarding a size limit with respect to the communication of images, and as further modified by Tushie's teachings regarding an application identifier as part of the protocol, by incorporation therein of Mathew's teachings regarding a graphic type identifier as part of the protocol, because it facilitates creation of the graphic object on the card by streamlining the identification of / the directing to the graphic object to be presented on the card. See Mathew, 0029-0030, 0039, Figs. 3, 12.
Kunz in view of Read, Tushie and Mathew does not explicitly disclose but Banin teaches:
wherein the acceptable protocol includes … begin data indicating a start of the graphic, and end data to identify an end of the graphic (Fig. 13j, 137:25-33 "The processing circuit 1350 is configured to generate the data signal 1341 to represent a sequence of a first control symbol 1342 (plus a control symbol indicator) of a communication protocol (e.g. the STEP protocol) that indicates a start of a data packet of the first priority, a first portion of the first data packet 1343-1 that comprises at least one payload data symbol, a second control symbol 1344 (plus a control symbol indicator) of the communication protocol that indicates a start of a data packet of the second priority, the second data packet 1345, a third control symbol 1346 (plus a control symbol indicator) of the communication protocol that indicates an end of the data packet of the second priority, and a second portion of the first data packet 1343-2 that comprises at least one payload data symbol.")
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Kunz’s systems and methods for displaying payment instrument art, as modified by Read's teachings regarding a security element (wrapping) and encryption in the communication of image/graphical content and regarding a size limit with respect to the communication of images, as further modified by Tushie's teachings regarding an application identifier as part of the protocol, and as further modified by Mathew's teachings regarding a graphic type identifier as part of the protocol, by incorporation therein of Banin's teachings regarding a protocol including a control signal comprising begin data indicating a start to the communication and a control signal comprising end data indicating an end to the communication, because it facilitates communication by synchronizing the sender and the receiver and delimiting the payload (i.e., identifying the substantive content of the communication signal that is what is intended to be communicated), which is especially critical in asynchronous communication where there is no clock signal to keep sender and receiver in sync, e.g., the begin data control signal serves to wake up the receiver to set its clock to read the upcoming payload data and the end data control signal informs the receiver that receipt of the payload data is complete and thereby prevents the receiver from misinterpreting the next incoming data byte as a continuation of the previously received data byte (in other words, from misinterpreting the subsequent data as part of the previously received payload data).
Regarding Claims 22 and 35
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claims 21 and 34 as set forth above. Kunz further teaches:
(claim 22) wherein the graphic object comprises text. (0024, 0063, 0065-0066)
(claim 35) wherein the graphic object comprises at least one of: text, graphics or videos. (0024, 0063, 0065-0066)
Regarding Claim 25
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claims 21 as set forth above. Kunz further teaches:
wherein an application (e.g., communication application 112 such as web browser) on a mobile computing device creates the graphic object. (0035, 0041 communication application 112 such as web browser (by virtue of what a web browser does – see Raghuwanshi “How does web browsers work” (sic) cited on attached PTO-892 Notice of References Cited) renders / displays / generates the art on the user device screen (creates the graphic object); alternatively, 0057 the displaying of the art “comprises rendering the corresponding electronic image file (creating the graphic object) on the user network device 110”; as such, the displaying is performed by software, i.e. an application, executing on the device; alternatively, 0075-0078 proxy card application 115 displays art on user device 110 (creates the graphic object); alternatively, 0063-0064 proxy card application 115 is used to create the art by the user selecting components to be combined to create the art)
Regarding Claim 26
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claim 21 and intervening claim 25 as set forth above. Kunz further teaches:
wherein the application (e.g., 112 or 115) is in communication with other applications (e.g., 111, 115 or 111, 112) on the mobile computing device. (per 0037-0038 communication application 112 is in communication with digital wallet application 111 and proxy card application 115, and 115 is in communication with 112 and 111 when embedded in 112)
Regarding Claim 27
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claim 21 and intervening claims 25-26 as set forth above. Kunz further teaches:
wherein the graphic object comprises data from other applications on the mobile computing device. (0039 the art selected (0063-0064) / created (0065-0066) by user is received by proxy card application 115 (data from other applications), for rendering / displaying by communication application 112 / web browser; note 0037-0038 proxy card application 115 may be embedded in digital wallet application 111, hence the proxy card application 115 is deemed to be multiple applications, such that the art comprises data from multiple other applications)
Regarding Claims 28 and 39
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claims 21 and 34 and intervening claims 25-27 (as set forth above) and 38 (as set forth below). Kunz further teaches:
wherein the application (communication application 112 such as web browser) pulls data from other applications (proxy card application 115) to create the graphic object. (0035, 0041 communication application 112 such as web browser renders / displays / generates the art on the user device screen (creates the graphic object) (by virtue of what a web browser does – see Raghuwanshi “How does web browsers work” (sic) cited on attached PTO-892 Notice of References Cited), while 0039 proxy card application 115 receives the art selected (0063-0064) / created (0065-0066) by user, therefore communication application 112 / web browser has obtained (pulled) the art from the proxy card application 115 (other applications) to create the graphic object; note 0037-0038 proxy card application 115 may be embedded in digital wallet application 111, hence the proxy card application 115 is deemed to be multiple applications, such that the art has been obtained from multiple other applications)
Regarding Claim 29
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claim 21 and intervening claim 22 as set forth above. Kunz further teaches:
wherein receiving the graphic object includes receiving the graphic object from input of a digital wallet application at the mobile computing device. (Further to the "receiving" step (first step) of claims 21, 24 and 40: The following applies to scenario 1: 0066 user submits customized art to proxy card application 115 on user device 110; 0038 note proxy card application 115 may be embodied as companion to and execute within (per 0037 in other words may be embedded in) digital wallet application 111; therefore, the art is the input of a digital wallet application, and the processor of the user device 110 receives the art from this input. The following applies to scenario 2: 0063-0064 options for art (for user selection) are presented to user on user device 110 via proxy card application 115, as per 0039 user selects options via (user input to) proxy card application 115 (and as above per 0037-0038 proxy card application 115 may be embedded in digital wallet application 111), so again the user selected/combined art is the input of a digital wallet application, and the processor of the user device 110 receives the art from this input.)
Regarding Claim 31
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claim 21 as set forth above. Kunz further teaches:
wherein displaying the graphic object includes displaying the graphic object in response to receiving selection of a payment account for the payment device at a digital wallet application executing at the mobile computing device. (0075, 0077, 0078, Fig. 2, 245, 250, art associated with selected payment instrument is displayed after user selects the payment instrument (0075, 0077, 0078) and after user selects account (0072 or 210, 215, 0053-0054), hence in response to receiving selection of a payment account for the payment device; regarding selection of account as taught by Fig. 2, 210, 215, 0053-0054, note this occurs via digital wallet application 111 (0053) or proxy card application 115 (0053) which per 0038, 0037 is part of digital wallet application 111; also per 0039, in general the selection of an account occurs via proxy card application 115 which, per 0038, 0037, is part of digital wallet application 111)
Regarding Claim 33
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claim 21 and intervening claim 31 as set forth above. Kunz further teaches:
wherein the graphic object is communicated to the portable payment device using wireless communication. (Further to the "displaying" step (last step) of claims 21, 24 and 40: The following applies to scenario 1: 0067, 325, the art is provided from proxy card system 140 to user device 110 via application 115 or via website -- in either case, this is using wireless communication as, per Fig. 1, 0032-0036, 0041, the route from proxy card system 140 to user device 110 is via network 105. The following applies to scenario 2: the display of the art on user device 110 as per 0075-0078 is carried out by a preceding transmission of the art to the user device 110 from the proxy card system 140 or from another "suitable computing system" as per 0069; likewise here such transmission is using wireless communication as, per Fig. 1, 0032-0036, 0041, the route from proxy card system 140 (or other computing systems) to user device 110 is via network 105.)
Regarding Claim 38
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claim 34 as set forth above. Kunz further teaches:
wherein an application (e.g., communication application 112 such as web browser, or proxy card application 115) on a mobile computing device creates the graphic object and (0035, 0041 communication application 112 such as web browser renders / displays / generates the art on the user device screen (creates the graphic object) (112 does this by virtue of what a web browser does – see Raghuwanshi “How does web browsers work” (sic) cited on attached PTO-892 Notice of References Cited); alternatively, 0057 the displaying of the art “comprises rendering the corresponding electronic image file (creating the graphic object) on the user network device 110”; as such, the displaying is performed by software, i.e. an application, executing on the device; alternatively, 0075-0078 proxy card application 115 displays art on user device 110 (creates the graphic object); alternatively, 0063-0064 proxy card application 115 is used to create the art by the user selecting components to be combined to create the art)
is in communication with other applications (e.g., 111, 115 or 111, 112) on the portable computer payment system. (per 0037-0038 communication application 112 is in communication with digital wallet application 111 and proxy card application 115, and 115 is in communication with 112 and 111 when embedded in 112)
Regarding Claim 41
Kunz in view of Read, Tushie, Mathew and Banin teaches the limitations of base claim 40 as set forth above. Kunz further teaches:
comprising an application (e.g., communication application 112 such as web browser, or proxy card application 115) to create the graphic object. (0035, 0041 communication application 112 such as web browser renders / displays / generates the art on the user device screen (creates the graphic object) (112 does this by virtue of what a web browser does – see Raghuwanshi “How does web browsers work” (sic) cited on attached PTO-892 Notice of References Cited); alternatively, 0057 the displaying of the art “comprises rendering the corresponding electronic image file (creating the graphic object) on the user network device 110”; as such, the displaying is performed by software, i.e. an application, executing on the device; alternatively, 0075-0078 proxy card application 115 displays art on user device 110 (creates the graphic object); alternatively, 0063-0064 proxy card application 115 is used to create the art by the user selecting components to be combined to create the art)
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure.
Jong (US-20040143551-A1) teaches inter alia the APDU protocol (International Standard ISO/IEC 7816-3) limits the size of the payload or data field to a small number of bytes (typically less than 128) determined by the restricted size of RAM, see 0009, 0014.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571)272-4131. The examiner can normally be reached on 8:30 am – 5:30 pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jessica Lemieux can be reached on 571-270-3445. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR.
Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DOUGLAS W. PINSKY/ /JESSICA LEMIEUX/Examiner, Art Unit 3626 Supervisory Patent Examiner, Art Unit 3626