DETAILED ACTION
Status of Claims
This Office Action is in response to claims filed with RCE on 12/22/2025.
Claims 1-4, 6-11, 13-18 and 20 are pending while claims 5, 12 and 19 are canceled.
Claims 1-4, 6-11, 13-18 and 20 are examined hereon.
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 .
Response to Arguments
With respect to the rejection of claims under 35 U.S.C. 103, Applicant is of the opinion that the Examiner withdraw the rejection of independent claim 1, and allow the independent since the cited portion of Mattsson does not disclose or suggest, as amended independent claim 1 recites, that "selecting the portion of the hash as the table offset includes selecting from the token table a first value that corresponds to the portion of the hash, wherein the first value comprises a number, and using the number from the token table as the table offset." More specifically, these paragraphs of Mattsson disclose substituting first and second substrings of characters with first and second tokens from a token lookup table. However, these paragraphs do not disclose or suggest anything with respect to a table offset. Further, there is no indication that even if these paragraphs of Mattsson did disclose anything related to a table offset, that the table offset is a number from the token lookup table, for example, in accordance with the above amendments to independent claim 1. Also, as discussed in the Reply that Applicant filed on July 18, 2025, although Bush's paragraph 85 discloses "table offset," this paragraph of Bush refers to the use of a "random number generator," and not to any number from a lookup table.
Examiner fully considers Applicant’s position, but respectfully disagree because as previously provided in the Final Rejection/Advisory Action and as Applicant previously admitted, Mattsson discloses selecting a remainder of the character string as a context, computing a hash of the context and selecting a portion as a table offset. That is, according to Applicant’s Specification in Par. [0048] which describes what a context may be as “For example, portions of a 16-digit financial account number, “1234-5612-3456-7812”, may be tokenized to provide security for the account number. For example, the middle 8 digits, “xxxx-xx12-3456-78xx”, may be tokenized, leaving the remaining 8 digits, “1234-56xx-xxxx-xx12”, as context for the tokenization.” As similarly, Mattsson discloses at Par. [0062], “Credit Card Numbers (CCN) are registered at the registers 10. The CCN is of the form ABC, where A is the BIN, which is normally 6 digits, B is a random number, typically 12 digits long, and C is the final digits, e.g. the last 4 digits, typically including a final check digit…” hence “A” or “C” are considered context which are stored hashed and a part of the first digits as portion of character strings are selected as table offsets for tokenization of sensitive character string as showing specifically on Fig. 5 and it’s associated section as well as See. Figs. 2-8; Pars. [0062], [0064]-[0065], [0075]-[0076]. Further, the Figs. of Mattsson and specifically Fig. 5 discloses first value comprising a number and using the number from the token table as the table offset which is using the first value (“789”) that is selected as the table offset which corresponds to a portion using a same token “Table 1.” (See, Figs. 3-9, specifically 5 and associated Pars. [0015]-[0016])
Although Mattsson discloses that the contexts are hashed and sorted, Mattsson does not explicitly disclose portion of the hashed context for table offset. Bush discloses the hash as the table offset (“shift positions”). (See. Par. [0085])
Therefore, 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 to simply substitute a special indicator that is assigned a certain position in a token, such as a first position in the token stored as hashed version (Pars. [0032], [0039], [0065]) of Mattsson in view of Bush in order to make a tokenized string of characters with an indicator in first position clearly recognizable and to make certain that the tokenized string of characters is not mistaken for e.g. a valid credit card number stored in a hashed version (Mattsson, Pars. [0039], [0065]) and to efficiently protect sensitive data at-rest and/or in-transit by generating shifted ciphertext to tokenize and detokenize data (Bush, Pars. [0022], [0029]). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6, 8-11, 13 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Mattsson (US 2021/0073414 A1) in view of Bush et al. (US 2021/0390884 A1).
With respect to claims 1, 8 and 15, Mattsson discloses a computer-implemented method, a non-transitory machine-readable medium, and a system for securing data by stateless tokenization, the system comprising: a data storage device storing instructions for securing data by stateless tokenization in an electronic storage medium; and a processor configured to execute the instructions to perform a method including:
receiving a character string; (Fig. 3; Pars. [0014], “receiving a sensitive string of characters;” [0071])
selecting a remainder of the character string as a context; (“A” or “C”) (“AXC”, “where A is the BIN”) (Fig. 2; Par. [0062], “In this example, Credit Card Numbers (CCN) are registered at the registers 10. The CCN is of the form ABC, where A is the BIN, which is normally 6 digits, B is a random number, typically 12 digits long, and C is the final digits, e.g. the last 4 digits, typically including a final check digit… The result of the tokenization is that the substring B to be substituted is substituted by a final token X. The X values can be numerical or alphanumerical values, and are preferably of the same length as the B values, i.e. in this example 6 digits. Consequently, the token service identifies a token corresponding to the received B value, and substitutes the B value with the token X to form a tokenized string of characters AXC.” [0064], “Further, it is also possible to add a check-sum test 24 for the tokenized string of characters AXC. This test may evaluate if the final digit in C is a correct digit in accordance with a check-sum test, e.g. following the Luhn algorithm. If the check-sum digit is correct, the tokenized string of characters may be mistaken for an original sensitive string of characters. Thus, for some applications, the result of the check-sum test may be deemed unsatisfactory if the check-sum digit is correct, whereas for other applications, the result of the check-sum test may be deemed unsatisfactory if the check-sum digit is incorrect. In case the result of said check-sum test is unsatisfactory, the step of substituting section B with a token X may be repeated with another token until said check-sum test is satisfied.”)
computing a hash of the context; (Fig. 2; Pars. [0065], “This database stores the tokenized string of characters AXC, and possibly in combination with the original CCN value ABC and/or a hashed version of ABC.” [0086] “A hash value for said sensitive string of characters may also be generated,”)
selecting a portion as a table offset (“first group of three digits”); (Figs. 3-9; Pars. “In a third embodiment of a tokenization method, schematically illustrated in FIG. 5, the sensitive string of characters again includes four groups of three digits and one group of four digits… Thus, in a first step, the first token lookup table is used to substitute the first two groups of three digits each into a token with the same number of digits, to form a first tokenized string of characters. Then, in a second step, the… first token lookup table is used to substitute the second and third group of three digits each into a token with the same number of digits, to form a second tokenized string of characters. Then, in a third substitution step, the first token lookup table is again used to substitute the first two groups of three digits each into a token with the same number of digits, to form a third tokenized string of characters.” [0076])
selecting a character window (“substring”) at a starting point within the character string; (Fig. 3; Par. [0015], “substituting a first substring of characters with a corresponding first token from said at least one token lookup table to form a first tokenized string of characters, said first substring of characters being a substring of said sensitive string of characters;”)
accessing a token table at an index (“token”) equal to a value of the character window (“the second and third group of three digits”) plus the table offset; (Fig. 3; Pars. [0017], [0071], “Then, in a second step, the second token lookup table is used to substitute the second and third group of three digits each into a token with the same number of digits. Here, the second group of digits comprises a token from the first substitution step, whereas the third group of digits comprises digits from the original sensitive string of characters. Accordingly, a second sub string of six digits in total is here substituted by a second token with six digits, to form a second tokenized string of characters.”)
wherein the selecting the portion as the table offset includes selecting from the token table a first value (“789”) that corresponds to the portion, wherein the first value comprises a number, and using the number from the token table as the table offset; (Figs. 3-9; Par. [0015], “substituting a first substring of characters with a corresponding first token from said at least one token lookup table to form a first tokenized string of characters, said first substring of characters being a substring of said sensitive string of characters;” [0016])
retrieving, from the token table at the index, a first tokenized value (“a token with the same number of digits”) corresponding to the value of the character window (“first two groups of three digits”) plus the table offset (Fig. 3; Par. [0071], “Thus, in a first step, the first token lookup table is used to substitute the first two groups of three digits each into a token with the same number of digits, to form a first tokenized string of characters.” [0073] “The use of two different lookup tables enhances the security. However, it is also possible to use the same lookup table for both the consecutive steps.” [0078]);
replacing (“substitute”) the value of the character window within the character string with the retrieved first tokenized value (Fig. 3; Pars. [0071], [0078]);
accessing the token table at the index (“the same number of digits”) equal to the value of the character window (“the second and third group of three digits”) shifted in the plus the table offset (Figs. 3-8; Pars. [0071], “Then, in a second step, the second token lookup table is used to substitute the second and third group of three digits each into a token with the same number of digits. Here, the second group of digits comprises a token from the first substitution step, whereas the third group of digits comprises digits from the original sensitive string of characters. Accordingly, a second sub string of six digits in total is here substituted by a second token with six digits, to form a second tokenized string of characters.” [0073], “The use of two different lookup tables enhances the security. However, it is also possible to use the same lookup table for both the consecutive steps.”);
retrieving, from the token table at the index, a second tokenized value (“a token with the same number of digits”) corresponding to the value of the character window (“second and third group of three digits”) shifted in the plus the table offset (Figs. 3-8; Pars. [0071]);
replacing (“substitute”) the value of the character window within the character string with the retrieved second tokenized value (Figs. 3-8; Pars. [0071]);
shifting the shifted character window (“tokenized string of characters”) within the character string by one character (“T”) in a second direction (“first position in the token”) (Figs. 3-7; Par. [0039], “it is also possible to use a special indicator in the tokens, to make the tokenized string of characters clearly recognizable, and to make certain that the tokenized string of characters is not mistaken for e.g. a valid credit card number. For example, the special indicator may be the character “T”. Further, the special indicator may be assigned a certain position in the token, such as the first position in the token.”);
accessing the token table at the index (“the same number of digits”) equal to the value of the character window (“the second and third group of three digits”) shifted in the second direction plus the table offset (Figs. 3-8; Pars. [0071], [0073]);
retrieving, from the token table at the index, a third tokenized value (“a token with the same number of digits”) corresponding to the value of the character window (“second group of digits”) shifted in the second direction plus the table offset (Figs. 4-6; Pars. [0075], “Then, in a third substitution step, the first token lookup table is again used to substitute the first two groups of three digits each into a token with the same number of digits, to form a third tokenized string of characters.” [0076], “The resulting third tokenized string of characters also comprises four groups of three digits each, and a fifth group comprising four digits. The first group of digits is substituted by tokens in two consecutive substitution steps. The second group of digits is substituted by tokens in three consecutive substitution steps. The third group of digits is substituted by tokens in one substitution step.”);
replacing the value of the character window shifted in the second direction within the character string with the retrieved third tokenized value; (Figs. 4-6; Pars. [0075]-[0076]) and
returning the character string as a tokenized character string (Figs. 4-6; Pars. [0076], “The resulting third tokenized string of characters also comprises four groups of three digits each, and a fifth group comprising four digits. The first group of digits is substituted by tokens in two consecutive substitution steps. The second group of digits is substituted by tokens in three consecutive substitution steps. The third group of digits is substituted by tokens in one substitution step.”).
Mattsson does not explicitly disclose:
the hash as the table offset,
shifting the character window within the character string by one character in a first direction, shifted in the first direction.
Bush discloses:
the hash as the table offset (“shift positions”). (Pars. [0085] “FIG. 1 describes a deterministic token implementation where the two shift positions (mtk_sp, dtkt_sp) are calculated from a hashing function of known inputs that won't change over multiple tokenization invocations.” [0109] “In various implementations, the MTK shift position for the data type may be determined using either a deterministic token implementation or a randomized token implementation.” [0156] “the metadata token may include the DTKT shift position. If a randomized token implementation was used to calculate the MTK shift position, the metadata token may also include the MTK shift position.”)
shifting the character window (“number of characters”) within the character string (“cta=ciphertext alphabet of randomly mixed or rearranged characters from plaintext alphabet”) by one character in a first direction, shifted in the first direction, (“Right-to-left”) (Fig. 1; Pars. [0033], “Tokenize (T) Function token=T(pt, pta, cta, sp) where pt=plaintext input to be tokenized, pta=plaintext alphabet consisting of set of characters (e.g., full ASCII table), cta=ciphertext alphabet of randomly mixed or rearranged characters from plaintext alphabet, sp=shift position where 0<=sp<length(cta); T performs a shifted substitution cipher by: 1. scta=shift(cta, sp) Right-to-left circular shift sp number of characters from beginning of cta; 2. token=translate(pt, pta, scta) Generate a substitution cipher of plaintext pt using plaintext alphabet pta and ciphertext alphabet scta; 3. token=reverse(token) Return a reversed token string” [0109]-[0115], [0134]-[0141]).
Therefore, 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 to simply substitute a special indicator that is assigned a certain position in a token, such as a first position in the token stored in hashed version (Pars. [0032], [0039], [0065]) of Mattsson in view of Bush in order to make a tokenized string of characters with an indicator in first position clearly recognizable and to make certain that the tokenized string of characters is not mistaken for e.g. a valid credit card number stored in a hashed version (Mattsson, Pars. [0039], [0065]) and to efficiently protect sensitive data at-rest and/or in-transit by generating shifted ciphertext to tokenize and detokenize data (Bush, Pars. [0022], [0029]). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
With respect to claims 2, 9 and 16, Mattsson in view of Bush discloses all the limitations as described above. Additionally, Mattsson discloses wherein the second direction is to the right (“first position in the token” which is left-to-right) (Fig. 3; Par. [0039]).
Mattsson does not explicitly disclose the first direction is to the left.
Bush disclose the first direction is to the left (“Right-to-left”) (Figs. 1; Pars. [0033]- [0045], “T performs a shifted substitution cipher by: 1. scta=shift(cta, sp) Right-to-left circular shift sp number of characters from beginning of cta; 2. token=translate(pt, pta, scta) Generate a substitution cipher of plaintext pt using plaintext alphabet pta and ciphertext alphabet scta; 3. token=reverse(token) Return a reversed token string” [0134]-[0141]).
Therefore, 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 to simply substitute a special indicator that is assigned a certain position in a token, such as a first position in the token (Par. [0039]) of Mattsson in view of Bush in order to make a tokenized string of characters with an indicator in first position clearly recognizable and to make certain that the tokenized string of characters is not mistaken for e.g. a valid credit card number (Mattsson, Par. [0039]) and to efficiently protect sensitive data at-rest and/or in-transit by generating shifted ciphertext to tokenize and detokenize data (Bush, Pars. [0022], [0029]). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
With respect to claims 3, 10 and 17, Mattsson in view of Bush discloses all the limitations as described above. Additionally, Mattsson discloses:
selecting a remainder of the character string as a clear text (“AXC”, “where A is the BIN”) (Fig. 2; Par. [0062], “In this example, Credit Card Numbers (CCN) are registered at the registers 10. The CCN is of the form ABC, where A is the BIN, which is normally 6 digits, B is a random number, typically 12 digits long, and C is the final digits, e.g. the last 4 digits, typically including a final check digit… The result of the tokenization is that the substring B to be substituted is substituted by a final token X. The X values can be numerical or alphanumerical values, and are preferably of the same length as the B values, i.e. in this example 6 digits. Consequently, the token service identifies a token corresponding to the received B value, and substitutes the B value with the token X to form a tokenized string of characters AXC.”),
wherein the starting point is within the clear text (Figs. 3-9).
With respect to claims 4, 11 and 18, Mattsson in view of Bush discloses all the limitations as described above.
Mattsson does not explicitly disclose wherein the shifting the character window within the character string by one character in the first direction is repeated until the character window is at a stopping point within the character string.
Bush discloses wherein the shifting the character window within the character string by one character in the first direction is repeated until the character window is at a stopping point within the character string (Pars. [0123]- [0129] “shift=a function that generates a shifted ciphertext alphabet by shifting mtk by mtk_sp characters using a right-to-left circular shift (e.g., if mtk_sp<N then shift mtk from right to left mtk_sp characters, and if N<=mtk_sp<2N then shift reverse(mtk) right to left mtk_sp characters, where N=length of mtk)”).
Therefore, 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 to simply substitute a special indicator that is assigned a certain position in a token, such as a first position in the token (Par. [0039]) of Mattsson in view of Bush in order to make a tokenized string of characters with an indicator in first position clearly recognizable and to make certain that the tokenized string of characters is not mistaken for e.g. a valid credit card number (Mattsson, Par. [0039]) and to efficiently protect sensitive data at-rest and/or in-transit by generating shifted ciphertext to tokenize and detokenize data (Bush, Pars. [0022], [0029]). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
With respect to claims 6 and 13, Mattsson in view of Bush discloses all the limitations as described above.
Neither Mattsson nor does Bush explicitly discloses wherein the token table comprises bn random numbers, ranging from 0 to bn -1, where n is a size of the character window and b is a size of an alphabet base b for the character string. However, the specific factors used in the formula only describe values used to perform a calculation and do not affect the manner in which the anticipated token table with random numbers. Therefore, 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 to use any variables in the formula that are necessary to calculate token tables with random numbers according to a particular business model or goal, as this is a matter of design choice. (In re Kuhle, 526 F.2d 553, 188 USPQ7 (CCPA 1975))
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mattsson (US 2021/0073414 A1) in view of Bush et al. (US 2021/0390884 A1) in view of Flitcroft et al. (US 2003/0028481 A1).
With respect to claims 7, 14 and 20, Mattsson in view of Bush discloses all the limitations as described above. Additionally, Mattsson discloses:
receiving an encrypted payment payload in response to a transaction initiated by a consumer at a merchant (Fig. 2; Pars. [0016], “The sensitive string of characters is preferably at least one of a number associated with personal information related to an individual, such as a social security number, and a number associated with financial holdings and transactions, such as a credit card number or a bank account number.” [0035], “When transferred between different units, the string of sensitive characters is preferably transferred between the units in encrypted form.” [0066], “Further, the tokenized string of characters AXC is preferably transferred to the central server 30, to be stored in a central token master database 32.” [0069]),
wherein the encrypted payment payload comprises a primary account number (PAN) of a finance account of the consumer (Pars. [0035], [0062], “Credit Card Numbers (CCN) are registered at the registers 10.”);
setting the value of the character string to the PAN (Figs. 3-9; Par. [0062], “Consequently, the token service identifies a token corresponding to the received B value, and substitutes the B value with the token X to form a tokenized string of characters AXC.”);
transmitting the tokenized character string to the merchant (Fig. 2; Pars. [0061], “The units 10 providing the sensitive string of characters to the local server 20 is not limited to cash registers, and may be any type of business application or the like. The unit 10 provides clear data field information regarding the sensitive string of characters to be tokenized to the local server 20, and receives as a result a tokenized string of data.”).
Neither Mattsson nor does Bush explicitly disclose:
receiving an authorization request for the transaction, the authorization request comprising the tokenized character string;
requesting authorization for the transaction from an issuer financial institution of the finance account of the;
receiving an authorization decision for the transaction from the issuer financial institution; and
transmitting an authorization response to the merchant.
Flitcroft discloses:
receiving an authorization request for the transaction, the authorization request comprising the tokenized character string (“limited use card numbers”) (Fig. 15; Pars. [0207]-[0208], [0217], “The dual interface transmissions, referred to herein as remapping, allow merchants and card issuers to handle transaction details in the same manner as conventional credit card transactions. Such conventional credit card transactions may be, for example, authorizations, settlements, copy requests, and charge-backs.”, [0234], “When a merchant 1510 receives a transaction utilizing a limited use number from RAD system 1506, the transaction details are handled in the same manner as an existing number since limited use card numbers share the same format as existing credit card numbers. The transaction details are transferred to the merchant acquirer and then routed onto the appropriate issuer on the basis of the leading digits of the limited use number, i.e., BIN, via central processing station 1508. The BIN is registered with central processing station 1508 to ensure appropriate routing.”);
requesting authorization for the transaction from an issuer financial institution of the finance account of the consumer (Fig. 15; Pars. [0235], “As described above, central processing station 1508 verifies the validity of the limited use number and ensures that the transaction meets all specified limitations. If the limited use number is valid and the transaction met the specific limitations, central processing station 1508 enters the master credit card number into the transaction message in place of the limited use number. Central processing station 1508 then transmits the transaction message to the issuer's processing facility 1512 as a normal authorization request.”);
receiving an authorization decision for the transaction from the issuer financial institution (Fig. 15; Par. [0235], “The issuer's processing facility 1512 transmits an authorization for the master card number, if appropriate, to central processing facility 1508.”); and
transmitting an authorization response to the merchant (Fig. 15; Par. [0235], “Central processing facility remaps the master card number to the limited use number and the transaction message is transmitted to the originating merchant acquirer and then the merchant.”).
Therefore, 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 to simply substitute a system for retail industry in compliant with the Payment Card Industry (PCI) Data Security Standard (DSS) (Par. [0026]) of Mattsson, Bush in view of Flitcroft in order to tokenize sensitive financial data of consumers to reduce risk exposure of the financial data while allowing merchants to get to consumers’ financial data for business needs (Mattsson, Par. [0026]) and to prevent (fraud) an unscrupulous consumers using credit card numbers to supply goods or services (Flitcroft, Par. [0055]). ("Express suggestion to substitute one equivalent technique for another need not be present to render such substitution obvious"; In re Fout, 213 USPQ 532 (CCPA 1982), In re Siebentritt, 152 USPQ 618 (CCPA 1967); Ex Parte Smith, 83 USPQ2d 1509 (Bd. Pat. App. & Int. 2007); KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
PGPub Wright et al. (US 2021/0359836 A1), Wright discloses:
selecting a character window at a starting point within the character string (Par. [0223]);
computing a hash of the context (Par. [0227])
PGPub TADA et al. (US 2019/0354491 A1) disclose the hash as the table offset. (Par. [0072])
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WODAJO GETACHEW whose telephone number is (469)295-9069. The examiner can normally be reached M-F 8:00-6:00 CST.
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, John W Hayes can be reached at (571) 272-6708. 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.
/WODAJO GETACHEW/Examiner, Art Unit 3697