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 .
Preliminary Amendment
All pending claims 1-12 filed December 1, 2025 are examined in this final office action necessitated by amendment.
Response to Amendment
All pending claims 1-12 filed December 1, 2025 are examined in this final office action necessitated by amendment.
Response to Arguments
Applicant's arguments filed remarks filed December 1, 2025 have been fully considered but they are not persuasive. Please refer to Attachment A which illustrates Applicant’s Fig. 2. As disclosed in Applicant’s specification, the first supplier is defined to be SUP and the second supplier is defined to be SUPSUP (supplier’s supplier). Chain A as drawn by the undersigned examiner comprises SUPSUP (second supplier) [Wingdings font/0xE0] SUP (first supplier) [Wingdings font/0xE0] ENT. Attachment B illustrates Kerschbaum Fig. 1 that likewise illustrates Chain A. Chain A as drawn by the undersigned examiner comprises supplier A (SUPSUP) [Wingdings font/0xE0] B (SUP) [Wingdings font/0xE0] C (ENT). By definition B is the first supplier and A is the second supplier. Therefore the second supplier (A/SUPSUP) supplies the first supplier (B/SUP) and the first supplier (B/SUP) supplies the C(ENT).
As illustrated in Kerschbaum, the second supplier (A) passes security datum to the first supplier (B) who in turns passes security datum to entity C.
The undersigned examiner is suggesting a telephonic interview for further assessment of the claims. Although there is no guarantee of reaching agreement on an allowance during the interview, it seems worthwhile to explore subject matter not yet examined that may help overcome rejections on the merits and subject matter eligibility.
Claim Rejections - 35 USC § 102
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 4-8 and 10 are rejected under 35 USC 102(a)(1) as being anticipated by Kerschbaum, US 2010/0329464.
Kerschbaum teaches all the limitations of claims 1, 4-8 and 10. In Kerschbaum see at least (underlined text is for emphasis):
Regarding claim 1: A method for enhancing security of a product using a supply chain of suppliers for manufacturing or producing the product, the method comprising:
[Kerschbaum: 0003] Implementations of present disclosure include methods for implementing visibility policies within a supply chain that includes a plurality of partners. In some implementations, such a method includes storing event data on a computer-readable storage medium of a first partner, the event data corresponding to at least one event associated with an item while the item was in possession of the first partner, the item having traveled through the supply chain, transferring evidence of possession between the plurality of partners as the item travels through the supply chain, and requesting access to the event data by a second partner. The method further includes determining that the item traveled through a portion of the supply chain associated with at least the first partner and the second partner, based on the evidence, authenticating an identity of the second partner, and authorizing the second partner to access the first event data from the computer-readable storage medium, when it is determined that the item traveled through the portion of the supply chain and when the identity of the second party is authenticated.
[Kerschbaum: 0004] In some implementations, the method further provide that the evidence includes proofs of possession corresponding to the second partner and any intermediate partners between the first partner and the second partner along the portion of the supply chain.
[Kerschbaum: 0005] In some implementations, the method further provides that determining whether the portion of the supply chain is valid is further based on chaining tokens that are generated by each of the first and second partners, and any intermediate partners between the first partner and the second partner along the portion of the supply chain.
consulting a security information dataset (TWP) including …
[Kerschbaum: 0024] FIG. 1 is a block diagram of an exemplar supply chain 100. In general, the supply chain 100 represents a system of organizations, people, technology, activities, information, and/or resources involved in moving information, products, and/or services between supply chain parties. For example, the supply chain 100 can enable data sharing between (i) a supplier and a customer, (ii) a supplier and another supplier, and/or (iii) a customer and another customer. The suppliers and customers can increase efficiency in providing and/or receiving services by analyzing shared data available upstream and downstream within a particular supply chain. In particular, access to this data allows new forms of analytics improving the efficiency of the supply chain.
[Kerschbaum: 0027] Supply chain visibility policies can include requirements such as providing evidence in the form of a proof of possession of an item at some point in the supply chain of the item. The proof of possession can be verified by a third party to convince the third party that the presenter of the proof actually had possession of the item at some point in time. In some implementations, the evidence may be stored on a radio frequency identification (RFID) tag (t). The RFID tags may each have a unique identifier that can be read by a business partner each time a tagged item (I.sub.t) is handled within a supply chain. Each time the item (I.sub.1) is handled, an event is stored on the tag (t). Event data may relate to, but is not limited to, unpacking items, shipping items, and receiving items.
[Kerschbaum: 0028] Evidence can also be provided in the form of a chaining token. In general, chaining tokens represent a data entity that a business partner possesses and controls that may be used to authenticate the partner's identity. In one example, the chaining token may be a cryptographic key that is protected by encrypting it under a password. In particular, a chaining token is a signed statement that a party (e.g., X.sub.i.sub.--.sub.k) has either sent or received a tag with identifier (t) from another party (e.g., X.sub.i+n.sub.--.sub.k).
[Kerschbaum: 0030] Referring again to FIG. 1, the supply chain 100 includes three stages with one business partner at each stage. The three business partners include Alice (A) 102, Bob (B) 104, and Charlie (C) 106. Each partner stores datasets (y.sub.t) within a respective internal database. For example, the database stored by Alice 102 is represented by (y.sub.t,A). Similarly, the databases stored by Bob 104 and Charlie 106 are represented by (y.sub.t,B) and (y.sub.t,C), respectively.
Please note: Supplier Bob (B) 104 is a supplier to Charlier (C) 106 and Supplier Alice (A) 102 is a supplier’s supplier, i.e. Alice (A) is a supplier to Bob (B).
… a first security provision datum of a first supplier of the supply chain and
Please refer to Attachment A which illustrates Applicant’s Fig. 2. As disclosed in Applicant’s specification, the first supplier is defined to be SUP and the second supplier is defined to be SUPSUP (supplier’s supplier). Chain A as drawn by the undersigned examiner comprises SUPSUP (second supplier) [Wingdings font/0xE0] SUP (first supplier) [Wingdings font/0xE0] ENT. Attachment B illustrates Kerschbaum Fig. 1 that likewise illustrates Chain A. Chain A as drawn by the undersigned examiner comprises supplier A (SUPSUP) [Wingdings font/0xE0] B (SUP) [Wingdings font/0xE0] C (ENT). By definition B is the first supplier and A is the second supplier. Therefore the second supplier (A/SUPSUP) supplies the first supplier (B/SUP) and the first supplier (B/SUP) supplies the C (ENT).
[Kerschbaum: 0028] Evidence can also be provided in the form of a chaining token. In general, chaining tokens represent a data entity that a business partner possesses and controls that may be used to authenticate the partner's identity. In one example, the chaining token may be a cryptographic key that is protected by encrypting it under a password. In particular, a chaining token is a signed statement that a party (e.g., X.sub.i.sub.--.sub.k) has either sent or received a tag with identifier (t) from another party (e.g., X.sub.i+n.sub.--.sub.k). In general, links of a supply chain are tied together by chaining tokens and the system can use identity-based encryption (IBE) to encrypt the event data and protect access to the chaining token information.
[Kerschbaum: 0036] … In step 308, B receives the chaining token from A, and generates his own proof of possession (p.sub.t,B) and "received" chaining token (c'.sub.t,B). In step 310, the system (e.g., system 200) determines whether the item (I.sub.t) is to be sent from B to C. If the item (I.sub.t) is not to be sent, the system loops back. If the item (I.sub.t) is to be sent, B generates a "sent" chaining token (c.sub.t,B) in step 312. In step 314, B sends the item (I.sub.t) and his proof of possession (p.sub.t,B) to C.
Please note: Supplier A (second supplier) passes security datum to Supplier B (first supplier) and Supplier B passes security datum to C (entity).
… a second security provision datum of a second
As illustrated in Kerschbaum, the second supplier (A) passes security datum to the first supplier (B) who in turns passes security datum to entity C.
[Kerschbaum: 0036] In step 300, A generates a proof of possession (p.sub.t,A) of having possessed item (I.sub.t). In step 302, the system (e.g., system 200) may receive a request from a business partner to send an item through the supply chain 100. For example, the item (I.sub.t) may be sent to B from A. If item (I.sub.t) is sent to B, A generates a "sent" chaining token (c.sub.t,A) in step 304. If the system does not receive a request to send item (I.sub.t), the process continues to wait for a request before continuing. Upon generating the chaining token (c.sub.t,A), A sends the item (I.sub.t) and A's own proof of possession (p.sub.t,A) to B in step 306.
wherein the security information dataset includes a security demand datum of a supplied entity supplied by the first supplier; and
[Kerschbaum: 0036] … C generates his own proof of possession (p.sub.t,C) and a "received" chaining token (c'.sub.t,C) in step 316. Accordingly, the item (I.sub.t) has successfully passed through the supply chain 100.
matching or comparing the first security demand datum and the second security provision datum with the security demand datum; wherein the security provision datum of the second
[Kerschbaum: 0038] Referring now to FIG. 4, a flowchart illustrates exemplar steps that can be executed to provide access to event data within the exemplar supply chain 100 of FIG. 1. The flowchart of FIG. 4 is premised on a request by C to access event data from A. In step 400, C presents his proof of possession (p.sub.t,C) and his received chaining token (c'.sub.t,C) to B. A series of verification tests can be performed to validate C's presented information, which are discussed in further detail below. For example, in step 402, it is determined whether C's identity can be verified, in step 404 it is determined whether the chain from B to C is valid, and in step 406, it is determined whether B possesses a sent chaining token (c.sub.t,B). If any of these conditions is not true, C is denied access to the event data stored by B (e.g., event data y.sub.t,B), and the event data stored by A (e.g., event data y.sub.t,A) in step 408. If, however, all three verification tests 402, 404, and 406 are true, B provides the sent chaining token (c.sub.t,B), received chaining token (C'.sub.t,B), and proof of possession (p.sub.t,B) to C in step 410, and C is granted access to the event data stored by B (e.g., event data y.sub.t,B).
Please note: Verification tests involve matching or comparing data.
[Kerschbaum: 0039] In step 412, C presents the proof of possession (p.sub.t,B), the sent chaining token (c.sub.t,B), the received chaining token (c'.sub.t,B), the received chaining token (c'.sub.t,C), and the proof of possession (p.sub.t,C) to A. A series of verification tests are executed to validate the information presented by C. In step 414, it is determined whether C's identity can be verified, and in step 416, it is determined whether the chain from A 102 to C 106 is valid. If either step 414 or step 416 is not true, C is denied access to event data stored by A (e.g., data y.sub.t,A). If, however, step 414 and step 416 are both true, it is determine whether A possesses the sent chaining token (c.sub.t,A) in step 420. If A does not possess the sent chaining token (c.sub.t,A), C is denied access to event data (y.sub.t,A) in step 418. If A does possess the sent chaining token (c.sub.t,A), C is granted access to event data (y.sub.t,A) in step 422.
Regarding claim 4: Rejection is based upon the disclosures applied to claim 1 by Kerschbaum regarding security information of upstream suppliers.
Regarding claim 5: Rejection is based upon the disclosures applied to claim 1 by Kerschbaum and further upon disclosures of Kerschbaum regarding cryptographic signature:
[Kerschbaum: 0037] The subsequent discussion and corresponding flow charts provide exemplar routines that add varying levels of security (e.g., cryptography) to enforce policies for retrieving and sending supply chain data. The supply chain can employ various techniques to enforce security policies including, but not limited to time-based proof of possession, signature-based proof of possession, shared-secret based proof of possession, token-based proof of possession, and identity-based encryption.
[Kerschbaum: 0040] Referring now to FIG. 5, a flowchart illustrates exemplar steps that can be executed to provide a signature-based proof of possession in accordance with implementations of the present disclosure. In some implementations, signature-based proofs of possession can be performed using cryptographic hash functions. By way of one non-limiting example, Merkle signatures may be used to combine several keys of a one-time signature scheme (OTS). An advantage of a Merkle signature is that it can be computed without modular arithmetic, trapdoors or similar, and is simply based on cryptographic hash functions. The use of Merkle signatures is merely exemplar in nature and is not intended to limit the present disclosure.
Regarding claim 6: Rejection is based upon the disclosures applied to claim 1 by Kerschbaum and further upon disclosures of Kerschbaum regarding a supplier’s public and private information, see [0053]. Please note: For situations where only a portion of the supplier’s information is publicly available, the remainder of the information is remains private.
Regarding claim 7: Rejection is based upon the disclosures applied to claim 1 by Kerschbaum. Please note: Supplier C is aware of suppliers A & B as Alice and Bob.
Regarding claim 8: Rejection is based upon the disclosures applied to claim 1 by Kerschbaum. Kerschbaum is computer-based.
Regarding claim 10: Rejection is based upon the disclosures applied to claim 1 by Kerschbaum.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 2, 3, 11 and 12 are rejected under 35 USC 103 as being unpatentable over Kerschbaum, US 2010/0329464, in view of Shih et al., US 11,238,162 “Shih.”
Regarding claim 2 and 11: Rejections are based in part upon the teachings applied to claim 1 by Kerschbaum and further upon the combination of Kerschbaum-Shih. Although Kerschbaum halts access to supply chain data by a supplier’s supplier in the chain due to invalid security data provided by the supplier’s supplier, Kersachbaum does not expressly mention replacing the supplier’s supplier with a more conformant supplier. Shih on the other hand would have taught Kerschbaum such techniques.
In Shih see at least:
(Shih: D15: col. 4, lines 50-65) Trust analysis identifies which components the system trusts to enforce each security policy and analysis is guided by system security policies. Security policies put constraints on system transactions necessary to protect the confidentiality, integrity, and availability of data (e.g. domain separation). Trust analysis requires detailed knowledge of the specific system design to include all enforced security policies, all hardware and software components, and how system components interact to enforce each security policy. Each of the above are described in the system design documents. This information enables designers to identify which components enforce which security policies and the consequences on each security policy of a component failure. Trust assessment is wholly dependent on system design and how components are employed to enforce security policies.
(Shih: D17: col. 5, lines 20-37) Trustworthiness is the level of confidence established in a system element. It can be viewed as the likelihood a component will not fail to behave or perform as designed or expected (e.g. supply chain compromise). Three major factors contribute to trustworthiness: vendor, pedigree and complexity. The vendor factor is determined by the company(s) manufacturing or authoring the component, country(s) of origin, and the vendors processes for securing their supply chain throughout the chain of custody from development, manufacturing, product handling, to operational use; essentially the vendors reputation for delivery of reliable, unaltered components. The pedigree is determined by previous, current, and planned component usage and previous evaluations of any type; essentially, the components exposure to scrutiny. The complexity is determined by the number of gates or lines of code and functional complexity; essentially the probability of finding any inserted malware in the component.
(Shih: D20: col. 6, lines 15-24) Examples of supply chain risk mitigation include securing the supply chain to improve the probability that part meets spec. For example, choose an alternate component source to change component supplier to a source that is more trustworthy (Example: purchase memory part from United States instead of China). Perform vendor inspections; send independent inspectors to verify manufacturing/supply chain process. Perform blind buys by obfuscating purchaser of part to avoid targeted supply chain attack.
One of ordinary skill in the art before the effective filing date would have recognized that applying the known techniques of Shih as described above would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the techniques of Shih to the teachings of Kerschbaum would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such data processing features into similar systems. Obviousness under 35 USC 103 in view of the Supreme Court decision KSR International Co. vs. Teleflex Inc.
It would have been obvious to one of ordinary skill in the art before the effective filing date to ascertain the need to choose a supplier that is more trustworthy based upon non-conformance results from a security failure in the supply chain.
Regarding claim 3: Rejection is based upon the teachings and rationale applied to the combination of Kerschbaum-Chen.
Regarding claim 12: Rejection is based upon the teachings and rationale applied to the combination of Kerschbaum-Chen. Please note: Invalid security information from a supplier’s supplier Alice (A) to supplier Bob (B) or supplier Bob to manufacturer Charlie (C) can result in product manufacturing stoppage, especially if the supplier’s supplier is the only source for a raw material or component.
Claim 9 is rejected under 35 USC 103 as being unpatentable over Kerschbaum, US 2010/0329464, in view of Menninger et al., US 7,072,843 “Menninger.”
Rejection is based in part upon the teachings applied to claim 1 by Kerschbaum and further upon the combination of Kerschbaum-Menninger. Although Kerschbaum implements supply chain security across the supply chain to suppliers and a supplier’s supplier, Kerschbaum does not expressly mention specific security provision datum of a supplier’s supplier. Menninger on the other hand would have taught Kerschbaum such techniques.
In Menninger see at least:
(Menninger: D270: col. 13, lines 7-13) Web Architecture 122--underlying all this electronic activity is technology, the web architecture with Internet access (through proprietary service or an Internet Service Provider (ISP)) that allows these electronic communications to take place efficiently and effectively. Encompassed in this component is the building of initial web applications and security for the Supply Chain.
(Menninger: D440: col. 37, lines 10-18) Using a virtual private network involves encryption data before sending it through the public network and decrypting it at the receiving end. An additional level of security involves encrypting not only the data but also the originating and receiving network addresses. Microsoft, 3 Com, and several other companies have developed the Point-to-Point Tunneling Protocol (PPTP) and Microsoft has extended Windows NT-to support it. VPN software is typically installed as part of a company's firewall server.
(Menninger: D448: col. 38, lines 22-29) Rivest-Shamir-Adleman (RSA) is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman. The RSA algorithm is a commonly used encryption and authentication algorithm and is included as part of the Web browser from Netscape and Microsoft. It's also part of Lotus Notes, Intuit's Quicken, and many other products. The encryption system is owned by RSA Security. Please note: Reference Moore, US 2006/0173985, below for encryption strength:
[Moore: 0224] Encryption based systems may use a wide array of cryptographic technologies including a number of those readily available in current commercially available operating systems and applications. This includes DES, S/MIME, Exchange Server Security, PGP, RSA, and various other forms of symmetric and asymmetric cryptography having various strengths (i.e., length of keys or encryption blocks), along with a number of techniques for managing keys, certificates, and associated access privileges.
(Menninger: D673: col. 65, lines 21-39) On-Going Activities: There are a number of steps the supply chain coordinator should implement to keep up with changes in web security. The following is a list of activities to include for continual incident tracking and handling measures:
1. Subscribe to advisories that are issued by various security incident response teams, like those of the CERT Coordination Center, and update systems against those threats that apply to the supply chain coordinator's web portal technology.
2. Monitor security patches that are produced by the vendors of equipment, software, applications, and third party affiliates, and obtain and install all that apply.
3. Actively watch the configurations of the supply chain coordinator systems to identify any changes that may have occurred, and investigate all anomalies.
4. Review all security policies and procedures annually (at a minimum).
5. Regularly check for compliance with policies and procedures. This audit should be performed by someone other than the people who define or implement the policies and procedures.
(Menninger: D702: col. 68, lines 49-55) Privacy of files and information stored on or within the web portal applications needs to be assured. User information that includes name, address, financial information, and other confidential information may at times need to be shared.
(Menninger: D705: col. 69, lines 16-20) The privacy policy should define reasonable expectations of privacy regarding other issues such as monitoring of electronic mail, logging of keystrokes, as well as access to users' files.
One of ordinary skill in the art before the effective filing date would have recognized that applying the known techniques of Menninger as described above would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the techniques of Menninger to the teachings of Kerschbaum would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such data processing features into similar systems. Obviousness under 35 USC 103 in view of the Supreme Court decision KSR International Co. vs. Teleflex Inc.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 11,720,907 (Chen et al.) “Blockchain-Based Product Authentication System,” discloses:
(Chen: D9: col. 1, line 64-col. 2, line 16) The present disclosure includes methods and systems for providing instant authentication of a product and enhanced user experience with the product via blockchain technologies. In some embodiments, a product verification system may use blockchain technologies to track the supply chain process of each instance (e.g., each copy) of a product. For example, either automatically or upon a request by a manufacturer of the product, the product verification system may generate tokens for different instances (e.g., copies) or anticipated instances of the product. In some embodiments, a unique token is generated for each anticipated instance of the product. The token may be initially stored in (and associated with) a digital wallet (also referred to as “wallet”) associated with the product verification system or a digital wallet associated with the manufacturer. When production of the products begins, the product verification system may transfer the tokens to a digital wallet associated with a first entity in the supply chain process of the product (e.g., the entity that begins the manufacturing process, such as an entity that harvest raw materials for the product).
(Chen: D42: col. 10, line 45-col. 11, line 2) FIG. 3 illustrates an example electronic token 300 according to one embodiment of the disclosure. The electronic token (or simply as “token”) 300 may be issued by the minting module 204 and may correspond to an instance of the product. The electronic token 300 is an electronic product that is transferrable among different parties based on a particular protocol. In some embodiments, the electronic token 300 may be defined as a chain of digital signatures provided by previous owners of the electronic token 300 to subsequent owners of the electronic token. In the illustrated embodiment, the electronic token 300 is owned by an owner 312, and FIG. 3 illustrates how the electronic token 300 is defined by the digital signatures of the previous owners 314, 316, and 318. Specifically, in transaction A, a hash of the public key of owner 316 (i.e., the owner receiving, as a result of transaction A, the electronic token 300.sub.1 defined by digital signatures provided up to transaction A) and the previous transaction (not illustrated, but occurring prior to transaction A) was signed by owner 318 (i.e., the owner providing, as a result of transaction A, the electronic token 300.sub.1 defined by digital signatures provided up to transaction A) using a private key and added to an initial electronic token (which was defined by digital signatures provided up to the transaction prior to transaction A) such that the electronic coin 302 was transferred to owner 316.
US 2017/0109675 (Hosny et al.) “Systems and Methods for Identifying and Monitoring a Supply Network Using a Payment Processing Network,” discloses:
[Hosny: 0032] In some example embodiments, the one or more sequential suppliers of the supply network replacing the one or more sequential suppliers in the first chain are selected from the supply network based on one or more of: a distance to the first merchant, a distance to at least one of suppliers in the first supply chain that are being replaced, a distance to at least one of suppliers remaining the first supply chain, a distance to at least one other of the one or more sequential suppliers from the supply network, a weather forecast for locations associated with at least one of the one or more sequential suppliers from the supply network, transit data for possible transit routes servicing downstream the alternative supply chain, including at least one of the one or more sequential suppliers from the supply network, or economical characteristics associated with at least one of the one or more sequential suppliers from supply network.
[Hosny: 0089] In some embodiments, the monitoring and notification system is further configured to determine alternative supply chains for replacing supply chains that may experience supply problems and recommend such alternative supply chains to the relevant merchants. Thus, the method 300 further includes steps 335 of determining one or more alternative supply chain(s) for the merchant(s) affected by the potential supply problem and step 340 of providing such recommendation(s) to the respective merchant(s). For example, in some embodiments, for a given merchant that buys a particular type of good, e.g., as identified by the respective SKU, MCC, or some other unique identified, other merchant(s) that buy the same type of good are determined, and their respective supply chains are analysed to determine one or more alternative supply chains.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT M POND whose telephone number is (571)272-6760. The examiner can normally be reached M-F, 8:30 AM-6:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Smith can be reached at 571-272-6763. 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.
/ROBERT M POND/Primary Examiner, Art Unit 3688 March 5, 2026