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 .
Priority
This Application claims priority to a German application # DE102022002638.4 dated 07/19/2022.
DETAILED ACTION
This Office Action is in response to an Amendment Application received on 07/27/2026. In the Application, claims 10 and 13 have been amended. Claims 11-12, and 14-18 remain original. Claims 1-9 remain cancelled. No further claim has been cancelled, and no new claim has been added.
For this Office Action, claims 10-18 have been received for consideration and have been examined.
Response to Arguments
Claim Objections
Applicants’ amendments to claims 10 and 13 have been reviewed and amendments have overcome the claim objections. Therefore, this objection has been withdrawn.
Claim Rejections – 35 USC § 112
Applicants’ remarks regarding rejection of claims under 35 USC § 112(a) & (b) have been reviewed, and remarks have overcome the raised rejections. Therefore, this rejection has been withdrawn.
Claim Rejections – 35 USC § 101
Applicants’ remarks that amended claims do not recite an Abstract Idea, Examiner respectfully disagree. After detailed review, the amended claim limitations still recite an abstract idea. Claims 10–14 and 16–18 recite methods and therefore fall within the statutory category of a process under 35 U.S.C. § 101. Accordingly, the analysis proceeds to Step 2A.
Independent claim 10 recites, reading an identifier from a control device of a vehicle; transmitting and storing the identifier; transmitting the identifier from the vehicle to an OEM computing device; transmitting the identifier from the OEM computing device to a service-provider computing device; saving the identifier; linking the identifier to a user account; receiving the identifier when the vehicle approaches a toll system; granting the vehicle access to a toll route; and billing the associated user account for such access.
The above concepts recite the concept of using identification information associated with an account to authorize access to a service and conduct a corresponding commercial transaction, including charging the account for the provided service.
Dependent claims 11–14 and 16–18 do not remove the claims from the identified judicial exception.
Claim 15 recite an eligible subject matter which requires the vehicle-internal computing unit reads the first identifier and a timestamp into a hash function; the hash function creates a hash value; the hash value and timestamp are transmitted to the central OEM computing device; and the central OEM computing device performs the claimed corresponding processing using the hash value and timestamp.
Unlike the limitations of claims 10–14 and 16–18, these limitations recite a particular data-processing/security mechanism governing the manner in which identifying information is processed and communicated between the vehicle and the OEM computing device.
When considered in the context of the claimed system and the disclosure of the specification, these limitations provide a more specific technological implementation of the transmission and processing of vehicle-identification information rather than merely using generic computing components to perform the identified commercial transaction.
Therefore, claim 15 is not rejected under 35 U.S.C. § 101 on the present record.
Applicant is advised that amendment of the rejected claims to incorporate appropriate limitations corresponding to the technical processing recited in claim 15 may overcome the rejection under 35 U.S.C. § 101, provided that the amended claim, when considered as a whole, integrates the judicial exception into a practical application or otherwise amounts to significantly more than the judicial exception.
Claim Rejections – 35 USC § 102
Applicants’ amendments to claim 10 has been reviewed and amendments have overcome the 35 USC § 102 rejection. Therefore, this rejection has been withdrawn. However, upon further consideration, the claims are rejected under obviousness rejection. See Office Action for details.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 10–14 and 16–18 are rejected under 35 U.S.C. § 101 because the claimed inventions are directed to a judicial exception, i.e., an abstract idea, without additional elements sufficient to integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
Claim 15 is not included in this rejection for the reasons discussed below.
Step 1 — Statutory Category
Claims 10–14 and 16–18 recite methods and therefore fall within the statutory category of a process under 35 U.S.C. § 101. Accordingly, the analysis proceeds to Step 2A.
Step 2A, Prong One — Judicial Exception
Independent claim 10 recites, inter alia:
reading an identifier from a control device of a vehicle;
transmitting and storing the identifier;
transmitting the identifier from the vehicle to an OEM computing device;
transmitting the identifier from the OEM computing device to a service-provider computing device;
saving the identifier;
linking the identifier to a user account;
receiving the identifier when the vehicle approaches a toll system;
granting the vehicle access to a toll route; and
billing the associated user account for such access.
The foregoing limitations, considered together, recite the concept of using identification information associated with an account to authorize access to a service and conduct a corresponding commercial transaction, including charging the account for the provided service.
The recited concept falls within the “certain methods of organizing human activity” grouping of abstract ideas, particularly commercial interactions, because the claim uses identifying/account information to authorize a user's access to a toll-based service and subsequently bills the user's account for that service.
Although claim 10 performs various information-processing operations in connection with the commercial interaction—such as reading, storing, transmitting, receiving, and associating identifying information, these operations facilitate the underlying commercial arrangement of identifying an account, authorizing access to a toll service, and charging the account for the provided access.
Accordingly, claim 10 recites an abstract idea within the certain-methods-of-organizing-human-activity grouping.
Dependent claims 11–14 and 16–18 do not remove the claims from the identified judicial exception.
Claim 11 further specifies that the first identifier is read and stored during production of the vehicle. This limitation specifies the time at which the identification information is collected and stored but does not alter the underlying abstract commercial interaction.
Claim 12 similarly specifies that the first identifier is read and stored during the service life of the vehicle. This limitation merely specifies when the information is obtained and stored.
Claim 13 further recites displaying the first identifier and requiring confirmation through a user control action before the identifier or transmission order is transmitted. These limitations amount to presenting information to a user and obtaining user authorization before proceeding with the transaction and do not materially alter the identified abstract idea.
Claim 14 further recites transmitting user data together with the first identifier from the OEM computing device to the service-provider computing device. This limitation constitutes the collection and communication of additional information used in connection with the identified commercial interaction.
Claim 16 further recites reading a second identifier from the control device and transmitting that identifier through the vehicle-internal computing unit to the OEM computing device. This limitation similarly concerns the collection and transmission of additional identifying information.
Claim 17 further recites transmitting the second identifier to the service-provider computing device and using the second identifier as an authentication feature of a user. This limitation uses identifying information to authenticate a participant in the transaction and therefore further facilitates the authorization of the commercial interaction.
Claim 18 further specifies that the second identifier is used for multi-factor authentication. This limitation further specifies the manner in which the user's identity is authenticated in connection with the transaction.
Accordingly, claims 10–14 and 16–18 recite a judicial exception under Step 2A, Prong One.
Step 2A, Prong Two — Practical Application
The claims are next evaluated to determine whether the additional elements, individually and in combination, integrate the identified judicial exception into a practical application.
Claim 10 additionally recites a vehicle control device, a vehicle-internal computing unit having persistent storage, a central OEM computing device operated by the vehicle manufacturer, a central service-provider computing device, a cryptographically secure transmission channel, wireless communication, and a stationary toll system.
These additional elements provide the technological environment in which the abstract commercial interaction is carried out. The vehicle-internal computing unit and central computing devices perform the functions of receiving, storing, and transmitting information; the communication channel communicates the identifying information; and the stationary toll system receives the identifier and implements the resulting access authorization.
Considered individually, these elements do not reflect an improvement to the functioning of a computer or another technology. Rather, the computing and communication components are used as tools to implement the identified account association, authorization, and billing process.
Considered in combination, the additional elements likewise do not impose a meaningful limit on the identified judicial exception. The claim uses the recited computing, storage, wireless communication, and toll-system components to acquire and communicate the information necessary to perform the commercial transaction and to implement the resulting authorization.
The recitation that the transmission channel is “cryptographically secure,” without further reciting in claim 10 a particular technological mechanism by which that security is achieved, does not itself provide a specific improvement to computer or communications technology.
Likewise, the dependent limitations of claims 11–14 and 16–18 specify when information is collected, what additional information is communicated, whether user authorization is obtained, or whether additional identification information is used for authentication, including multi-factor authentication. These limitations further facilitate the identified transaction but do not, as presently claimed, provide a specific improvement to the operation of the computing devices, communication network, vehicle control device, or toll system.
Accordingly, considering the additional elements both individually and as an ordered combination, claims 10–14 and 16–18 do not integrate the judicial exception into a practical application.
The claims are therefore directed at the judicial exception under Step 2A.
Step 2B — Significantly More
The claims are further evaluated to determine whether any additional element, or combination of additional elements, amounts to significantly more than the identified abstract idea.
The recited computing devices, persistent storage, server devices, wireless communications, transmission of data, display apparatus, user input, authentication, and toll-system components perform their ordinary functions of receiving, storing, transmitting, displaying, and processing information in implementing the claimed commercial transaction.
The claims do not presently recite a particular unconventional architecture, processing technique, or other technological implementation that transforms the abstract commercial interaction into patent-eligible subject matter.
Considered as an ordered combination, the additional limitations likewise amount to implementing the identified authorization and billing process using the recited vehicle, server, communication, and toll-system infrastructure. The ordered combination therefore does not provide an inventive concept sufficient to transform the identified abstract idea into patent-eligible subject matter.
Accordingly, claims 10–14 and 16–18 are directed to an abstract idea without significantly more and are therefore ineligible under 35 U.S.C. § 101.
Claim 15 — Eligible Subject Matter / Potential Amendment
Claim 15 is not included in the present rejection.
Claim 15 further requires that:
the vehicle-internal computing unit reads the first identifier and a timestamp into a hash function;
the hash function creates a hash value;
the hash value and timestamp are transmitted to the central OEM computing device; and
the central OEM computing device performs the claimed corresponding processing using the hash value and timestamp.
Unlike the limitations of claims 10–14 and 16–18, these limitations recite a particular data-processing/security mechanism governing the manner in which identifying information is processed and communicated between the vehicle and the OEM computing device.
When considered in the context of the claimed system and the disclosure of the specification, these limitations provide a more specific technological implementation of the transmission and processing of vehicle-identification information rather than merely using generic computing components to perform the identified commercial transaction.
Therefore, claim 15 is not rejected under 35 U.S.C. § 101 on the present record.
Amendment Recommendation
Applicant is advised that amendment of the rejected claims to incorporate appropriate limitations corresponding to the technical processing recited in claim 15 may overcome the rejection under 35 U.S.C. § 101, provided that the amended claim, when considered as a whole, integrates the judicial exception into a practical application or otherwise amounts to significantly more than the judicial exception.
For example, incorporation of limitations directed to processing the first identifier and timestamp using the claimed hash function, generating the hash value, communicating the hash value and timestamp between the vehicle-internal computing unit and OEM computing device, and performing the corresponding processing at the OEM computing device may provide a specific technological implementation sufficient to distinguish the amended claim from merely performing the identified account-association, authorization, and billing concept using generic computing and communication components.
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 10, and 12-14, and 16-18 are rejected under 35 U.S.C. §103 as being unpatentable over Mack et al. (US 2020/0327218 A1; hereinafter “Mack”) in view of Templ et al. (US 2013/0293349 A1; hereinafter “Templ”).
Regarding claim 10, Mack teaches a method involving authentication of a vehicle using a vehicle-side authentication unit, a vehicle component/control unit, a central computer external to the vehicle, and a service unit.
Mack teaches reading a first identifier from a control device of a vehicle, wherein a request command is supplied to a vehicle interface and executed by a vehicle component, such as an engine controller, which outputs a characteristic value such as an identification number of the engine control unit (Mack, ¶¶ [0024]-[0028]; see also disclosure corresponding to vehicle component 10 and characteristic value 7).
Mack further teaches transmitting the identifier to a vehicle-internal computing/authentication unit, because the identification/characteristic value output by the vehicle component is received through the vehicle interface by the vehicle authentication unit. Mack further teaches storage of vehicle-related values and request information within the authentication unit and central computer architecture.
Mack teaches transmitting vehicle identification information from the vehicle to a central computer external to the vehicle. In particular, the authentication unit transmits the characteristic value to the central computer, and the central computer receives and stores the characteristic value in a characteristic-value table (Mack, ¶¶ [0028]-[0032]; see also ¶¶ [0100]-[0103]).
Mack additionally teaches secure communication between the vehicle/service infrastructure and the central computer. Mack explains that communication between the central computer and service unit may occur through an encrypted secure communication connection and that additional communication may be established between the vehicle authentication unit and central computer (Mack, ¶¶ [0110]-[0112]).
Mack further teaches that a user may initiate or authorize the service. A vehicle occupant enters a predetermined user input at an input unit, which may be a vehicle console, smartphone, tablet, or laptop, and a coupling/activation signal is transmitted to the central computer (Mack, ¶¶ [0092]-[0095]; see also ¶¶ [0079]-[0086]).
Mack further teaches a central computer communicating authorization information with a service unit, wherein the service unit may be a barrier, and the central computer transmits an enable signal permitting the requested service (Mack, ¶¶ [0013]-[0017], [0058]-[0068], [0107]-[0112]).
Mack therefore teaches the general architecture of:
vehicle control component → vehicle computing/authentication unit → central computer → service infrastructure, together with secure vehicle/service authentication and authorization.
Mack does not expressly teach that the service infrastructure is specifically a toll service provider and that the identifier is linked to a user account that is billed for access to a toll route.
Templ teaches these remaining features.
Templ teaches an identification device containing information identifying a user and vehicle, transmitting that information to an authentication device and associating access rights or privileges with the user after verification. Templ further teaches transmitting vehicle/user identification information to a verification system and receiving an authentication response.
More particularly, Templ expressly teaches that the authentication device may be part of a toll collection station, that vehicle/user identifiers are transmitted to the authentication device, and that the toll station authenticates the vehicle and user. Templ further teaches determining the route driven by the vehicle and calculating tolls based upon the route and driver information (Templ, ¶¶ [0107]-[0108]).
Templ additionally teaches forwarding a verified user/vehicle identifier to a billing system, wherein the billing system receives the verified identifier and bills the user (Templ, ¶¶ [0109]-[0110]).
Templ also teaches granting access after successful verification. For example, upon determining that the user is authorized to pass a gate with the identified vehicle, an authentication response is provided and the gate is opened (Templ, ¶¶ [0105]-[0106]).
Therefore, Templ teaches or suggests:
associating vehicle identification information with a user;
wirelessly obtaining vehicle/user identification at an authentication or toll station;
granting access based upon successful authentication;
operating the system in a toll-collection environment; and
transmitting verified identification information for billing the identified user.
It would have been obvious to one of ordinary skill in the art before the effective filing date to employ Mack's centralized vehicle authentication architecture for the toll and billing application taught by Templ. Mack expressly contemplates vehicle authentication for service units such as barriers, while Templ expressly teaches using vehicle/user identification for toll collection, access authorization, and billing.
One of ordinary skill would have been motivated to combine the references to provide centralized, secure authentication of a vehicle for automated toll access and billing, thereby avoiding separate manual identification and payment procedures while using the existing vehicle identification and central authentication infrastructure.
Accordingly, Mack in view of Templ teaches or suggests all limitations of claim 10.
Regarding claim 12, Mack teaches querying a vehicle component during operation of the authentication system, receiving the resulting characteristic/identification value through the vehicle interface, and using the value in subsequent authentication processing.
Mack therefore teaches obtaining the identifier from the vehicle component after the vehicle authentication architecture has been established and during use of the vehicle.
It would have been obvious to store such acquired identification information persistently so that the information need not be repeatedly obtained from the control unit each time the service is invoked.
Regarding claim 13, Mack teaches an input unit that may comprise a console of the vehicle, smartphone, tablet, or other user device. Mack further teaches displaying a warning/query to the user and transmitting an activation signal to the central computer only after the user performs the predetermined input. The disclosure specifically contemplates a touch-sensitive display through which the user performs the activation input.
Thus, Mack teaches requesting user authorization through a user interface before activating a vehicle-related service.
It would have been obvious to display the identifier or information identifying the requested service before obtaining the user's confirmation so that the user can verify the information that is to be transmitted. Such modification represents the predictable use of Mack's disclosed user confirmation interface for confirming the vehicle identification information involved in the requested service.
Regarding claim 14, Mack teaches that the coupling signal may contain registration data of the user and/or information about the vehicle and/or authentication unit.
Templ similarly teaches transmitting information identifying both the user and vehicle to the authentication/verification infrastructure and using the resulting verified user/vehicle identity for access and billing.
It would therefore have been obvious to transmit user data together with the vehicle/control-device identifier to the service-provider computer because the service provider requires sufficient information to associate the authenticated vehicle identifier with the appropriate user for authorization and billing.
Regarding claim 16, Mack teaches using multiple values for authenticating the vehicle and authentication unit. In addition to the characteristic/vehicle identification value, Mack teaches an identification value uniquely associated with the authentication unit, generating an identification check value therefrom, and transmitting that identification check value together with the vehicle check value to the central computer.
Mack therefore teaches using multiple identifiers/authentication values originating from the vehicle-side authentication architecture and transmitting them to the central computer.
Further, Templ teaches combined user and vehicle identifiers and expressly recognizes that combining multiple identification codes provides increased security.
It would have been obvious to obtain and transmit an additional identifier associated with the vehicle control/authentication device in order to provide an additional basis for authenticating the particular device and vehicle.
Regarding claim 17, Templ expressly teaches using multiple identification values, including a user ID and vehicle ID, to authenticate a user/vehicle combination and transmitting the identification information through an authentication device to a verification system.
Templ further teaches that successful authentication associates access rights and privileges with the user and that the verified user/vehicle identification may subsequently be forwarded to a billing system.
It would therefore have been obvious to use Mack's additional identification value as an authentication feature in Templ's service-provider authentication process and to transmit that value to the service-provider infrastructure to provide additional assurance that the user/device requesting the service is authorized.
Regarding claim 18, Templ expressly teaches combining car and personal identification (i.e. Multifactor authenticaiton) to obtain an additional degree of security. Templ explains that requiring both identification codes increases security and further teaches dynamically combining several identification codes.
Thus, although Templ does not necessarily employ the modern phrase “multi-factor authentication” for every embodiment, Templ teaches authentication using multiple independent identification values associated with the vehicle and user.
Mack likewise teaches authenticating using multiple values, including a vehicle characteristic/check value, an identification value uniquely associated with the authentication unit, and shared-secret/session values.
It would have been obvious to one of ordinary skill in the art to use the second identifier of claim 17 as an additional authentication factor in combination with the first/user identifier because Templ expressly teaches that combining vehicle and personal identification provides an additional degree of security.
The use of the second identifier as an additional authentication factor therefore represents the predictable application of Templ's multiple-identification authentication technique to Mack's multiple vehicle/device identifiers
Claim 15 rejected under 35 U.S.C. §103 as being unpatentable over Mack et al. (US 2020/0327218 A1; hereinafter “Mack”) in view of Templ et al. (US 2013/0293349 A1; hereinafter “Templ”) and further in view of Dechgan et al., (US 2020/0266990 A1).
Regarding claim 15, Mack already teaches applying a predetermined check-value function to a vehicle identification value, wherein the check-value function may specifically comprise a hash function. Mack teaches transmitting the resulting vehicle check value to the central computer and using the same predetermined check-value function at the central computer to generate a corresponding check value for comparison.
Mack therefore teaches the underlying architecture of:
vehicle identifier → hash/check function → transmitted check value → central computer → corresponding check-function processing.
Mack does not expressly teach incorporating a timestamp into that hash processing.
Dechgan teaches secure communications between a vehicle device and backend server using time-dependent cryptographic credentials.
Dechgan teaches generating a single-use credential based upon a shared key and time value. Dechgan further teaches attaching a timestamp to a transmitted message and using the timestamp in calculating the expected credential value at the receiving computing device.
Dechgan explains that TOTP techniques use a Unix timestamp as a seed value for an encryption hash (Dechgan, ¶¶ [0036]-[0038]; FIG. 4).
It would have been obvious to modify Mack's hash-based vehicle authentication technique to additionally incorporate Dechgan's timestamp into the hash/check-value generation and transmit the timestamp with the resulting value.
One of ordinary skill would have been motivated to do so because Dechgan expressly teaches that time-dependent credentials improve the security of communications with vehicle devices by limiting the useful lifetime of authentication information and addressing unauthorized reuse/replay of credentials.
Thus, the combination would predictably provide increased security for transmission of Mack's vehicle identification/authentication information.
Claim 11 rejected under 35 U.S.C. §103 as being unpatentable over Mack et al. (US 2020/0327218 A1; hereinafter “Mack”) in view of Templ et al. (US 2013/0293349 A1; hereinafter “Templ”) and further in view of Tanaka., (US 2004/0010322 A1).
Regarding claim 11, Mack in view of Templ teaches the method of claim 10 substantially as set forth above, including obtaining an identifier associated with a vehicle control device, communicating the identifier through a vehicle-internal computing/authentication architecture, and subsequently using vehicle/user identification information for service authorization and billing.
Mack in view of Templ does not expressly disclose that the first identifier is read from the control device and persistently stored in the vehicle-internal computing unit specifically during production of the vehicle.
Tanaka teaches this limitation.
Tanaka teaches a vehicle control system comprising a plurality of electronic control units (ECUs) connected through a communication line, wherein each ECU includes a communication circuit, a microcomputer, and a non-volatile memory for persistently storing identification information. See Tanaka, US 2004/0010322 A1, disclosure corresponding to the vehicle control system 10, ECUs 20, 30 and 40, communication line 60, and non-volatile memory 23.
Tanaka further teaches that each ECU transmits its own identification information (ID code) to the other vehicle ECUs and receives the identification information transmitted from the other ECUs. The received ID codes are stored in an identification-information table in the non-volatile memory. Thus, an identifier originating from one vehicle control device is communicated to and persistently stored by another vehicle-internal computing/control unit.
Tanaka further expressly teaches that the ID code initially stored in the identification-information table is the ID code provided at the time of assembly or shipment in the vehicle manufacturing factory. Tanaka additionally explains that the operation for storing the ID codes is performed at the time of first energization in assembling or shipping the vehicle. During this operation, the ID code of an ECU is transmitted to the other ECUs, the ID codes transmitted from the other ECUs are received, and the received ID codes are stored in the identification-information table of the non-volatile memory.
Accordingly, Tanaka teaches or suggests reading/receiving an identifier from a vehicle control device during production of the vehicle and saving that identifier in persistent, non-volatile storage of another vehicle-internal computing unit during production of the vehicle, as required by claim 11.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the vehicle authentication arrangement of Mack, as modified by Templ, to acquire and persistently store the control-device identifier during vehicle production in the manner taught by Tanaka.
One of ordinary skill in the art would have been motivated to make such a modification because Tanaka teaches that exchanging and persistently storing the identifiers of the installed vehicle control units during initial vehicle assembly permits the vehicle control units to share the identification information from the vehicle's initial configuration. Such an arrangement would predictably ensure that the identifier required by Mack's subsequent vehicle authentication procedure is already reliably associated with and available within the vehicle computing system before the vehicle enters service.
The proposed modification merely applies Tanaka's known technique of acquiring and persistently storing ECU identification information during vehicle assembly to Mack's vehicle identification/authentication architecture for the predictable purpose of establishing the vehicle's control-device identification information during manufacture.
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 SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6:00 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, William Korzuch can be reached at 571-272-7589. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491
Prosecution Insights