DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to claim amendments and remarks filed by Applicant’s representative on April 2, 2026. Claims 1-20 are pending, no claims have been canceled, and no new claims have been added.
Claim Objections
Claim(s) 4-7, 11-14 & 18-20 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Amendments and Remarks
Applicant’s latest filed claim amendments and corresponding remarks dated April 2, 2026 have been received and fully considered. Applicant’s remarks and/or comments are generally directed to the current claim amendment(s), and accordingly deemed moot in light of the new grounds of rejection provided with this action.
With regards to Applicant’s latest amendments and remarks, Applicant firstly notes and remarks that the independent claim(s), and particularly independent claim 1, has been further amended to now expressly recite
“A method comprising:
receiving, by a virtual conference provider from a first client application used by a
first participant and executed within a virtual desktop ("VD") environment, a first request to join a meeting hosted by the virtual conference provider,
providing, by the virtual conference provider to the first client application, network
information and meeting information associated with the meeting;
connecting, by the virtual conference provider, the first client application to the
meeting using a first connection;
receiving, by the virtual conference provider from a second client application
executed by a client device used by the first participant, a second request to join the
meeting, the second request comprising at least a subset of the meeting information,
connecting, by the virtual conference provider, the second client application to the meeting based on the at least the subset of the meeting information using a second
connection, the first client application and the second client application both corresponding to the first participant;
associating the first connection and the second connection with the first participant;
receiving, by the virtual conference provider, first meeting signaling information
from the first client application and one or more first multimedia streams from the second client application; and
providing, by the virtual conference provider, second meeting signaling information to the first client application and one or more second multimedia streams to the second client application”.
With respect to the above, Applicant notes and remarks that none of the prior art reference(s) applied in rejecting independent claim 1 [Chen et al, Moran et al], either individually or in combination with other prior art disclosures, expressly and properly discloses or suggests the above amended claim feature(s) or limitation(s) of receiving, by a virtual conference provider from a ‘first client application used by a first participant’ and executed within a virtual desktop ("VD") environment, a first request to join a meeting hosted by the virtual conference provider’, as well as the feature of receiving, by the virtual conference provider from a second client application executed by a ‘client device used by the first participant’, a second request to join the meeting, the second request comprising at least a subset of the meeting information -- as currently recited by amended independent claim 1 above (and similarly in independent claims 8 & 15).
In particular, Applicant notes or remarks that amended Claim 1 is explicit that the requests are sent from ‘two different client application used by the same participant’: "a first client application used by a first participant" and "a second client application executed by a client device used by the first participant." Thus, the two requests to join the meeting are for the same participant – and neither Chen nor Moran discloses or make obvious such functionality. Applicant secondly notes and remarks that Chen does not disclose ‘two different client applications used by the same participant’ joining the same meeting, and thus cannot describe associating connections established by those requests. Applicant further remarks that Chen does not disclose any capability to receive signaling information to one client application and multimedia streams from another application, where both applications are used by the same individual [Applicant Remarks: par 5, pg. 8 – par 2, pg. 9]. Accordingly, Applicant remarks that the amended independent claims are distinguishable from the applied prior art and/or prior art combination(s) used to reject the claims, and that the respective dependent claims are also distinguishable by virtue of their dependency on their respective parent independent claims.
However, in response to Applicant’s amended feature and associated remarks, the Office asserts and notes that the newly amended feature(s) and described elements are now expressly taught or disclosed in view of teachings and/or disclosures by at least Wang et al, as discussed / cited with this action. Wang also cures and resolves any deficiencies of Chen and Moran noted by Applicant above, as discussed below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) 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.
Claim(s) 1, 2, 8, 9, 15, 16 is/are rejected under 35 U.S.C. 103 as being disclosed by Chen et al (hereinafter Chen), Foreign Patent Pub CN112288404A (publication date January 2021) in view of Moran et al (hereinafter Moran), US Patent 7653013 B1 (publication date January 2010) and in further view of Wang et al (hereinafter Wang), US Patent Publication US 20190026121 A1 (publication date January 2019).
As per claim{s} 1, 8, 15, Chen discloses a method comprising:
receiving, by a virtual conference provider (Chen: e.g., Conference System {of a 3rd Party} / ‘Cloud desktop’ of the Virtual Desktop Platform including ‘Conference System’ Management function / software ) [pg. 2, par 2-3] [pg.6 par 9] (e.g., ‘Conference Management Device’ ) [pg. 4 par 4] from a first client application (Chen: e.g., Virtual Desktop Client [VDC]) [pg. 6, par 9] [pg. 2, par 2-3] and executed within a virtual desktop (“VD”) environment (Chen: e.g., Virtual Desktop Platform [VDP] ) [pg. 6, par 9] [pg. 2, par 2-3], a first request to join a meeting hosted by the virtual conference provider (Chen: e.g., after step S120, executing step S130: the virtual machine corresponding to the first user sends the ‘invitation link’ address to the client of the second user {invited user / recited ‘first participant’ } corresponding to the invited user identification; the invitation link address is used for ‘inviting the second user’ to access the cloud desktop of the first user, and adding the virtual conference created on the cloud desktop…The ‘second user’ refers to the ‘invitee’ {invited user / recited ‘first participant’ } of the virtual conference, specifically for example: {the 2nd User} can be the ‘participant’ to participate {join} in the virtual conference, and the second user can access the cloud desktop of the first user by ‘clicking’ the invitation link address {accepting the ‘invite’ to ‘participate’ / join in the virtual conference of the 1st User / virtual conference Host / initiator}, and adding the virtual conference created on the cloud desktop) [pg. 11 par 3-4; Fig. 5]; and
providing, by the virtual conference provider to the first client application, network information and meeting information associated with the meeting (Chen: e.g., expressly discloses in one aspect obtaining the ‘virtual machine identifier’ corresponding to the cloud desktop of the first user, assuming that the virtual machine identifier of the cloud desktop of the first user is ‘1.1.1.1’. The ‘invitation link address’ can be “http: // 1.1.1.1/” wherein the ‘invite’ is the link address of the invitation interface…In the second embodiment, according to / or using the ‘cloud desktop identification of the first user’ and ‘other information’ to generate the ‘inviting link address’…For example: supposing the segmentation symbol is &; and the virtual machine identifier of the cloud desktop of the first user is ‘1.1.1.1’, then the ‘invitation link address’ can be “http: // 1.1.1.1/ [uid=2&cid=3”, wherein the parameter uid= 2 represents the ‘invited User Identification’ is ‘2’, cid=3 represents the ‘Conference Identification’ is ‘3’, it also can according to the specific actual condition comprises more ‘other information’ ) [pg. 10 par 7 – pg. 11 par 1; Fig. 5];
connecting, by the virtual conference provider, the first client application to the meeting using a first connection (Chen: e.g., after step S120, executing step S130: the virtual machine corresponding to the first user sends the ‘Invitation link address’ to the client of the Second User corresponding to the invited user identification; the invitation link address is used for inviting the second user to access the cloud desktop of the first user, and adding the virtual conference created on the cloud desktop…the second user refers to the invitee of the virtual conference, specifically for example: can be the participant to participate in the virtual conference, the second user can access the cloud desktop of the first user by ‘clicking the invitation link address’, and ‘adding the virtual conference’ {accessing / joining the virtual conference} created on the cloud desktop…The embodiment of the above step S130 is as follows: the virtual machine corresponding to the first user sends the inviting link address to the client of the second user corresponding to the invited user identifier through the HTTP protocol or HTTPS protocol; the client of the second user after receiving the invitation link address sent by the virtual machine corresponding to the first user; displaying the invitation confirmation message to the second user, so that the second user after reading the invitation confirmation message, making the selection of ‘accepting invitation’ or refusing invitation, or ‘directly clicking the invitation link address’, representing ‘acceptance’ of the invitation of the first user; wherein the ‘invitation link address’ is used for inviting the second user to access the cloud desktop of the first user, and adding {the Second User to the} ‘virtual conference’ created on the cloud desktop {equivalent to the ‘first connection’ to the virtual conference executed on a Virtual Desktop Platform / Environment}) [pg. 11, par 3-5; Fig. 5] (e.g., the virtual machine of the first user in the virtual desktop platform sends the ‘conference invitation’ information (including the ‘invitation link address’) to the ‘client end of the Second user’ and the ‘client end of the Third user’; the client of the second user and the client of the third user respectively display the conference invitation information; the Second user and the Third user after ‘clicking’ to agree to add the button of the virtual conference, the client of the Second user and the client of the Third user through the interface of the virtual desktop platform is ‘added’ to the virtual conference; the virtual machine of the first user in the virtual desktop platform returns the information such as the address of the conference desktop to the client of the second user and the client of the third user respectively; the client of the second user and the client of the third user after receiving the information of the conference desktop address, the client of the second user and the client of the third user are connected with the virtual machine of the first user; after the ‘connection’ is successful, the second user and the third user can access the cloud desktop running in the virtual machine of the first user….In the realizing process, firstly using the virtual machine in the virtual desktop platform to process the conference request sent by the inviting user client, and creating a virtual conference and generating the conference invitation link according to the conference identifier, then sending the conference invitation link to the client corresponding to the invited user identifier in the conference request; so that the invited user can confirm the conference invitation link and ‘join the virtual conference’; so as to integrate the cloud conference management function on the basis of the ‘cloud {Virtual} Desktop solution’, forming an integrated solution, improving upon / eliminating the need for the user to independently deploy three-party conference system software which increases maintenance cost, improving authorization cost, compatibility and occupying additional resource and so on, at the same time, improving the user experience ) [pg. 12 par 2-pg. 13 par 1; Fig. 4];
receiving, by the virtual conference provider from a second client application executed by a client device , a second request to join the meeting, the second request comprising at least a subset of the meeting information; and connecting, by the virtual conference provider, the second client application to the meeting based on the at least the subset of the meeting information using a second connection, the first client application and the second client application both corresponding to the first participant (Chen: e.g., For example: the first user clicks to create a conference on the client, the client can create a virtual conference by invoking the interface of the virtual desktop platform, and return the conference identifier (i.e., conference ID); the first user clicks the inviting attendee on the client end, and selects the second user and the third user as the attendee; the conference request is initiated by invoking the interface of the virtual desktop platform; the ‘virtual machine of the first user in the virtual desktop platform’ sends the ‘conference invitation information’ (including the invitation link address) to the ‘Client end of the Second user’ {recited ‘first participant’} and the ‘Client end of the Third user’; the ‘client of the second user’ and the ‘client of the third user’ respectively display the conference invitation information; the second user and the third user after clicking to agree to add the ‘Button’ of the Virtual Conference, the ‘Client of the Second User’ and the ‘Client of the Third User’ through the interface of the Virtual Desktop Platform is “added” to the Virtual conference ) [pg. 12 par 2; Fig. 4] (e.g., a ‘client’ or client device, such as a ‘smart phone’, ‘personal computer’, ‘tablet computer’, ‘personal digital assistant’ or ‘mobile internet device’) [pg. 8, par 4; Fig. 2];
associating the first connection and the second connection with the first participant (Chen: e.g., the ‘conference request’ may include the ‘invited user information’ and the ‘conference information’: wherein, the ‘information of the invited user’ may include: ‘user identification’ {of the invited user}, nickname, name and gender information, and wherein the ‘conference information’ may include: ‘conference identifier’, ‘conference type’ and ‘conference location’ information ) [pg. 8 par 5 Fig. 2] (e.g., expressly teaches in one aspect that in the implementation process, by selecting the ‘invited user identifier’ to send the ‘inviting link address’ of the virtual conference {to the second user} according to the client endpoint of the first user, the ‘security’ of the ‘invited user’ {second user} to ‘join / participate’ in the ‘virtual conference’ {initiated by the first user} and ‘access’ the cloud desktop of the {first} user {for requesting virtual conference control ‘operations’ by the Second User during the virtual conference, such as ‘screen control’ or ‘microphone control’ during the virtual conference} is effectively improved ) [pg. 2 par 5 – pg. 3 par 3; pg. 4 par 4 – pg. 5 par 1].
But while Chen discloses substantial features of the invention above, he does not expressly disclose the additional recited feature{s} / limitation{s} of the method further comprising receiving, by the virtual conference provider, first meeting signaling information from the first client application and one or more first multimedia streams from the second client application; and providing, by the virtual conference provider, second meeting signaling information to the first client application and one or more second multimedia streams to the second client application.
However, in a related endeavor, Moran particularly discloses the additional recited feature{s} / limitation{s} of the method further comprising receiving, by the virtual conference provider, first meeting signaling information from the first client application and one or more first multimedia streams from the second client application; and providing, by the virtual conference provider, second meeting signaling information to the first client application and one or more second multimedia streams to the second client application (Moran: e.g., expressly teaches / discloses in one aspect that Multipoint Controller 34 instructs the Multipoint processor 36 to ‘initiate a conference’ (or if the terminal {i.e., Terminal 22} is ‘joining’ an existing conference, to ‘add the terminal to the conference’). The H.323 standard does not specify any mandatory requirements for the communication between the Multipoint controller and Multipoint processor, and in most cases, proprietary ‘Signalling’_48 will be employed for these communications. Alternatively, ‘H.248_signalling’ can be used…Once the Multipoint processor 36 has ‘added’ Terminal 22a to the conference, an ongoing ‘Media stream’_49 is established between the Terminal 22a and the Multipoint processor 36. This is a ‘two-way stream’ and may employ multiple media channels, such as ‘audio’, ‘video’, text and ‘data’ / file transfer…Additional Terminals 22b, 22c, 22d ‘joining’ the conference do so in the same manner as Terminal 22a. When the four terminals have joined, Multipoint processor 36 is communicating with each terminal via a 2-way multimedia stream 49…Multipoint processor 36 ‘receives the incoming multimedia stream 49 from each Terminal 22a-22d and processes it by separating the various media channels from each terminal, and mixes the signals as appropriate to generate an ‘outgoing multimedia stream’ to each Terminal ) [col 8, L26-47; Fig. 3].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify and/or combine Chen’s invention with the above said additional feature(s), as expressly disclosed by Moran, for the motivation of providing a conferencing method and system with ‘enhanced’ capabilities, wherein the conferencing system allows users / participants of the main conference and/or a subconference to utilize one or more ‘media types’ {audio, video, data, etc.}, and which in turn permits user of a subconference to actively or passively participate in the main conference using the at least one supported media type [Moran: Abstract, col 2, L14-21 & 36-42; Fig. 1].
Further, while the combination of Chen and Moran discloses substantial features of the invention above, they do not expressly disclose the additional recited feature{s} / limitation{s} of the method further comprising receiving, by a virtual conference provider ‘from a first client application used by a first participant’ and executed within a virtual desktop ("VD") environment, a first request to join a meeting hosted by the virtual conference provider, as well as the feature of receiving, by the virtual conference provider from a second client application executed by ‘a client device used by the first participant’, a second request to join the meeting…”.
However, in a related endeavor, Wang expressly discloses the additional recited feature{s} / limitation{s} of the method further comprising receiving, by a virtual conference provider ‘from a first client application used by a first participant’ and executed within a virtual desktop ("VD") environment, a first request to join a meeting hosted by the virtual conference provider (Wang: e.g., ‘Virtual Desktop Client Device’ _106 ) [0017; Fig. 1] (e.g., expressly teaches / discloses in one aspect that in some cases, users remotely accessing their virtual desktop need to utilize a multimedia device, such as a camera, microphone or audio speaker. For example, a user may wish to make a Voice Over IP (VOIP) telephone call, “join an online meeting or attend a video conference using their virtual desktop” (via the user’s ‘Virtual Desktop Client Device’}. If the user's client device is equipped with a multimedia accessory, the user may utilize Real Time Audio Video (RTAV), which is a feature offered by some virtual desktops. RTAV redirects the multimedia stream captured by the camera and/or microphone of the client device to the remote virtual desktop and makes it accessible to the virtual desktop as though the multimedia accessory was installed on the remote server. RTAV therefore requires the virtual desktop client device to have some form of multimedia capability. However, many client devices capable of establishing a virtual desktop connection may not have built-in ‘multimedia accessories’…{although users ‘remotely accessing’ their virtual desktop using a ‘Multimedia device’ may, such as a camera, microphone or audio speaker}) [0004] [also 0017], as well as the feature of receiving, by the virtual conference provider from a second client application executed by ‘a client device used by the first participant’, a second request to join the meeting…” (Wang: e.g., user’s ‘Mobile Device’ {i.e., Mobile Device _130) [Fig. 1] (e.g., in various embodiments described herein, the virtual desktop client device can employ the multimedia accessory of a nearby mobile device and redirect the multimedia stream captured by the accessory to the virtual desktop. The process can be initiated when a user logged into their virtual desktop client device provides input indicating a request to utilize the multimedia accessory of a nearby mobile device…Once the user input is received by the virtual desktop client application, a Quick Response (QR) code is generated and displayed to the user by the virtual desktop client device. The QR code is encoded with information (e.g. IP address) identifying a web server that is operating on the virtual desktop client device. ‘The User may then utilize their mobile device’ equipped with a camera to scan the QR code and ‘establish a connection with the server’ identified in the QR code. The connection may be a hypertext transfer protocol (HTTP) connection, such as a WebSocket connection, and it is used to send the multimedia stream between the mobile device and the virtual desktop client device….In one embodiment, when the mobile device is used to scan the QR code, a web application is launched on the web browser of the mobile device. The web application establishes a connection with the server and streams ‘multimedia captured on the Mobile device’ to the Virtual desktop client device. For example, the web application may access the digital camera {of the Mobile device} to begin capturing video and stream the captured video to the Virtual Desktop Client device. The ‘Virtual Desktop Client device’ receives the video over the WebSocket connection and ‘redirects’ the video to the virtual desktop over a virtual channel by providing the video to a Real Time Audio Video (RTAV) module operating on the Virtual Desktop Client device. In this manner, the video captured by the Mobile device is available to the virtual desktop without the need to install specialized virtual desktop client software on the mobile device. The User is therefore allowed to ‘participate’ in various multimedia based activities, such as ‘online meetings’ or ‘video conferences’ even in cases when the ‘Virtual Desktop Client Device’ does not have any ‘multimedia capabilities’ {but which the User’s Mobile device has}) [0013-0014] (e.g., In various embodiments, the Virtual Desktop Client device may also ‘redirect’ multimedia received from the virtual desktop to the Mobile device. This may be useful in applications, such as ‘video conferencing’, so that the audio being played on the virtual desktop can be heard directly on the mobile device, without the user having to listen to the audio on the virtual desktop client device) [0015; Fig. 1].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify the combination with the above said additional feature(s), as expressly disclosed by Wang, for the motivation of providing a system for multimedia redirection where a ‘Virtual Desktop Client device’ can utilize the multimedia accessories such as digital camera(s) and/or microphone(s) of ‘Mobile devices’ by utilizing image scanning techniques [Wang: Abstract, 0002; 0011; Fig. 1].
Claim(s) 8, 15 recite(s) substantially the same limitations / features as claim 1, is/are distinguishable only by its/their statutory category (System, non-transitory CRM), and accordingly rejected on the same basis.
As per claim{s} 2, 9, 16, Chen in view of Moran, and Moran in particular, discloses the method further comprising associating the first meeting signaling information and the one or more first multimedia streams (Moran: e.g., expressly teaches / discloses in one aspect that Multipoint Controller 34 instructs the Multipoint processor 36 to ‘initiate a conference’ (or if the terminal {i.e., Terminal 22} is ‘joining’ an existing conference, to ‘add the terminal to the conference’). The H.323 standard does not specify any mandatory requirements for the communication between the Multipoint controller and Multipoint processor, and in most cases, proprietary ‘Signalling’_48 will be employed for these communications. Alternatively, ‘H.248_signalling’ can be used…Once the Multipoint processor 36 has ‘added’ Terminal 22a to the conference, an ongoing ‘Media stream’_49 is established between the Terminal 22a and the Multipoint processor 36. This is a ‘two-way stream’ and may employ multiple media channels, such as ‘audio’, ‘video’, text and ‘data’ / file transfer {associating the Terminal that has ‘joined / been added’ to the Conference with the Terminal for receiving and/or transmitting two-way Media stream_49}…Additional Terminals 22b, 22c, 22d ‘joining’ the conference do so in the same manner as Terminal 22a. When the four terminals have joined, Multipoint processor 36 is communicating with each terminal via a 2-way multimedia stream 49…Multipoint processor 36 ‘receives the incoming multimedia stream 49 from each Terminal 22a-22d and processes it by separating the various media channels from each terminal, and mixes the signals as appropriate to generate an ‘outgoing multimedia stream’ to each Terminal ) [col 8, L26-47; Fig. 3].
The motivation for combining Chen with Moran is similar to that given to claim 1 above.
Claim(s) 3, 10, 17 is/are rejected under 35 U.S.C. 103 as being disclosed by Chen in view of Moran and in view of Wang and in further view of Boyer et al (hereinafter Boyer), US Patent Pub 20130282803 A1 (publication date October 2013).
As per claim{s} 3, 10, 17, while the combination of Chen, Moran and Wang discloses substantial features of the invention above, they do not expressly disclose the additional recited feature{s} / limitation{s} of the method wherein the virtual conference provider comprises virtual conference control and a VD gateway, and wherein the first request is received by the virtual conference control and the second request is received by the VD gateway, and wherein the VD gateway communicates with the virtual conference control to associate the first and second connections.
However, in a related endeavor, Boyer particularly discloses the additional recited feature{s} / limitation{s} of the method wherein the virtual conference provider comprises virtual conference control and a VD gateway, and wherein the first request is received by the virtual conference control and the second request is received by the VD gateway, and wherein the VD gateway communicates with the virtual conference control to associate the first and second connections (Boyer: e.g., Conference environment 400 in FIG. 4 includes Communication network 401, over which Media server 413 and Client devices 409, 411, 413, and 417 communicate with each other and with Conference system 403. Examples of client devices 409, 411, 413, and 417 include mobile smart phones, tablet computers, laptop computers, notebook computer, net book computers, personal desktop computer, ‘virtual desktop computers’, and any combination or variation thereof. Examples of Media server 413 include Video servers, music servers, ‘Web servers’, and any combination or variation thereof…Conference system 403 includes ‘Gateway system’_405 {equivalent to VD gateway} and ‘Conference server’_407 {equivalent to Virtual Conference Control} Conference server 407 ‘hosts conference sessions’ and provides ‘functionality and services’ to allow client devices to connect to and exchange ‘communications’ {media streams} over the conference sessions. Some Client devices may communicate with Conference server 407 without interacting with gateway system 405. However, Gateway system 405 allows client devices to connect to Conference server 407 from various networks that otherwise cannot provide more direct interaction with conference sessions and that may require ‘services’ provided by Gateway system 405, such as protocol or format conversion) [0056-0057; Fig. 4].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify the combination with the above said additional feature(s), as expressly disclosed by Boyer, for the motivation of providing a conferencing method and system for facilitating conference sessions which allow users or participants to interact with each other in a variety of ways, as well as access conference sessions using a variety of communication devices and by way of a variety of communication channels [Boyer: Abstract, 0002-0003 & 0005; Fig. 1].
Claim(s) 10, 17 recite(s) substantially the same limitations / features as claim 1, is/are distinguishable only by its/their statutory category (System, non-transitory CRM), and accordingly rejected on the same basis.
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.06(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, 9am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry can be reached on 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451
Prosecution Insights