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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Interpretation
The claim limitations "an audio driving module ... configured to acquire target audio data to be shared between different applications and store the target audio data in a memory; and determine a file descriptor corresponding to the target audio data according to a memory address at which the target audio data is stored" and "an audio frame module ... configured to share the file descriptor between the different applications" in claim 15 invoke 35 U.S.C. 112(f) because the claim uses a generic placeholder ("module") coupled with functional language ("configured to ...") without reciting sufficient structure to perform the recited functions, and the generic placeholder is not preceded by a structural modifier that would remove it from treatment under 112(f). See MPEP § 2181(I). Because these claim limitations invoke 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure, material, or acts described in the specification that perform the entire claimed function, and equivalents thereof. A review of the written description does not reveal structure, material, or acts corresponding to the claimed functions of the "audio driving module" and "audio frame module" beyond a general-purpose processor performing generic computer functions, which is not sufficient to constitute corresponding structure under 35 U.S.C. 112(f). See MPEP § 2181(II)(B). Claim 15 is accordingly further rejected under 35 U.S.C. 112(b) below.
Claim Rejections – 35 USC § 112b
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 6 is rejected under 35 U.S.C. 112(b). It recites, in relevant part, storing played audio containing a watermark as target audio data “if it is determined that the fourth application is used to verify the watermark.” The claim does not identify what entity or process performs this determination, what triggers it, or its procedural relationship to the storing step that is conditioned upon it. Therefore, it is unclear whether the recited storing step is a positive method step that must be performed in every instance of practicing the claim or a conditional limitation that does not need to be reached at all.
Claim 9 is rejected under 35 U.S.C. 112(b). It depends on claim 7, which recites “determining the file descriptor corresponding to the target audio data according to the mapping relationship”. Claim 9 further limits the same determining step, but recites “determining a handle corresponding to the target audio data according to the mapping relationship”. The claim fails to establish whether a “handle” is the same data object as “the file descriptor” carried forward from claim 7, a data structure that wraps or corresponds to the file descriptor, or an entirely separate identifier, making claim 9 indefinite.
Claim 10 is rejected under 35 U.S.C. 112(b). It depends on claim 9 and recites “mapping the virtual memory addresses of the different applications to the same handle, and sharing the handle between the different applications”. Claim 9 recites both “a same handle” and “a handle corresponding to the target audio data”, so it is unclear to which of these “the handle” in claim 10 refers. Claim 10 is also indefinite for the reasons given for claim 9, from which it depends.
Claim 15 is rejected under 35 U.S.C. 112(b) as indefinite. As explained in the Claim Interpretation section above, the “audio driving module” and “audio frame module” limitations of claim 15 invoke 35 U.S.C. 112(f), but the written description fails to disclose adequate corresponding structure, material, or acts for performing the claimed functions. A claim limitation that invokes 35 U.S.C. 112(f) but for which the specification fails to disclose the corresponding structure is indefinite under 35 U.S.C. 112(b). See MPEP § 2181(II)(B); In re Aoyama, 656 F.3d 1293 (Fed. Cir. 2011).
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 1-6 and 11-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims are evaluated under the subject matter eligibility analysis of MPEP § 2106.
Step 1.
Claims 1-6 and 11-14 recite a method, which is a process. Claim 15 recites a system and claim 16 recites an apparatus, each of which is a machine. Claim 17 recites a computer storage medium, which is a manufacture. The claims fall within the statutory categories.
Step 2A, Prong One.
Claim 1 recites “determining a file descriptor corresponding to the target audio data according to a memory address at which the target audio data is stored.” The specification describes a file descriptor as “a non-negative integer” that is “an index value” (specification, ¶ [00228]). Under its broadest reasonable interpretation, this limitation covers selecting an index value that corresponds to the location at which data is stored. That is an evaluation that can practically be performed in the human mind or with pen and paper, for example by assigning or looking up an index number for a storage address in a table. Claim 1 does not recite any particular manner of determining the file descriptor that could not be performed in that way. The limitation therefore recites a mental process, which is one of the groupings of abstract ideas. See MPEP § 2106.04(a)(2)(III).
Step 2A, Prong Two.
The abstract idea is not integrated into a practical application. Claim 1 recites the following additional elements:
(a) “acquiring target audio data to be shared between different applications and storing the target audio data in a memory.” This limitation gathers and stores the data on which the determining step operates. It is recited at a high level of generality and is insignificant extra-solution activity. See MPEP § 2106.05(g).
(b) “sharing the file descriptor between the different applications, so that the different applications acquire the target audio data according to the memory address corresponding to the file descriptor.” This limitation passes the result of the determining step to generic software (“different applications”). The “so that” clause states the result of the sharing; the claim does not recite how an application uses the file descriptor to reach the memory address. The limitation amounts to transmitting data and to an instruction to apply the abstract idea using generic computer components. See MPEP § 2106.05(f) and (g).
(c) “a memory” and “different applications” are generic computer components, and the recitation of “audio data” limits the abstract idea to a particular type of data. See MPEP § 2106.05(f) and (h).
The specification states that the disclosed method improves the use efficiency of audio data because the applications access the audio data without copying it (specification, ¶¶ [00175]-[00176]). The specification attributes that result to mapping the physical memory address at which the audio data is stored to the virtual memory addresses of each application, and mapping those virtual memory addresses to the same file descriptor (specification, ¶¶ [00222]-[00227], [00236]). Claim 1 does not recite that mapping. As drafted, claim 1 covers any way of determining the file descriptor and any way of sharing it, including arrangements in which each application still copies the audio data. Claim 1 therefore does not reflect the improvement described in the specification. See MPEP §§ 2106.04(d)(1) and 2106.05(a). Considered as a whole, the additional elements do not integrate the abstract idea into a practical application, and claim 1 is directed to the abstract idea.
Step 2B.
The additional elements, considered individually and as an ordered combination, do not amount to significantly more than the abstract idea. As explained above, they are data gathering, data storage and data transmission performed by generic computer components. The courts have recognized storing and retrieving information in memory, and receiving or transmitting data, as well-understood, routine and conventional computer functions. See MPEP § 2106.05(d)(II), citing Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015), OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014). Considered together, the additional elements add nothing that is not already present when they are considered separately. Claim 1 is not patent eligible.
Claims 15-17 recite the same determining step as claim 1 and therefore recite the same abstract idea. Claim 15 recites the steps of claim 1 as functions of an “audio driving module” and an “audio frame module.” Claim 16 recites a processor and a memory that execute the method, and claim 17 recites a computer storage medium holding a program that implements the method. These elements are generic computer components used to carry out the abstract idea, and they amount to an instruction to implement the abstract idea on a computer. See MPEP § 2106.05(f). Claims 15-17 are not patent eligible for the reasons given for claim 1.
Claims 2-4 recite the source of the audio data (“a hardware register”) and the way the audio data is moved into memory (“a direct memory access mechanism” and “continuous memory allocation technology”). These limitations further describe the data gathering and storing step and remain insignificant extra-solution activity. See MPEP § 2106.05(g). They are also well-understood, routine and conventional. The specification refers to the direct memory access mechanism and the contiguous memory allocator as existing mechanisms and does not describe their particulars (specification, ¶¶ [00190], [00193]). Berreth describes DMA engines as a feature of audio devices that use standard port drivers (Berreth, ¶ [0009]), and Iizuka describes transferring digital audio data between audio input/output devices and storage under control of a DMA controller (Iizuka, Abstract).
Claims 5 and 6 name what the applications do with the audio data (recording, adding a watermark, playing, verifying a watermark). The functions are recited by name only, and they limit the abstract idea to a field of use. See MPEP § 2106.05(h). Claims 5 and 6 also recite moving the audio data from a hardware register to a physical memory (claim 5) and from a physical memory to a hardware register for playback (claim 6), which are data gathering and data output. See MPEP § 2106.05(g).
Claim 11 describes the data as data that the applications process at the same time. Claim 12 identifies the operating system on which the applications run, which generally links the abstract idea to a technological environment. See MPEP § 2106.05(h). Claim 13 recites that the file descriptor is transmitted “using an audio framework,” which is a generic software component used as a tool to transmit the result of the determining step. See MPEP § 2106.05(f). Claim 14 recites that the applications acquire and process the audio data with “a time delay” but does not recite how the delay is provided. The specification states that the delay means only that the processing by the two applications is not completely aligned in time (specification, ¶ [00180]).
Claim Rejections – 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1, 11-13, 15-17 are rejected under 35 USC § 103 as being unpatentable under Kotteri (US 2020/0104093 A1), in view of Aloni (US 10064021 B1).
Regarding claim 1, Kotteri teaches
acquiring target audio data to be shared between different applications and storing the target audio data in a memory, by disclosing, “As shown in FIG. 1A, the computing system 100 may include audio capture hardware 112 that may be configured to capture an audio data stream 113. For example, the audio capture hardware 112 optionally may include a microphone 114 and/or a microphone array 116 each configured to capture audio data. The audio capture hardware 112 may include any suitable audio capture/recording device. The audio capture hardware 112 may be configured to send the captured audio data stream 113 to the listener service 108. The listener service 108 may be configured to store the received, captured audio data stream 113 in the rolling audio buffer 110 ... The rolling audio buffer is provided as an example of a shared memory space.” (¶¶ [0014]-[0015]). Kotteri further teaches sharing the stored target audio data between the different applications, so that the different applications acquire the target audio data from the shared memory, by disclosing that “the first application 104A and the second application ... may be both associated with the trigger such that the history segment of the audio data stream is provided from the shared memory space to both the first application and the second application based on the trigger” [0052]. To the examiner, this is understood to mean that the identical stored data is made available to more than one separately instantiated application via the shared memory space.
However, Kotteri fails to teach determining a file descriptor corresponding to the target audio data according to a memory address at which the target audio data is stored, and sharing the file descriptor between the different applications, so that the different applications acquire the target audio data according to the memory address corresponding to the file descriptor. Aloni teaches determining a file descriptor corresponding to the target audio data according to a memory address at which the target audio data is stored, by disclosing a “kernel driver 216 returns a slot identifier 681 (e.g. ‘0’) to the sample object 621S corresponding to the given digital audio sample 6211 the sample object 621S stores the slot identifier 681 in the SlotID field 665. The sample object 621S corresponding to the given digital audio sample 621 further sets the Is-Cached field to “True” to indicate that the resampled PCM data 680 of the given digital audio sample 621 is stored in a slot of the kernel RAM buffers 218 identified by the slot identifier 681 in the SlotID field 665.” (Paragraph 74). Aloni further teaches sharing that identifier so that the target audio data is acquired according to the memory address corresponding to it, by disclosing that SoundPool will “pass the memory address 505 of the PCM data to AudioFlinger,” which retrieves the PCM data from address 505 (FIG. 5 discussion), and that the application passes slot identifier 681 to kernel driver 216 using a PlayCached(slotID) API and an IOCTL system call, so that kernel driver 216 retrieves the resampled PCM data 680 from the slot identified by that identifier (FIG. 7 discussion), with Binder IPC facilitating this communication across process boundaries (FIG. 4 discussion).
A person of ordinary skill in the art would have found it obvious to identify Kotteri's stored audio data, kept in a shared memory space accessible to different applications, by an identifier tied to its memory location, as taught by Aloni, and to share that identifier with each application rather than requiring each application to independently locate the shared data. Kotteri and Aloni both address avoiding duplication of audio data across multiple consumers of a shared buffer, and Aloni's identifier-passing mechanism is a known technique, implemented on the Android platform, for identifying and retrieving data from a memory location shared across process or application boundaries. Applying Aloni's known identifier-passing technique to Kotteri's shared memory space would have yielded the predictable result of allowing the different applications to obtain the shared audio data by reference to a common identifier rather than by an independent copy.
Regarding claim 11, Kotteri teaches
the method according to claim 1, wherein the target audio data to be shared comprises target audio data processed by the different applications at the same time, by teaching that the first application 104A “may continue to receive the audio data stream 113 and perform any suitable operations based on the audio data stream 113. The first application 104A may stop receiving the audio data stream 113 at any suitable time based on any suitable conditions.” [0028], while the second application 104B is concurrently and independently processing its own segment of the identical shared audio data stream 113 from the same rolling audio buffer 110 (FIGS. 1C-1D); contemporaneous processing of the same target audio data by different applications.
Regarding claim 12, Aloni teaches
the method according to claim 1, wherein the different applications comprise different applications running on an Android system, by teaching that “the device 100 is operating according to the Android™ operating system” (Paragraph 43), naming Android-specific components. This limitation specifies the operating system on which the already-disclosed multi-application sharing occurs; Aloni's disclosure is expressly implemented on Android, and Kotteri's teachings, as applied to claim 1 above, already establish the underlying multi-application sharing architecture within Aloni's Android environment.
Regarding claim 13, Aloni teaches
the method according to claim 1, wherein the sharing the file descriptor between the different applications comprises: transmitting the file descriptor to the different applications using an audio framework, so that the file descriptor is shared between the different applications, by disclosing that the Android audio framework is the mechanism transmitting memory address 505 and slot identifier 681 between components (FIG. 4-7 discussion).
Regarding claims 15-17, they recite substantially the same limitations as those recited in claim 1, applied to a system, an apparatus, and a computer storage medium, respectively. Thus, for the same reasons presented with respect to claim 1, claims 15-17 are rejected.
Claims 2-4 and 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Kotteri in view of Aloni in view of Berreth (US 2010/0077110 A1).
Regarding claim 2, Kotteri, as applied to claim 1 above, teaches
acquiring the target audio data to be shared between the different applications and storing the target audio data in a memory. Berreth teaches determining a hardware register of the target audio data when the different applications need to share the target audio data, and acquiring the target audio data from the hardware register and storing the target audio data in the memory, by disclosing that audio device 124 provides position register 312, mapped into virtual memory for direct client access, which indicates the buffer position of the audio data samples currently moving through the device's ADC (Position Registers section; Stream Latency During Recording), and by disclosing that the audio device captures the audio and writes it directly into cyclic buffer 122 in physical memory, referenced by that register, for access by the client and by audio application(s) 110 (FIG. 3; Overview).
A person of ordinary skill in the art would have applied Berreth's hardware register to Kotteri's shared audio buffer, because a hardware register that indicates where captured audio currently resides in the buffer would identify, for Kotteri's listener service, the location of the data to be acquired and stored for sharing among applications.
Regarding claim 3, Berreth teaches
storing the target audio data in the hardware register in a physical memory by using a direct memory access mechanism, by teaching that client 118 writes audio stream 126 to cyclic buffer 122 for direct access by DMA controller(s)/engine(s) 316/318 associated with audio device 124, without further copying by the port driver (block 212/FIG. 3 discussion).
Regarding claim 4, Berreth teaches
allocating continuous physical memories for the target audio data by using continuous memory allocation technology, and storing the target audio data in the allocated continuous physical memories, by disclosing that where audio device 124 lacks scatter-gatherer capability, WaveRT miniport driver 128 allocates cyclic buffer 122 using pages that are physically continuous in memory, via the IPortWaveRTStream::AllocateContiguousPagesForMDL method (Scatter-Gather DMA and Buffer Looping section), and by disclosing that the same cyclic buffer 122 is where client 118 writes, and audio device 124 reads and writes, the audio stream (FIG. 3).
Claim 7-8 are rejected under 35 USC § 103 as being unpatentable under Kotteri (US 2020/0104093 A1), in view of Aloni (US 10064021 B1
Regarding claim 7, Kotteri and Aloni, as applied to claim 1 above, teach that
the target audio data is stored in a memory, and that the memory address at which it is stored is passed between different applications so that each may acquire the data. Aloni further teaches respectively mapping a physical memory address at which the target audio data is stored to virtual memory addresses of the different applications, wherein the virtual memory addresses are isolated from each other between the different applications, by disclosing that SoundPool retrieves the PCM data from system RAM through an “IMemory” pointer (a memory address) to that data (FIG. 4 discussion) and passes that same memory address 505 across the process boundary to AudioFlinger, which retrieves the PCM data from address 505 (FIG. 5 discussion), each side of that boundary being a separate process with Android's Binder-IPC-mediated cross-process architecture ensuring that each application maintains its own isolated virtual address space and that only the memory address or identifier is exchanged across the boundary (FIG. 4-5 discussion).
A person of ordinary skill in the art would have applied Aloni's cross-process, memory-address-passing technique to Kotteri's shared audio buffer, so that each application obtains the physical memory location of the shared audio data through its own isolated virtual address space, tied to the other applications' spaces only by the memory address or identifier passed between them.
Regarding claim 8, Aloni, as applied above, teaches0
determining the file descriptor corresponding to the target audio data according to the mapping relationship, by using a kernel of an operating system, mapping the physical memory address at which the target audio data is stored to the virtual memory addresses of the different applications, and establishing the mapping relationship between the virtual memory addresses of the different applications and the same file descriptor, by disclosing that kernel driver 216, operating at the OS kernel level and distinguished from application-accessible system RAM, stores the resampled PCM data in a slot of kernel RAM buffers 218 and returns the corresponding slot identifier 681, which is stored in the SlotID field 665 and set to “True” in the Is-Cached field to indicate that the identifier maps to that particular slot in kernel-accessible memory (Paragraph 74).
Claim 5-6 are rejected under 35 USC § 103 as being unpatentable under Kotteri (US 2020/0104093 A1), in view of Aloni (US 10,064,021 B1) in further view of Tai (US 2020/0098380 A1)
Regarding claim 5, Kotteri, as applied to claim 1 above, teaches the
acquiring the target audio data to be shared between the different applications and storing the target audio data in the memory comprises: acquiring recorded audio by the first application and storing the recorded audio in a hardware register; and taking the recorded audio as the target audio data to be shared between the first application and the second application, and storing the recorded audio stored in the hardware register in a physical memory, by teaching a first application that receives and stores captured audio in the shared rolling audio buffer 110 (a physical-memory-resident structure), corresponding to the claimed recording first application and its storage of recorded audio in memory. However, Kotteri does not teach the different applications comprises a first application and a second application, the first application is configured for recording audio, and the second application is configured for adding a watermark to the audio. Tai teaches this limitation by disclosing a distinct watermark-embedding function, encoding an audio watermark into audio data using a sign-sequence/multi-segment Eigenvector scheme prior to output (watermark encoding structure 810/820), corresponding to the claimed second, watermark-adding application operating on the same shared audio data. A person of ordinary skill in the art would have applied Tai's watermark-embedding function to the audio recorded and shared by Kotteri's first application, so that a second application could embed a watermark in that same shared audio data.
Claim 6 recites substantially the same limitations as those recited in claim 5, applied to the method of claim 6. Thus, for the same reasons presented with respect to claim 5, claim 6 is rejected
Claim 14 are rejected under 35 USC § 103 as being unpatentable under Kotteri (US 2020/0104093 A1)in view of Aloni (US 10,064,021 B1), in further view of Phan (US 2006/0200846 A1).
Regarding claim 14, Kotteri, as applied to claim 1 above, teaches by the different applications,
acquiring the target audio data according to the memory address corresponding to the file descriptor, and processing the target audio data, by teaching that the first application 104A may continue to receive the audio data stream and perform operations on it (FIGS. 1B-1D; ¶ [0028]). However, Kotteri does not teach providing a time delay in processing of the target audio data by the different applications. Phan teaches this limitation by disclosing allocated receive buffer descriptors for recording a received packet into a shared memory, and separately allocating playback buffer descriptors for playback of that recorded packet from the same shared memory, disclosing a first portion of the packet “simultaneously played back from the shared memory while recording a second portion” (Phan, claim 2; Abstract).
A person of ordinary skill in the art would have recognized that Phan's playback process operates on data recorded at an earlier point in time than the data currently being recorded, and would have applied Phan's record/playback time-offset technique to the shared audio data of Kotteri, because Phan similarly teaches recording and playing back data from a single shared memory.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL NWUHA whose telephone number is (571)272-9367. The examiner can normally be reached Monday-Friday; 7:30 am - 5:00pm.
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, Kevin Young can be reached at (571) 270-3180. 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.
/SAMUEL OBINNA NNAJI NWUHA/
Examiner, Art Unit 2194
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights