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 .
This Office Action is in response to Amendment filed on 11/11/2025.
In the instant Amendment, claim 14 has been amended; and claims 1, 11, and 14 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Final
In light of Applicant’s amendments, objection of claim 14 has been withdrawn.
Response to Arguments
Applicant's arguments filed 11/1/2025 regarding claims 1-20 have been fully considered but they are not persuasive.
Applicant argues that there is “no first provisioning data” in Galdo regarding claims 1 and 11.
Galdo expressly teaches that, after validating the friend device’s secure-element attestation, the owner signs the sharing entitlements and the friend secure-element public key, encrypts the signed result using a session key, and also encrypts other tokens as needed, and then transmits this encrypted data to relay servers using a URL/session ID; the friend device obtains the encrypted data and decrypts it in its secure element. (Galdo, [0071]–[0072].) Galdo further explains that the “other tokens” may include access/operation tokens such as an immobilizer token for a vehicle. (Galdo: [0045].) Accordingly, Galdo teaches relay-mediated delivery of encrypted data comprising entitlements/tokens that authorize and enable the friend’s access to the electronically-secured property, i.e., “first provisioning data” for the shared access credential. Such encrypted entitlements/tokens constitute “first provisioning data” because they are data used to enable/authorize/instantiate the shared digital key/access on the recipient side, consistent with Applicant’s own description that provisioning data includes key-creation/authorization material. The friend device’s secure-element attestation/credential chain further provides device-associated identity information used to associate the recipient device with the share transaction, i.e., contact/identity information in the context of secure device-to-device provisioning via a relay.
Applicant argues that “Huang authenticates a card/user, not the device; no pre-registration info”
The Examiner respectfully disagrees. Applicant’s argument is not persuasive because Huang expressly discloses that a magnetic secure transmission device (MST 102) is an electronic device having a unique device identifier (IDMST), and that the wallet server 106 stores association data linking the IDMST to a user account (Huang, [0030], [0035]). Huang further discloses that the MST is registered to the user account during initialization, after which the MST and wallet server perform authenticated handshakes and command exchanges (Huang [0037]–[0038]). This registration and storage of association data constitutes pre-registration of the electronic device with the host computer, as recited. Huang also teaches that the host computer stores pre-registration information associated with the electronic device, including the IDMST–account association and device-specific cryptographic keys retrievable based on IDMST (Huang [0030], [0042], [0062]). Such information is necessarily stored prior to later provisioning and authentication operations. Huang further teaches performing a comparison based on an identifier of the electronic device and stored information, because the wallet server explicitly checks whether the IDMST is currently associated with the user’s wallet account before permitting provisioning to proceed (Huang, [0042], [0050]). When this comparison indicates a match, the wallet server proceeds to generate and return device-specific authorization or provisioning data; when it does not, provisioning is denied (Huang, [0042]–[0044], [0062]). Thus, Huang teaches that a successful comparison results in the electronic device being considered verified, as claimed.
Applicant’s assertion that Huang verifies only a card or issuer is an overly narrow reading of the disclosure. Although Huang also performs card-level checks, the verification of IDMST against stored association data is a distinct device-level verification that is required before any card provisioning occurs (Huang: [0041]–[0042], [0050]). Claim 14 does not exclude additional verification steps. Rodriguez is properly relied upon to teach generating hashed or digested identifying information after verification and using such transformed information for downstream provisioning, thereby satisfying the remaining post-verification limitations of claim 14. Accordingly, Applicant’s amendment and arguments do not overcome the rejection of claim 14.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 7-11 are rejected under 35 U.S.C. 103 as being unpatentable over Galdo et al. (WO 2019241047 A1 ; Hereinafter “Galdo”) in view of Huang et al. (US 20150371234 A1; Hereinafter “Huang”).
As per claims 1, 11, Galdo teaches an electronic device (device 10), comprising (Galdo: para [23], [30], “The system may include the owner device 10, the friend device 12”):
an interface circuit configured to communicate with a second electronic device (device 12), a relay computer and (Galdo: para[30], [70] [73], “In the embodiment of Fig. 12, one or more relay servers 142 may be used to permit the owner 40 to make a single communication to the friend 42 to provide a sharing”);
a processor coupled to the interface circuit (Galdo: fig. 13, para [75-79], [90], processor 1302); and
memory, coupled to the processor, storing program instructions, wherein, when executed by the processor, the program instructions cause the electronic device to perform operations comprising (Galdo: fig. 13, para [79], [90], Memory 1314):
receiving, associated with the second electronic device, an invitation to receive an instance of a digital key, wherein the invitation comprises an encryption key and an address of the relay computer (Galdo: fig 12, arrow 140, para [70], “In this embodiment, the owner device 10 may transmit a sharing invitation, with a URL and session ID provided from the relay server 142. The owner device 10 may obtain the URL and the session ID at some point prior to the sharing (e.g. well in advance, or in response to the user 40 deciding to perform the share). The owner device 10 may also generate a session key to be used for encryption by the devices 10 and 12 for data to be transferred through the relay servers 142.. the session key may be a symmetrical key that may be used for both encryption and decryption (arrow 140 in Fig. 12).” Galdo discloses that the owner device transmits a sharing invitation with URL and session ID provides from relay server(s) (142), and the owner device generates a session key used for encryption/decryption of data transferred through relay services 142);
providing, addressed to the relay computer, a request for contact information associated with the electronic device and first provisioning data for the instance of the digital key (Galdo: fig 12, arrow 140, para [45], [71-72], “The friend device 12 may encrypt its SE attestation (e.g. the friend SE PK certification and chain) do the session key and may transmit the encrypted attestation to the relay servers 142 using the URL.” Galdo discloses that the friend device transmits encrypted information to the relay servers using the URL and further that the owner device transmits encrypted data to the relay servers using the URL and session ID, which the friend device obtains (i.e., requests/retrieves via the URL/session) from the relay servers. In particular, Galdo teaches that the owner device encrypts (i) the friend SE public key and (ii) the sharing entitlements, and may also encrypt other tokens as needed, then transmits the resulting encrypted data to relay servers 142 using the URL/session ID, which the friend device obtains from the relay servers . Such encrypted sharing entitlements and tokens constitute first provisioning data for enabling the friend device to obtain/instantiate access rights to the electronically-secured property, e.g., “other tokens” may include an immobilizer token required to permit an automobile to operate );
receiving, associated with the relay computer, encrypted information specifying the contact information and the first provisioning data (Galdo: fig 12, arrow 140, para [71-72], “(Galdo: fig 12, arrow 140, para [71-72], “the owner device 10 may communicate with the key tracking server 110 to check the CRL and may sign the sharing entitlements and the friend SE PK if validated successfully (arrows 112 and 114). The secure element 14 may sign the friend SE PK and the sharing entitlements, and may encrypt the result using the session key. The secure element 14 may also encrypt the other tokens 52, as needed. The owner device 10 may transmit the encrypted data to the relay servers 142 using the URL and session ID….The friend device 12 may obtain the encrypted data and the secure element 16 may decrypt the data.” Galdo discloses that the friend device transmits to relay servers an encrypted SE attestation (friend SE PK certification and chain) (device-associated identity/credential information) and that the owner device transmits to relay servers encrypted data comprising the signed friend SE PK and signed sharing entitlements (and optionally other tokens), which the friend device obtains from the relay servers);
decrypting the encrypted information (Galdo: fig 12, arrow 140, para [71-72], “(Galdo: fig 12, arrow 140, para [71], “The friend device 12 may obtain the encrypted data and the secure element 16 may decrypt the data.”).
Galdo does not explicitly teach providing, addressed to the host computer, second contact information and input data for a hash function; and selectively receiving, associated with the host computer, second provisioning data for the instance of the digital key.
However, in the related art, Huang teaches providing, addressed to the host computer, second contact information and input data for a hash function (Huang: para[65-67], “the mobile communication device sends authentication information (for example, ID.sub.MST, R.sub.MST, username, password, and A* (where A* includes information, such as, an issuer account credential based on the issuer's authentication requirements)) to the wallet server (702).”); and
selectively receiving, associated with the host computer, second provisioning data for the instance of the digital key (Huang: para[66-67], “The wallet server retrieves the MST's K.sub.MST from ID.sub.MST, and sends K.sub.dCVV and SYNC (where SYNC contains the time-stamp information, and is used to synchronize time between the MST and the wallet server) to the mobile communication device (716”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have modify Galdo to include Huang’s server assisted validation provisioning exchange so that additional provisioning information is provided only after validation, thereby reducing fraudulent or unauthorized portioning (Huang: para [04]).
As per claim 2, Galdo in view of Huang teaches the independent claim 1. Huang teaches wherein the input data comprises a random or pseudorandom data (Huang: para[41], “The mobile communication device queries the MST for its identifier (ID.sub.MST) and session nonce R.sub.MST (308)”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Galdo with the validation process of Huang, it will prevent provisioning a pairing key to a malicious party and protect from potential fraud (Huang: para [04]).
As per claim 6, Galdo in view of Huang teaches the independent claim 1. Galdo teaches wherein the contact information comprises at least one of a telephone number or an email address (Galdo: para[24], “For example, the identity may include one or more of a phone number (e.g. if the device 12 is a mobile phone such as a smart phone), an email address, a name, a user name in a particular app, a user name on an account with a particular institution (e.g. an Apple.sup.® ID), et”).
As per claim 7, Galdo in view of Huang teaches the independent claim 1. Galdo teaches wherein the invitation comprises a link corresponding to the address of the relay computer (Galdo: fig 12, arrow 140, para [70], “In this embodiment, the owner device 10 may transmit a sharing invitation, with a URL and session ID provided from the relay server 142. The owner device 10 may obtain the URL and the session ID at some point prior to the sharing (e.g. well in advance, or in response to the user 40 deciding to perform the share).”).
As per claim 8 Galdo in view of Huang teaches the independent claim 1. Galdo teaches wherein the instance of the digital key comprises a digital car key or a digital lock key (Galdo: para [45], “The other tokens may be tokens used by the electronically-secured property 18 in addition to the sharing tokens or, in the case of the owner, the owner’s credentials, to provide access to the property or enable certain features or operations of the property 18. For example, if the property 18 is a vehicle and more specifically an automobile, an immobilizer token may be required permit the automobile to operate. The immobilizer token may be one of the other tokens.”).
As per claim 9, Galdo in view of Huang teaches the independent claim 1. Galdo teaches wherein the relay computer is associated with a different manufacturer or a provider than a manufacturer or a provider of the electronic device (Galdo: para [73], “It is noted that, in some embodiments, each device OEM may have its own relay servers 142. Thus, when devices 10 and 12 are manufactured by different OEMs, different relay servers 142 may be contacted by the devices 10. Thus, there may be multiple transmissions of the encrypted data through multiple relay servers 142 between the devices 10 and 12, in some embodiments.”).
As per claim 10, Galdo in view of Huang teaches the independent claim 1. Galdo teaches wherein the relay computer is associated with a manufacturer or a provider of the second electronic device (Galdo: para [73], “It is noted that, in some embodiments, each device OEM may have its own relay servers 142. Thus, when devices 10 and 12 are manufactured by different OEMs, different relay servers 142 may be contacted by the devices 10. Thus, there may be multiple transmissions of the encrypted data through multiple relay servers 142 between the devices 10 and 12, in some embodiments.”).
Claims 3-4, 12 are rejected under 35 U.S.C. 103 as being unpatentable over Galdo et al. (WO 2019241047 A1 ; Hereinafter “Galdo”) in view of Huang et al. (US 20150371234 A1; Hereinafter “Huang”) in view of Murray et al. (US 10326797 B1; Hereinafter “Murray”).
As per claims 3, and 12, Galdo in view of Huang teaches the independent claim 1.
Galdo in view of Huang does not teach wherein, after providing the contact information and the input data, and prior to receiving the second provisioning data, the operations comprise performing a verification process with the host computer and a verification computer.
However, in the related art, Murray teaches wherein, after providing the contact information and the input data, and prior to receiving the second provisioning data, the operations comprise performing a verification process with the host computer and a verification computer (Murray: col. 14, line 9-23, “the authentication of the second device 130 to the cloud architecture 140 can be implemented using an application installed on the second device 130. The application can be configured to be managed by the operating system 134 and instantiated by the processor 133 using the operating system 134. The application can be implemented using a method to verify the identity of the user of the second device 130. The application can use the elements and modules on the second device 130 to aid in the task of user identification. The application can, for example, perform second device 130 authentication by asking the user to input a username and password using display device and input device technologies, such as a touch screen display, that can be relayed to the web server 446 for authentication”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Galdo with the validation process of Murray, it will prevent provisioning a pairing key to a malicious party and protect from potential fraud (Murray: col. 14, line 5-10);
As per claims 4, Galdo in view of Huang and Murray teaches the dependent claim 3. Murray teaches wherein the verification process comprises a one-time password authentication (Murray: col. 14, line 9-23, “the methods for adding a secure connection can be performed using a one-time password (OTP) method that generates an encryption key with a finite validity period.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Galdo with the validation process of Murray, it will prevent provisioning a pairing key to a malicious party and protect from potential fraud (Murray: col. 14, line 5-10);
Claims 5, 13 are rejected under 35 U.S.C. 103 as being unpatentable over Galdo et al. (WO 2019241047 A1 ; Hereinafter “Galdo”) in view of Huang et al. (US 20150371234 A1; Hereinafter “Huang”) and Chazot et al. (US 20200382954 A1; Hereinafter “Chazot”).
As per claims 5, and 13, Galdo in view of Huang teaches the independent claim 1.
Galdo in view of Huang does not teach wherein, after receiving the second provisioning data, the operations comprise creating the instance of the digital key based at least in part on the first provisioning data and the second provisioning data.
However, in the related art, Chazot teaches wherein, after receiving the second provisioning data, the operations comprise creating the instance of the digital key based at least in part on the first provisioning data and the second provisioning data (Chazot: para[0039], “The host computer can generate second security data and generate a digital security key based on the first security data and the second security data. The host computer can transmit the second security data back to the wireless peripheral device. The wireless peripheral device can also generate the digital security key based on the second security data received from the host computer, as well as the first security data. As a result of the exchange of the first security data and the second security data, a shared digital security key can be generated and stored at each of the host computer and the wireless peripheral device”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Galdo with Chazot, it will improve security, a pairing process can be performed, over the wireless communication channel, between a wireless peripheral device and a host computer to enable the wireless peripheral device and the host computer to recognize each other. (Chazot para[02]).
Claims 14, 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Huang et al. (US-20150371234-A1; Hereinafter “Huang”) in view of Rodriguez et al. (EP 3 579 524 B1; Hereinafter “Rodriguez”).
As per claim 14, Huang teaches a host computer (Card Issuer server 110), comprising (Huang: fig. 1, para[29], “FIG. 1. The overall system 100 includes a MST 102, a mobile communication device 104, a wallet server 106, a provisioning and authentication server 108, a card issuer server 110,”):
an interface circuit configured to communicate with an electronic device, a verification computer and a partner computer (Huang: fig. 1, para[29], [61-63], “FIG. 1. The overall system 100 includes a MST 102, a mobile communication device 104, a wallet server 106, a provisioning and authentication server 108, a card issuer server 110,”);
a processor coupled to the interface circuit (Huang: para[96], “a microprocessor 1202, a light-emitting diode (LED) indicator 1204, a power source 1206, optionally a magnetic stripe reader (MSR) 1208, a memory storage component or secure element 1210, an input/output interface 1212”); and
memory, coupled to the processor, storing program instructions, wherein, when executed by the processor, the program instructions cause the host computer to perform operations comprising (Huang: para[96]):
receiving, associated with the electronic device, contact information and input data for a hash function (Huang: para [41-46], [62-66], “Upon a user request, the mobile communication device queries the MST the ID.sub.MST and session nonce R.sub.MST (402), and the MST sends the ID.sub.MST and R.sub.MST to the mobile communication device (404). With input from the user, the mobile communication device forwards this information to the wallet server, plus the user's credential (for example, ID.sub.MST, R.sub.MST, username, password) (406). The user may also input information (B*) for authenticating the user with the card issuer server (for example, the card issuer's identity and the user's online banking credential(s)).”);
performing a comparison operation based at least in part on an identifier of the electronic device and stored device information (Huang: para [42-46], [50], [62-66] “T, the wallet server authenticates the user using the username and password, and also checks to see if the ID.sub.MST is currently associated with the user's wallet account. The wallet server may verify the validity and monotonicity of KSN. The wallet server may also perform a check to ensure the data received is valid. For example, the wallet server may check that TRACK contains valid ISO-7812 strings.”), wherein the electronic device is pre-registered with the host computer (Huang: para[30-37], “the wallet server 106 may include one or more databases 116 and user accounts 118. The one or more databases 116 may store association data of the MST 102 and the user accounts 118, and one or more keys used by the MST 102 and/or the wallet server 106. The MST 102 may be registered with a user account 118…. a user may set up the user account 118 on the wallet server 106,”) and stored information comprises pre-registration information associated with the electronic device (Huang: para[30-37], [62-66]“ The wallet server performs one or more validations (624)…If everything validates or check out, the wallet server retrieves the K.sub.MST corresponding to ID.sub.MST, and generates a permission cryptogram, including {DD, R.sub.MST}K.sub.MST. The wallet server returns this permission to the mobile communication device (626).”, Huang discloses that the wallet server stores information necessary to retrieve a device specific master key (KMST) corresponding to the IDMST after registration accordingly, Huang teaches stored information comprising pre-registration information associated with electronic device);
when there is a match between the identifier and the stored device information, considering the electronic device to be verified (Huang, para [42-44], [50], [62], “the wallet server authenticates the user using the username and password, and also checks to see if the ID.sub.MST is currently associated with the user's wallet account. The wallet server may verify the validity and monotonicity of KSN. The wallet server may also perform a check to ensure the data received is valid.”);
providing, addressed to the partner computer, the hashed contact information and a request for the provisioning data (Huang: para[66-67], “the wallet server sends a request for provisioning to the provisioning and authentication server (710). The request may include the PAN and auxiliary information, such as a CVV-2, name, date of birth, answer to a challenge question, and/or other information.”, para[90], “the PAN (or hash of the PAN) may be used as an identifier in the provisioning and authentication server”);
selectively receiving, associated with the partner computer, the provisioning data (Huang: para[66-71], “The provisioning and authentication server generates a random key (K.sub.dCVV) for the card (712), and inserts in its database a 3-tuple of: {PAN, K.sub.dCVV, T.sub.stamp} (as described above with reference to FIG. 5). The provisioning and authentication server sends the K.sub.dCVV to the wallet server, optionally along with the auxiliary information B* (714).”); and
selectively providing, addressed to the electronic device, the provisioning data (Huang: para[66-67], “The wallet server retrieves the MST's K.sub.MST from ID.sub.MST, and sends K.sub.dCVV and SYNC (where SYNC contains the time-stamp information, and is used to synchronize time between the MST and the wallet server) to the mobile communication device (716”).
Although Huang teaches sending a hash PAN to the provisioning server, Huang does not explicitly teach that the hash Pan is generated when the electronic device is considered to be verified.
However, in the related art, Rodriguez teaches when the electronic is considered to be verified: generating a hashed version of the contact information based at least in part on the input data and the hash function (Rodriguez: para[131-133], “A copy of the credential can then be created as and when it is needed, for instance to determine whether a credential presented to the system matches the original (access to the published profile may only be granted if this is the case). The seed and metadata may be hashed a random number of times, and the stored ingredients then include this random number as well. Where the metadata comprises a device ID to the profile may only be granted if the credential is presented along with a matching device ID. Thus, use of the credential is restricted to that device for added security (if the user wishes to use multiple devices to assert their identity, they can request a separate credential for each device, each credential bound to the profile)”);
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Huang with Rodriguez, it will protect device identifiers bind provisioning data to a verified electronic device, and reduce the risk of fraudulent provisioning(Rodriguez: para[85]).
As per claim 16, Huang in view of Rodriguez teaches the independent claim 14. Rodriguez teaches wherein the contact information comprises at least one of a telephone number or an email address (Rodriguez: “Name of Company: Address of Company: Contact: First Name Last Name Email Address: (x2) Phone Number: Employee Start Date: Day (option) Month & Year (mandatory) Employee End Date: Day (option) Month & Year (mandatory) Annual Salary:”).
As per claim 17, Huang in view of Rodriguez teaches the independent claim 14. Huang teaches wherein the input data comprises a random or pseudorandom data (Huang: para[41], “The mobile communication device queries the MST for its identifier (ID.sub.MST) and session nonce R.sub.MST (308)”).
As per claim 18, Huang in view of Rodriguez teaches the independent claim 14. Huang teaches wherein the partner computer is associated with a manufacturer that provides an instance of a digital key (Huang: para[38], “In this aspect, the POS may also communicate with one or more of the wallet server 106, provisioning and authentication server 108, card issuer server 110, and/or the acquirer server 112, via the network 114.”).
As per claim 19, Huang in view of Rodriguez teaches the independent claim 14. Huang teaches wherein the instance of the digital key comprises a digital car key or a digital lock key (Huang: para [34], “Once the user is logged in, the personal PIN may be used to enter a payment card section of the wallet application, as well as to unlock the wallet application..”).
As per claim 20, Huang in view of Rodriguez teaches the independent claim 14. Huang teaches wherein the host computer, the verification computer, or both are associated with a manufacturer or a provider of the electronic device (Huang: para[102], “The devices, systems, and methods provide for the remote loading and transmission of card data from a card issuer to the wallet server provider”).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Huang et al. (US-20150371234-A1; Hereinafter “Huang”) in view of Rodriguez et al. (EP 3 579 524 B1; Hereinafter “Rodriguez”) and Li et al. (US 20220294778 A1; Hereinafter “Li”).
As per claim 15, Huang in view of Rodriguez teaches the independent claim 14.
Li teaches wherein the operations comprise, when there is not a match between the identifier and the stored device information, providing a request, addressed to the verification computer, with a one-time password to be provided to the electronic device, and receiving, associated with the electronic device, the one-time password that is then used by the host computer to verify the electronic device (Li: para[83-90], “the one or more processors determine when the candidate UDP factor matches an authentication UDP factor associated with the user's account. For example, the one or more processors may generate an authentication password hash based on an account authentication password in the factors, and declare the i) validation valid when the candidate password hash matches the authentication password hash. When a match occurs, flow moves to 510; otherwise flow moves to 512. …At 512, the one or more processors validate a candidate time-based one-time password (TOTP) factor by identifying, from the image data, a second MGI code displayed on the trusted computing device, the second MGI code representative of the candidate TOTP factor. The one or more processors determine when the candidate TOTP factor matches an authentication TOTP factor. For example, the one or more processors generate the authentication TOTP factor based on a time authentication factor and a pre-shared key, and declare the ii) validation valid when the candidate TOTP factor matches the authentication TOTP factor. When a match occurs, flow moves to 514; otherwise flow moves to 516.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Huang with Li, it will control and protect information provided to these outside parties, and to facilitate business (Li: para[02]).
Conclusion
THIS ACTION IS MADE FINAL. 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 LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Alexander Lagor can be reached on (571)-270-5143. 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.
/L.L.N./Examiner, Art Unit 2437
/MENG LI/Primary Examiner, Art Unit 2437