Apple Inc - [2022] APO 60

IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Apple Inc [2022] APO 60
Patent Application: 2020201129

Title:Unified communication application

Patent Applicant: Apple Inc

Delegate:Greg Powell

Decision Date: 31 August 2022

Hearing Date: Written submissions filed on 13 May 2022

Catchwords: PATENTS – section 45 – examiner’s objection of lack of inventive step – creation of a communication session history – examiner’s objection cannot be sustained in light of available information – application referred back to examination for further consideration

Representation: Patent attorney for the applicant: FPA Patent Attorneys Pty Ltd, Sydney

IP AUSTRALIA
AUSTRALIAN PATENT OFFICE

Patent Application: 2020201129

Title:Unified communication application

Patent Applicant: Apple Inc
Date of Decision: 31 August 2022
DECISION

The examiner’s objection taken in the third report cannot be sustained. The claimed invention does not lack an inventive step on the available evidence. There is no evidence to establish that it would be a matter of routine to retrieve communication session files from different sources prior to arranging the lines into a coherent whole.

However, it could be said that the existence of such session files and their use has not been fully investigated by the examiner in their assessment of actions at other patent offices and in searches carried out by the examiner. Therefore, the application is remitted back to the examination section for further consideration.
Pursuant to sub-regulation 13.4(3), the final date to gain acceptance is set at four (4) months from the date of this decision.
REASONS FOR DECISION

Patent application 2020201129 (the present application) was filed by Apple Inc (the applicant) on 17 February 2020 as a divisional application of patent application 2016201444 (the parent application – which has been granted). The parent application is a divisional application of patent application 2013214758 (the grandparent application – which lapsed after not gaining acceptance). Ultimately, the present application claims priority from US applications 61/595127 filed on 5 February 2012 and 14/464801 and 14/464807, both filed on 4 May 2012.
The present application was filed after 15 April 2013. The fate of the present application is therefore governed by the Patents Act 1990 (the Act) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012. These amendments included the introduction of new section 49(1). Under this provision, I must accept the present application if satisfied on the balance of probabilities that it complies with the requirements of the Act. If I am not so satisfied, I can refuse the present application.
A first examination report was issued on 17 February 2021 raising objections in relation to manner of manufacture and inventive step. The applicant responded to the first examination report on 2 November 2021 by way of written submissions and proposed amendments to the description (but not the claims). A second examination report issued on 30 November 2021 maintaining the objection to just inventive step. Another response was filed on 1 February 2022 with further proposed amendments (to the description and claims) and arguments. A third examination report issued on 16 February 2022 maintaining the inventive step objection.
On 17 February 2022 the applicant requested to be heard by written submissions. Following direction, the applicant filed written submissions on 13 May 2022. The submissions were accompanied by a further proposed amendment adding in a new dependent claim 15. Previous claims 15 and 16 were renumbered as claims 16 and 17. I believe the amendment is allowable.
As amendments have been proposed, this decision is based upon the specification as proposed to be amended by the statements of proposed amendments filed up to and including 13 May 2022.
Finally, while the final date for acceptance of the present application was 17 February 2022, the time for gaining acceptance is extended by 3 months from the date of the present decision (see reg 13.4(1)(g)), or longer if appropriate (see reg 13.4(3)).
Hearings and decisions on parent application
It is worth noting that the parent application was the subject of two decisions (the first parent decision[1] and the second parent decision[2]). In relation to the first parent decision, the examiner had raised objections to a lack of inventive step in light of prior art and, after a number of reports, the applicant then requested to be heard. In the first parent decision, the delegate of the Commissioner concluded that the objection raised by the examiner did not adequately address a particular question that the delegate had to consider. The delegate remitted the parent application to examination for further consideration.
[1] Apple Inc. [2018] APO 91
[2] Apple Inc. [2019] APO 45
Following this, the examiner raised a further inventive step objection in light of new prior art. After another two reports following responses and amendments made by the applicant, the applicant requested to be heard. In the second parent decision the (same) delegate found, contrary to the examiner, that the invention as claimed possessed the requisite inventive step and directed that the parent application be accepted.
The Specification
Background to the present invention
The background to the present invention is contained in the first and second parent decisions. As outlined in the first parent decision:
“The specification states that the invention relates generally to facilitating a communication session in an electronic environment. As background, the specification provides an overview of electronic instant messaging services, how a user would generally interact with such services, and issues which may arise:
[0002] Typically, in order to initiate an electronic communication session, a user can log into an instant messaging service using a username and a password. After the user logs into the instant messaging service, the user can view a contacts list that shows the status of the user's established contacts on that service. When the user desires to establish a communication session with a particular contact on the user's contacts list, the user can select an identifier representing the particular contact, or the intended recipient, from the user's contacts list, create a message in a message box that appears when the user selects the identifier, and send the message to the recipient. Upon receiving the message, the recipient can either respond to the sender or decline to respond. If the recipient responds to the sender, a communication session is established and communication between the sender and the recipient (referred to as ‘participants of the communication session’) begins. In some instances, the participants of the communication session can invite other contacts to join the communication session.
[0003] A number of instant messaging services have become widespread, with some being more popular with certain groups of users. Users are often registered with several instant messaging services and communicate with other users who are also registered with a number of instant messaging services, some of instant messaging services of which do not overlap. Moreover, users registered with several instant messaging services often have different usernames for some of those services. A user can have trouble keeping track of which contacts are on which services and under which usernames.
[0004] In some instances, a user can he [sic] logged into several instant messaging services. If the user is not currently logged into a service that an intended recipient is currently using, the user must log into that service before the user is able to send messages to the intended recipient. In other instances, a user can be logged into several instant messaging service but only actively using some of those services. If the user is not currently actively using the service that the intended recipient is using, then the user must switch to the service that the intended recipient is using to be able to send messages to the intended recipient. It can be cumbersome for the user to constantly have to log into and/or switch between different services when the user desires to communicate with different contacts.
[0005] Further, the user might desire to view a communication history with another user. For instance, the user might be searching for a particular dialogue between the user and another user. However, with each user having multiple usernames associated with multiple instant messaging services, it can be difficult to find the particular dialogue.”[3]
[3] First parent decision at [11]
Overview of the present invention
As noted in the first and second parent decisions, to address the issues with the prior art, the applicant developed a “unified messaging application” that permitted users to communicate using a plurality of electronic communication services. The operation of the system is described in detail in the first and second parent decisions, and I do not intend to repeat that detail here.
Nevertheless, at a broad level, in the system a user initiates a communication session by inputting an identifier (full or partial) of another user they wish to communicate with, and the system presents a list of possible matches and, if necessary, the various communication services (e.g. SMS, e-mail, instant messaging, etc) by which the user could communicate with that other user. The user selects the other user (and the communication service if required) and composes (by typing text, sending a file such as a photo, launching a video or audio chat) a message to be sent. The system also receives and displays any response from the other user.
The decisions note that:
“Once the users of the conversation have been identified, the computer generates a combined communication history which aggregates messages from conversations associated between the first user and the second user, across all relevant user identifiers.”[4]
The present invention relates to this aspect of the system.
[4] First parent decision at [12] (quoted in second parent decision at [7])
The present application states that:
“The communication application in some embodiments can provide other functionality including the ability to display a communication history between a first user and a second user to the first user. In response to a user request for communication history between a user and another user, unified messaging app … can aggregate and present a communication history between two users, including communication that took place across multiple electronic communication services”[5]
[5] Present application at [0087]
The present applications notes that electronic communication services can be hosted by different providers and/or on different servers, and some electronic communication services maintain records of past communication.
The present application notes that there could be local and remote storage of electronic communication session files, noting that Figure 8 shows such an arrangement:
The present application states that:
“… FIG. 8 is a system diagram 800 that illustrates local and remote storage of electronic communication session files that can be located and aggregated to generate a communication history between users. In some embodiments, user device 100 can communicate via a wide area network 805 (e.g., the Internet) with various servers. As shown, the servers can include instant messaging service #1 server 810, SMS service server 815, and instant messaging service #2 server 820. Other servers (not shown) hosted by other providers of electronic communication services can also be connected to network 805. In this embodiment, each of servers 810, 815, and 820 stores communication history files in an associated data repository 825, 830, 835.
A representative communication file is shown as chat session file 840. File 840 can be a transcript of a chat session between two (or more) users and can be retrievable from data repository 825 by reference to various parameters such as the date, time, and/or participants’ user names (or other account identifiers). In some embodiments, the date and time associated with the file can include a range of times over which communications occurred (e.g., all communications from the same day can be stored in one file, or if the communication service defines a session, the range of times can correspond to the duration of a session). File 840 can store a record of each message that was sent by either party during the relevant time range, and each message can have a timestamp indicating when it was actually sent. In some embodiments, file 840 can include text data, audio data, video data, image data, or any other data representing the communication that took place. A communication file can include any number of messages; in some instances, each message may be in a separate file, or a single file may contain many messages.”[6]
[6] Present application at [0088]–[0089]
FIG. 9 is an example of generating a communication history page by aggregating multiple communication session files according to an embodiment of the present invention:
The messages are displayed according to timestamps. The specification states:
“Page 900 in FIG. 9, which is generated by aggregating communication session files from instant message service 910, VOIP service 915, and text message service 920, shows the aggregated communication history between the user and Johnny Appleseed. The aggregated communication history shows all chat lines and text exchanges between the user and Johnny Appleseed, sorted by timestamps, without regard for which service was used. Because ‘Hey Mandy’ from VOIP service 915 has a timestamp of 10:56:33 and is the first communication between the user and Johnny Appleseed, it is displayed as the first chat line in the aggregated communication history. The next communication occurred when Johnny Appleseed sent ‘Hello!’ to the user via instant message service 910 at 13:20:05. Hence, it is displayed as the second chat line in the aggregated communication history. In this way, all the chat lines from instant message service 910 and VOIP service 915 are sorted by each of their associated timestamp. Communication lines from the different communication session files can be interleaved depending on each communication line's timestamp. Moreover, page 900 also includes the communication history between the user and Johnny Appleseed from SMS service 920. As indicated by their associated timestamps, the text messages were exchanged later in the day. Consequently, the text message exchanges are displayed at the bottom of page 900, below the communication history from instant message service 910 and VOIP service 915.”[7]
[7] Present application at [0094]
This aggregation process is set out in Figure 10, which is self-explanatory:
While noting that page 900 can be scrollable (since the communication history could be quite long and not fit into the available display space), the description also notes[8] that memory constraints may prevent the entire communication history being loaded into system memory. In that circumstance, the system could load the portion of the page being viewed into system memory at that time. Other portions could then be loaded into system memory (with the current displayed portion being unloaded) for display as the user went to view other portions of the communication history page. This is shown in Figures 11A and 11B:
[8] Present application at [0106]
In these figures, 1105 represents the entire communication history, consisting of a number of cells 1102 each of which represent a portion of the communication history. As the user scrolls through the history, only a certain amount of the history is displayed in the viewing window 1115 and 1120. As the user scrolls through the window, some of the portions of the aggregated history that are outside the window are loaded (e.g. 1102(7) and 1102(8) in figure 11A) or unloaded (e.g. 1102(11) and 1102(12) in figure 11B) as the case may be.
The number of cells displayed could be optimised depending on the parameters used. For example, cell size could be defined as a fixed number of messages/lines, or a fixed amount of content, depending on considerations such as loading speed, rendering speed, the amount of memory available, and the acceptable delay before displaying different portions of the communication history in response to the user scrolling.
The claims
The specification, as proposed to be amended up to 13 May 2022, has 17 claims of which claims 1, 16 and 17 are independent. Claim 1 is directed to a method, while claim 16 is directed to a computer-readable storage medium storing a program which runs the method and claim 17 is directed to an electronic device which contains a memory storing a program which runs the method.
Claim 1, as proposed to be amended is as follows:
“1. A method comprising:
receiving, by an electronic device that includes a display, a request for a communication history between a first user and a second user;
obtaining, by the electronic device, a set of communication session files that store communications between the first user and the second user, each of the set of communication session files including a set of conversation lines, each of the set of conversation lines being associated with a timestamp, wherein the conversation lines in different ones of the set of communication session files were transmitted using different ones of a plurality of electronic communication services;
arranging, by the electronic device, the conversation lines from all of the set of communication session files in an order based on the associated timestamps;
displaying, on the display, by the electronic device, at least a portion of the arranged conversation lines, wherein:
the arranged conversation lines are displayed on a page in a user interface of the electronic device;
the displayed portion of the arranged conversation lines corresponds to a portion of the page currently being viewed by the first user; and
at least the portion of the arranged conversation lines is loaded;
receiving an input of the first user scrolling from the portion of the page currently being viewed by the first user to another portion of the page; and
in response to receiving the input, loading another portion of the arranged conversation lines corresponding to the another portion of the page.”
While there is some overlap with the claims considered by the delegate in the first and second parent decisions, claim 1 is essentially based on claims 43–45 of the grandparent application. These claims were deleted prior to the commencement of examination of the grandparent application. As discussed at paragraph [4] above, with the exception of claim 15, the claims I am considering are identical to those that were the subject of the third examiner’s report. The full claim set is given in the Annex to this decision.
The citation – WO 2008/030967
As noted, the examiner objected that the claims lacked an inventive step. This objection was made in light of WO 2008/030967, which was labelled as “D3” in the reports. As such it is appropriate to discuss what D3 discloses.
D3 is directed to a “mobile computing device” such as smart phone that supports telephone and voicemail services, as well as other types of mobile messaging services such as facsimile, e-mail, instant messaging (IM), short message service (SMS) messaging, multimedia message service (MMS) messaging, video conferencing, and the like[9]. Figure 1 discloses the system:
[9] D3 at [0002]
Essentially, the content of messages that are sent and received (both of which may include attachments) are stored in a message content database 140. Sent messages are created using the various messaging apps 131–138. Messages of the same type can be received. A message log 144 keeps track of various types of messages which are sent and received. The information stored includes, inter alia, the time and date of receipt, or sending, of the message. The contacts database 142 stores records of contacts. The record for an individual could include information such as first name, last name, telephone numbers, e-mail address, Instant Message (“IM”) screen names, SMS identifier, MMS identifier, personal information, notes, and the like.

With respect to the present invention, D3 notes that the user can be presented with message threads. The threads are created by the threading engine 146 accessing the message content database 140, the contacts database 142, and the message log 144 to associate received messages of different message types with a particular sender and sent messages of different types with a particular recipient.
The user is presented with a “message list” as shown in Figure 2:
This screen displays the message list 210 which, although it may be sorted in various ways such as by time of receipt, by sender name, by message type, and so forth, is shown in D3 as being sorted by time of receipt. The items shown in Figure 2 include a message thread 214, a high priority unread e-mail message 216, a missed telephone call 218, a high priority SMS message that has been read 220, and an unread SMS message 222.
When the message thread 214 is selected by the user, they are presented with a message thread comprising various message items. Figure 3 displays this:
The display 300 shows a message thread 304 displaying various message items between the user and a particular contact (John Doe). In the present case, the messages displayed in the message thread 304 are sorted by time of receipt/sending. D3 notes that:
“the message thread 304 may be arranged to display messages of various types and formats. In this embodiment, the message thread 304 includes a message 322 comprising a telephone call that displays linked telephone number information of the contact and the date of receipt (e.g., Thu 9/8/06 11:30 p.m.). The message thread 304 includes a message 324 comprising a received and read e-mail message with an attachment that displays linked e-mail address information of the contact, the subject of the e-mail message, and the date of receipt (e.g., Fri 9/9/06 1:15 a.m.). The message thread 304 includes a message 326 comprising a sent IM message that displays linked IM screen name information of the contact, the text of the IM message, and the date sent (e.g., Fri 9/9/06 1:20 a.m.). In some embodiments, an IM icon associated with the message 326 may indicate whether the contact is currently online and available to receive an IM message.
The message thread 304 includes a message 328 comprising a received and read SMS message that displays the date of receipt (e.g., 9/9/06 9:31 a.m.) and the text of the SMS message. The message thread 304 includes a message 330 comprising a sent SMS message that displays the date sent (e.g., 9/9/06 9:32 a.m.) and the text of the SMS message.”[10]
[10] D3 at [00062]
A scroll bar 306 allows the user to scroll through the messages in the message thread 304. D3 also notes:
“In various embodiments, the messaging UI 300 may comprise a hyperlink 320 to retrieve archived messages. In one embodiment, for example, the messaging UI 300 may be arranged to show a maximum number (e.g., 50) of recent messages exchanged between the user and the contact. By clicking on the hyperlink 320, the user may view all the previous messages. In general, providing the hyperlink 320 to archived messages may improve the rendering time of the messaging UI 300 and allow the user to launch the messaging UI 300 immediately as well as retaining access to numerous and/or old messages.”[11]
[11] D3 at [00061]
Outline of the examiner’s objection
The examiner’s position can be ascertained from objections 5 and 6 of the second and third examination reports, respectively. I will note that the claims reported on by objection 5 differ from the claims I am considering in the following ways:
(a)in claim 1, the claims did not require a “scrolling input” before loading another portion. Instead, what was received was an “indication” that the portion of the page being viewed had changed because the user was scrolling;
(b)current claims 14 and 15 were not present, and current claims 16 and 17 were numbered 14 and 15
These are slight differences. The examiner’s view of the claims in their objection is still broadly applicable to the claims before me.
In objection 5, the examiner found a lack of inventive step in light of D3. The objection was as follows (formatting and italics in original):
“The invention defined in claim 1 lacks an inventive step when D3 is read in light of common general knowledge.
Applicant’s assertions have been carefully considered and the objections in light of D1 and D2 are withdrawn. However the claims continue to lack an inventive step in light of prior art document D3.
I apologise for raising a new citation at this stage of examination.
Applicant asserts that this invention is made against a background of, before the priority date, developments in communication histories on computing devices having no provision for a person to, on request, view two-way conversations or dialogues with another person across communication platforms or that these communication histories are loaded into a page of a user interface as the user views and scrolls through the communication history.
However as evidenced by D3 and further elaborated in the following discussion, viewing two-way conversations or dialogues with another person across communication platforms was known in the art well before the priority date of the current application. Additionally caching of data to conserve memory was a well known technique.
With respect to claim 1, D3 does disclose receiving a request for a communication history between a first user and a second user (Paragraph [0058] the messaging UI 300 may be presented to a user when the message item 214 is selected. The selection of message item 214 is considered to read on the feature of requesting for a communication history between a first and a second user);
D3 discloses storing communication session files including a set of conversation lines, each of the set of conversation lines at Paragraph [0036] when it discloses a message content database Fig. 1 Ref 140 arranged to store content and attachments (e.g., media objects) of messages sent and received by the messaging applications Fig. 1 Ref 130. D3 explicitly discloses displaying messages along with the time the message was received, see at least Figs. 2 and 3. Therefore it is inherent that D3 discloses the storing the message content in the message content database along with its associated with a timestamp. As shown at Fig. 1 Ref 130, D3 teaches the conversation lines in different ones of the set of communication session files were transmitted using different ones of a plurality of electronic communication services.
D3 discloses arranging and displaying at least a portion of the arranged conversation lines (Paragraph [0050] where it discloses the messaging UI 300 may be arranged to show a maximum number (e.g., 50) of recent messages exchanged between the user and the contact) wherein the conversation lines from all of the set of communication session files in an order based on the associated timestamps (Fig. 3).
D3 does not explicitly disclose in response to receiving a scrolling indication, loading another portion of the arranged conversation lines corresponding to the other portion of the page currently being viewed by the first user.
However D3 discloses that only a maximum number (e.g., 50) of recent messages exchanged between the user and the contact are displayed and that by clicking on the hyperlink 320, the user may view all the previous messages (see Paragraph [0061]).
The problem solved by the feature in the current invention is to overcoming memory constraints.
The feature defined in the claim one is a specific type of web caching that was known to a skilled person. It is well known in the art at the priority date of the application that web caching systems can lead to significant bandwidth savings, server load balancing, perceived network latency reduction, and higher content availability.
Therefore this difference between D3 and claim 1 does not of itself constitute an inventive step.
The same analysis is equally applicable to claims 14–15 as they define the corresponding programming instruction and a electronic device executing the method of claim 1.
Furthermore, I have considered the appended claims 2–13. These claims define features that are either disclosed in the above cited documents or are mere design choices or are common general knowledge in the art, which therefore cannot contribute to a patentable inventive step.
For example, the feature of chronological order as defined by claim 2 is disclosed in D3 at Fig. 3, the feature of account identifiers as defined by claim 3 is disclosed in D3 at Paragraph [0042] as identifying information, the feature of claims 7 and 9 are disclosed in [D3] at Fig. 1 Ref 130.”
In response to this objection, the applicant responded with arguments and amendments. The amendments made slight adjustments to the wording of claim 1 and added claim 14. The examiner remained of the opinion that inventive step was lacking and objection 6 was raised in light of D3, with a further document D4 (NUSSER S et. al “Enabling Efficient Orienteering Behavior in Webmail Clients”, 20th annual ACM symposium on User interface software and technology 2007, pp. 139-148.) being used to establish common general knowledge. As should be clear from my comments at paragraphs [4] and [24] above, claims 1–16 that were considered by the examiner in their third report are identical to claims 1–14, 16 and 17 that are before me now.

Objection 6 was as follows (formatting and italics in the original):
“The invention defined in claims 1 – 16 do not involve an inventive step in light of D1[sic].
Objection number 5 raised in the previous Examination Report is maintained.
Applicant amendments and submissions have been carefully considered and found unpersuasive.
Applicant submits that the examiner approach has
1.been impermissibly influenced by hindsight
2.not provided any evidence for the feature of scrolling to view a different portion of conversation history forms part of the common general knowledge
3.(a) not engaged in what is involved in making the interface shown in Fig. 3 to receive a scrolling input to load for display the other portion of arranged conversation lines and (b) the common general knowledge also does not point to any problem or for that matter any other motivation to vary D3.
I will address each of these points below
1 and 3(b): At Paragraph [00062] D3 teaches that to improve rendering time (in other words to not overload the memory) only a maximum number (e.g., 50) of recent messages exchanged between the user and the contact. In other words, D3 discusses the problem of memory issues and teaches a solution to address this problem.
Therefore the prior art (D3) provides evidence that the problem of memory overload is known in the prior art.
2: Regarding the evidence that the feature of dynamic loading of content when scrolling is common general knowledge in the art, Applicant’s attention is drawn towards D4: Figs. 3 and 4 and corresponding text, specifically Page 145, as an example. See specifically where D4 teaches our DOM structure is designed to contain only a small subset of the message headers – about three times the number of rows that fit on a single page. We then pad this structure with two large elements on both sides to create a scrollbar of the proper size. Figure 3 shows how this approach can be used to drastically simplify the portions of the DOM that are not currently displayed. The extra sets of populated DOM nodes before and after the current page allow us to efficiently support page-up and page-down operations.
It should also be noted the current description discusses this feature in general terms at Paragraphs [0108]–[0112] and it is left to the skilled person to implement this technique. Therefore based on the face of the current specification alone, this feature appears to be a common general knowledge in the art.
3a: As discussed with respect to item 1 above, D3 does provide evidence that the problem of memory overload is known in the prior art.
A skilled person, by virtue of their experiences, would be well aware of the advancements and improvements in their field, that being the technique of dynamic loading in the current field. It would be readily apparent to them the advantages of the solution defined in the current claims and would implement them in D3 in a straight forward, non-inventive manner.
Therefore the solution provided by the current claims, that of using scrolling input for dynamic loading is considered to be a technical equivalent to the solution taught in D3.
Finally, Applicant has introduced a new dependent claim 14 and provides Paragraphs [91] – [96], [106] – [108] and [110] as support.
Using colours to distinguish content being presented is well known. It would be particularly obvious in light of D3 when it teaches visually distinguishing messages by service-identifying annotations (as shown in FIG. 3 refs 328 and 330),
The discussion with respect to other dependent claims as discussed in the previous Examination report is maintained.”
Inventive Step
Statutory framework
The statutory basis for inventive step is set out at s7(2) and s7(3) of the Act, and is reproduced below:
(2) For the purposes of this Act, an invention is to be taken to involve an inventive step when compared with the prior art base unless the invention would have been obvious to a person skilled in the relevant art in the light of the common general knowledge as it existed (whether in or out of the patent area) before the priority date of the relevant claim, whether that knowledge is considered separately or together with the information mentioned in subsection (3).
(3) The information for the purposes of subsection (2) is:
(a) any single piece of prior art information; or
(b) a combination of any 2 or more pieces of prior art information that the skilled person mentioned in subsection (2) could, before the priority date of the relevant claim, be reasonably expected to have combined.
The test for obviousness set out in Wellcome Foundation Ltd v VR Laboratories (Aust) Pty Ltd is whether it would have been a matter of routine to proceed to the claimed invention.
“The test is whether the hypothetical addressee faced with the same problem would have taken as a matter of routine whatever steps might have led from the prior art to the invention, whether they be the steps of the inventor or not.”[12]
[12] [1981] HCA 12 at [45]; (1981) 148 CLR 262 at 286
The High Court in Aktiebolaget Hässle v Alphapharm Pty Ltd[13] also approved the approach taken in Olin Mathieson Chemical Corporation v Biorex Laboratories Ltd in which Graham J had posed the reformulated Cripps question[14]:
“Would the notional research group at the relevant date in all the circumstances directly be led as a matter of course to try [the claimed invention] in the expectation that it might well produce a useful [desired result]?”
[13] [2002] HCA 59 at [51] – [53]
[14] [1970] RPC 157 at [187]
In AstraZeneca AB v Apotex Pty Ltd[15], the Full Court held that in formulating the problem it is not permissible to incorporate information that is not available to the person skilled in the art either as common general knowledge or information available under subsection 7(3).
[15] [2014] FCAFC 99 at [203]
In relation to what level of inventiveness is required to sustain a patent, the Full Federal Court in Garford Pty Ltd v Dywidag Systems International Pty Ltd stated as follows[16]:
“The inventiveness required to sustain a patent for a claimed invention is quite small. A ‘scintilla’ of inventiveness is all that is required: Alphapharm at [195]. However, there must still be ‘some difficulty overcome, some barrier crossed’ (per Lockhart J in RD Werner & Co Inc v Bailey Aluminium Products Pty Ltd [1989] FCA 57; (1989) 25 FCR 565 at 574) or some contribution to the art “beyond the skill of the calling” (Allsop Inc v Bintang Ltd [1989] FCA 297; (1989) 15 IPR 686 at 701)”.
[16] [2015] FCAFC 6 at [44]
Common General Knowledge (CGK)
Common general knowledge was described by the High Court in Lockwood Security Products Pty Ltd v Doric Products Pty Ltd [No 2] in the following terms[17]:
“‘Common general knowledge’ was well understood as being ‘part of the mental equipment of those concerned in the art under consideration’, and Minnesota Mining had confirmed that what was ‘known or used’ in Australia was confined to common general knowledge, which was explained as:
“the background knowledge and experience which is available to all in the trade in considering the making of new products, or the making of improvements in old””. (Citations omitted.)
[17] [2007] HCA 21; (2007) 235 CLR 173 at [55]
In Aktiebolaget Hässle v Alphapharm Pty Ltd[18], the High Court upheld the primary judge’s rejection of s7(3) information as common general knowledge in circumstances in which there was no evidence of its general acceptance and assimilation by the PSA.
[18] [2002] HCA 59; (2002) 212 CLR 411 at [31]
In order to qualify as common general knowledge, it is not necessary that the knowledge be memorised by the PSA. It is sufficient if it is material in the field in which the PSA is working which he or she knows exists to which he or she would refer as a matter of course (ICI Chemicals & Polymers Ltd v Lubrizol Corp Inc [1999] FCA 345; (1999) 45 IPR 577 at [112] per Emmett J; ICI Chemicals & Polymers Ltd v Lubrizol Corp Inc [2000] FCA 1349; (2000) 106 FCR 214 at [57]; see Bodkin C, Patent Law in Australia (2nd ed, Thomson Reuters, 2014) at [4110]).
Problem to be Addressed
The background discussion given in the application (see paragraph [9] above) discusses problems with keeping track of contacts on various services and switching between services to send messages to various recipients. However, in discussing the loading of portions of any particular conversation history, the specification notes:
“… memory constraints can prevent unified messaging app 145 from loading the entire communication history into system memory. Some embodiments implement intelligent memory caching by dynamically loading and unloading portions of the communication history page into and out of system memory, based at least in part on the portion within the page that the user is viewing at any given time”[19]
[19] Present application at [0106]
As such, the problem that is sought to be addressed by the claims has to do with addressing memory constraints. However, what impact the memory constraints have on a system is not explained. This is because the specification does not discuss what memory has constraints. The use of “system memory” is vague and unhelpful. It is well known that electronic devices can have different types of memory. RAM and ROM are two well-known examples. It is also known that there can be memory dedicated to image data (often called VRAM). The specification does not differentiate. Constraints in different memory could produce different effects. VRAM constraints may affect the device’s ability to properly (or quickly) render the display. Constraints in RAM may affect program loading speeds or operating speeds. It is not entirely clear what problem is being referred to when the specification states that there might be a problem “loading the entire communication history into system memory”.
The applicant’s submissions, both during examination and now, do not assist in this matter. Indeed, the applicant appears to have left it up to the examiner to find a problem, and then sought to differentiate the broadly proposed problem of the specification with the problem set out by the examiner.
To my mind, it is appropriate to maintain the problem to be addressed by the claimed invention as one of addressing memory constraints. Given the paucity of information in the specification, the problem must encompass problems in any memory type of the device which impacts the performance of the device in some way. What that impact is will be varied, but there must be an impact. The result of this is that any citation does not necessarily have to address the same impact that is embodied in the present application – viz a constraint in some sort of memory that affects the device’s ability to load the entire communication history.
The Person Skilled in the Art

The specification is to be construed through the eyes of the person skilled in the art (PSA). He or she is a hypothetical person, or team, having a practical interest in the subject matter of the invention. This includes both those who might wish to make the invention and those who might wish to use it. While well versed in the relevant field, the PSA is taken to be non-inventive; (Root Quality Pty Ltd v Root Control Technologies Pty Ltd [2000] FCA 980 at [71]- [72]; referring to Catnic Components Ltd v Hill & Smith Ltd [1982] RPC 183 at 242 and The General Tire & Rubber Company v The Firestone Tyre & Rubber Company Ltd [1972] RPC 457 at 485).
No submissions were made by the applicant in regard to the PSA. The identity of the PSA does not appear to have been discussed in the process of examination. I assume this is largely because there is little contention on the matter. For the sake of completeness, I consider it clear that the relevant person would include those with a working knowledge of the design, programming and use of electronics for computing. More specifically, it would seem that the PSA has experience in dealing with systems which contain memory constraints that impact the operation of the system in some way.
Claims construction
I note what Middleton J said in Eli Lilly and Company Limited v Apotex Pty Ltd[20]:
“It is well settled that the Court should, from the outset, approach the task of patent construction with a generous measure of common sense. The Court must place itself in the position of a person skilled in the relevant art, being the subject matter of the patent. From this perspective, the patent is to be read as a whole, in the context of the specification and in light of the prevailing common general knowledge and state of the relevant art at the priority date.”
[20] [2013] FCA 214, 100 IPR 451 at [139]
The correct approach to the construction of claims was discussed by Bennett J in H Lundbeck A/S v Alphapharm Pty Ltd[21]:
“… the words in a claim should be read through the eyes of the skilled addressee in the context in which they appear ... While the claims define the monopoly claimed in the words of the patentee's choosing, the specification should be read as a whole ... It is not permissible to read into a claim an additional integer or limitation to vary or qualify the claim by reference to the body of the specification ... terms in the claim which are unclear may be defined or clarified by reference to the body of the specification”
I will specifically construe only two terms of the claims.
[21] [2009] FCAFC 70, 81 IPR 228 at [118] – [120]
“communication session file”
As will be clear, the scope of this term is important to the determination of this matter. In their submissions, the applicant sought to distinguish the claims and the citation on the basis of, inter alia, what this term encompassed
Essentially, the applicant submitted that each communication session file contained the transcript of a chat between the two (or more) users using a communication service, with each message having an associated timestamp. The applicant noted that the present application described the files as having various parameters such as the date, time and/or participants of the chat session. Each file could store all communications from the same day, or all the communications in a single session over a range of time covering the duration of the session.
To my mind, there is force to the applicant’s submissions. Furthermore, I believe that this construction is supported by the words of the claim. Based on what is defined in the claim, a communication session file is a file containing “a set of conversation lines, each of the set of conversation lines being associated with a timestamp”. Each one of the communication session files includes a set of conversation lines transmitted using a specific one of the electronic communication services. That is, no two files contain conversation lines transmitted using the same communication service. While it is possible that the files contain the full set of all conversation lines between the users using that communication service, it does not have to be so limited. I would also note that the claim requires there to be at least two communication session files in existence.
This construction is consistent with the invention as described in the specification which, when discussing the invention with regard to figure 8, notes that communication session files 840 are stored in various databases 825, 830 and 835. The description states that each file could be composed of one message, or many messages, but it seems clear to me that they do not necessarily contain all messages, given that the files seem to be spread across the various databases. This “division” is also supported by the specification which describes each different session file as containing conversation lines “transmitted using different ones of multiple electronic communication services”[22]. It seems clear to me that this arrangement must result in these files only being partial records of all communication between at least two users.
[22] Present application at [0009]
Moreover, each communication session file is associated with only a single electronic communication service. The separate databases make this clear.
“loaded”/“loading”
The description refers to memory constraints possibly preventing “loading” the entire communication history into “system memory”[23]. Figures 11A and 11B show that this is addressed by loading a portion of the entire communication history 1105 into system memory, with a portion of the page displaying the conversation lines. As stated in the specification:
“… page 1105 is shown as being divided into a number of cells 1102, each corresponding to a portion of the communication history. A cell 1102 can be, e.g., a fixed number of conversation lines (e.g., one hundred lines) or a fixed amount of data (such as a page of system memory).”[24]
[23] Present application at [0106]
[24] Present application at [0107]
While this is describing a situation whereby a portion had previously been loaded, the claims also refer to the initial presentation of the communication history as being one where “at least a portion of the arranged conversation lines is loaded”.
To me it seems clear that, whenever “loaded” or “loading” is used in claim 1, it is describing a process whereby a part of the conversation history is taken from wherever it is stored (which is never discussed in the specification) and placed into that area of the memory which is accessed by the system (i.e. what has been called “system memory” in the description) to allow the user to view this conversation history portion on the page. This part of the conversation history could be the original portion, or a new part that was not part of the original portion that could be accessed by the user from the page.
I will note a couple of things. Firstly, while the claims define loading portions of the arranged conversation lines, contrary to the figures they never define unloading previously loaded portions. Secondly, it is clear from page 900 in figure 9, and from the fact that portions of the loaded message lie outside the viewing windows 1115 and 1120 of figures 11A and 11B, that it is possible to scroll through what is loaded to allow the user to see what is outside the viewing window. However, it is equally the case that, prior to it being loaded, this scrolling cannot access the not-loaded portion.
Applicant’s submissions
The applicant’s submissions, having covered the history of the present application and the objections raised, raised four broad lines of argument as to why the amended claims did not lack an inventive step. They were:
·D3 did not disclose or suggest obtaining a set of communication session files that store communications between the first user and the second user;
·D3 did not disclose or suggest arranging, displaying and loading conversation lines of communications between a first user and a second user using multiple different communication services, in the manner claimed;
·D3 did not disclose or suggest the dynamic loading of portions of the arranged conversation lines in response to receiving a scrolling input; and
·The combination of the interworking features of the claims as a whole.
I will consider the submissions under these headings.
“obtaining a set of communication session files”
The applicant submitted that, in the present application, for a communication history between two users, the electronic device obtained a set of communication session files. As I have already determined above, each communication session file contains the transcript of a chat between the two (or more) users using a communication service, but no file contains all communications between the users over all communication services.
The applicant noted that the present application described the files as having various parameters such as the date, time and/or participants of the chat session, and that each file could store all communications from the same day, or all the communications in a session, over a range of time covering the duration of the session.
The applicant stated that the present invention obtained these communication session files and “the conversation units or lines from all of the retrieved communication session files”[25] from these files were then arranged based on the timestamps associated with the lines.
[25] Present application at [0104]
The applicant sought to contrast this with D3. The applicant noted that the examiner stated in their objection that:
“D3 discloses storing communication session files including a set of conversation lines, each of the set of conversation lines at Paragraph [0036] when it discloses a message content database Fig. 1 Ref 140 arranged to store content and attachments (e.g., media objects) of messages sent and received by the messaging applications Fig. 1 Ref 130. D3 explicitly discloses displaying messages along with the time the message was received, see at least Figs. 2 and 3. Therefore it is inherent that D3 discloses the storing the message content in the message content database along with its associated with a timestamp. As shown at Fig. 1 Ref 130, D3 teaches the conversation lines in different ones of the set of communication session files were transmitted using different ones of a plurality of electronic communication services.”
The applicant indicated that they understood the examiner to be saying that the items stored in database 140 were equivalent to the communication session files of the claim. They contended that this was “mere assertion”[26] and stated that pointing to the message database storing content and attachments of messages sent and received by the messaging applications said nothing about the existence or not of files in the form of the claimed communication session files.
[26] Applicant’s submissions at page 4
The applicant indicated that the message content database of D3 stored the content and attachments of messages sent and received by the messaging applications, and the threading engine accessed the message content database, the contacts database, and the message log to identify the sender of a message and track the various types of messages sent and received by the device. The applicant noted D3 stated:
“The threading engine 146 may be arranged, for example, to determine the sender of an incoming or received message as well as to determine the recipient of an outgoing or sent message. The sender or the recipient may be determined by the threading engine 146 using various types of identifying information associated with a particular message such as a telephone number, e-mail address, IM screen name, SMS identifier, MMS identifier, and so forth.”[27]
[27] D3 at [00041]
The applicant submitted that, therefore, D3 described that the relevant messages from the message content database were extracted on the basis of aspects of each message. The applicant submitted that D3 used a “message-by-message” approach and referred to paragraph [00042] of D3 as supporting the conclusion that messages of different types for a particular contact were threaded together when each message was sent or received:
“… the threading engine 146 may match identifying information associated with an incoming or outgoing message against contact records stored in the contacts database 142. In such implementations, messages of different types may be correlated and threaded together for a particular known contact. For example, a contact record may comprise a name, telephone number, e-mail address, and an IM screen name for a known contact. In this case, identifying information associated with several different types of messages such as telephone messages, voicemail messages, fax messages, SMS messages, MMS messages, e-mail messages, and IM messages all may be matched against the contact record to correlate and thread together messages for the known contact.”[28]
[28] D3 at [00042]
Consideration
The applicant is seeking to differentiate the communication session files of the present application from the file in D3. As I understand the argument, the applicant is saying that what is stored in the message content database of D3 are not files containing subsets of all communication between two users. Rather, the database contains a file which contains all communication lines transmitted and received using all communication services. According to the applicant, the result is that D3 does not obtain a set of communication session files.
I can see the force in the applicant’s arguments. What D3 discloses is a device storing (i) content and attachments (if any) of a message, (ii) identifying information of various contact and (iii) logs of messages sent and received. I cannot see how any of these can be equivalent to a communication session file of the present application. There is none of the “division” I mentioned above. While it may be said that the device of D3 stores, in essence, the same information as all the communication session files of the present application, the structure (or how the storage is arranged) is different.
Furthermore, while D3 discloses presenting the user with a message list (see Figure 2), none of the items in the list could be said to be “a set of communication session files that store communications between the first user and the second user” as per claim 1. At best what is shown are communications between a first user and many other users transmitted using different communication services.
Moreover, the message thread that can be presented to the user (see Figure 3) is not a set of lines transmitted using an electronic communication service, as is required for the communication session files of the claims. Rather, it is a history of communications between a first and second user across all electronic communication services rather than just one.
As such, I do not consider this feature to be disclosed in D3. I also do not see it disclosed in D4. This is not to say that such a feature is not known in the art. However, the evidence presented thus far does not establish that it is.
“arranging, displaying and loading conversation lines”
The applicant noted that proposed claim 1 required “arranging ... the conversation lines from all of the set of communication session files in an order based on the associated timestamps”, “displaying, on the display … at least a portion of the arranged conversation lines”, and that “at least the portion of the arranged conversation lines is loaded”.
The applicant submitted that D3 did not disclose:
(i)arranging conversation lines from all of the set of obtained communication session files of communications between a first user and a second user using multiple different communication services,
(ii)displaying, and
(iii)loading a portion of these arranged conversation lines.
Consideration
Given my conclusion with respect to communication session files above, the applicant must be correct that D3 does not disclose (i). However, I would make the observation that, ignoring for the moment the lack of disclosure of communication session files, D3 does disclose (ii) and (iii).
It is quite clear from Figure 3 of D3 that a portion of the arranged conversation lines are displayed. Moreover, to be displayed, and as I have construed the term, the lines must have been “loaded” into memory. It is also clear from D3 that only a portion of all conversation lines have been loaded, and that other conversation lines are loaded by clicking a hyperlink. The applicant’s submissions do not change this because, as far as I can understand, they were focused on the lack of enabling the user “to readily perceive the content or the conversation lines of the communications between a first user and a second user”[29]. In this regard, the applicant submitted that D3’s display of the messages:
“is not equivalent to and does not suggest displaying the actual conversation lines between first and second users. Rather, in order to view or listen to the content of an email or voicemail message, the user must click on the linked email address information of the contact or the linked telephone number information of the contact.”[30]
[29] Applicant’s submission at page 5
[30] Applicant’s submission at page 5
However, the phrase “portion of the arranged conversation lines” in claim 1 to my mind, clearly refers to the portion of all arranged conversation lines that have been loaded into system memory. Claim 1 makes no mention of displaying the actual content of the conversation lines.
“dynamic loading”
The applicant noted that the examiner conceded that D3 did not explicitly disclose loading another portion of the arranged conversation lines when a user scrolled from the portion of the page currently being viewed to another portion. They noted that the examiner considered that the feature of dynamic loading of content when scrolling was common general knowledge and that D4 was indicative of this.
The applicant responded to this by seeking to distinguish what was described in D4. Noting the passage from D4 that was cited by the examiner in their report (see [36] above), the applicant observed that the immediately preceding paragraph in D4 stated (bolding in submission):
“Since bluemail is designed to maintain a local cache of all the message headers, our objective in displaying a folder is to provide an accurate scrolling and viewport mechanism. There are, however, significant performance challenges to overcome in updating complex visual DOM structures. ... Rendering an entire mailbox in this fashion—u * t = 10,000 * 100ms = 1000s — would obviously be prohibitively long.”[31]
[31] Applicant’s submission at page 6
The applicant submitted that the dynamic rendering described in D4 was different to the dynamic loading required in claim 1. Specifically, the applicant submitted that maintaining a local cache was incompatible with a system that dynamically loaded objects.
The applicant also submitted that D3 did not disclose any relevant problem that could be used as a starting point to the inventive step enquiry. The applicant noted that the examiner asserted:
“At Paragraph [00062] (this should be a reference to paragraph [00061]) D3 teaches that to improve rendering time (in other words to not overload the memory) only a maximum number (e.g., 50) of recent messages exchanged between the user and the contact. In other words, D3 discusses the problem of memory issues and teaches a solution to address this problem.”
The applicant submitted that the problem of rendering time was not a memory overloading problem. They submitted that the examiner sought to associate the need for improving rendering performance with the memory overloading problem. The applicant stated that there was no teaching or suggestion in D3 that the rendering time of the messaging UI was limited by memory overloading. The applicant also submitted that if the examiner intended that “rendering time” incorporated “memory overloading”, then the applicant’s position was that the problem statement impermissibly incorporated part of the claimed solution, since:
“the problem of rendering time addressed by D3 and D4 is different to the problem of memory overloading addressed by the present application”[32]
[32] Applicant’s submission at page 6

The applicant submitted that the evidence before the examiner did not establish dynamic loading was known. The applicant noted that, in D4, the webmail application displayed metadata associated with each received email message, such as the sender of the email, the size of the email, the subject and the receipt date. The applicant submitted that D4 did not teach or suggest dynamically loading portions of arranged conversation lines.
Finally, the applicant submitted that clicking on the hyperlink of D3 is not consistent with any dynamic scrolling from D4. I interpolate this to mean that the applicant believes that one action in D3 or D4 cannot be replaced with the action in the other. The applicant submitted that (bolding in submission):
“D3 provides no teaching or suggestion that a user can scroll to view messages beyond those already available for viewing in the messaging UI. Instead, in D3, the user must click on hyperlink 320, which results in retrieving and display of archived messages. Importantly, as described above D3 discloses a process of considering individual messages for threading, not session files containing messages. Whilst communication session files may contain messages outside of the relevant time window, so that dynamic loading as claimed has a working interrelationship and synergistic effect with the use of session files, this is not the case if individual messages are being threaded. In that case a request to display another page is not a request to load another portion of previously arranged conversation lines, but to request the arrangement of individual messages to create a new page of threaded messages.
Applicant submits that D3 fails to teach or suggest in response to receiving a scrolling input, loading another portion of the arranged conversation lines corresponding to the another portion of the page, as recited by pending claim 1. Further, the examiner’s alleged indicator of common general knowledge (e.g. D4) also fails to teach or suggest such features.”[33]
[33] Applicant’s submission at page 7
Consideration
I do not agree with the applicant.
As a first point, the problem to be solved is to deal with memory constraints. In this regard, I consider it is well known that memory constraints in VRAM can interfere with efforts to properly (or quickly) render a display. In this sense, the reference in D3 and D4 to issues with rendering can, in my opinion, to be taken as references to addressing memory constraints. The fact that there are local caches is not relevant here. To my mind it was reasonable for the examiner to take the position they did.
In addition, as examiner notes in their report, the level of disclosure in the specification when discussing the implementation of such dynamic loading suggests that the technique is known to such an extent that no specific instruction is required. This strongly suggests that the technique is common general knowledge. I also note that the technique of “infinite scrolling (see for example is very well known and something which falls within the scope of the claims, particularly given my comments above when construing the terms “loaded” and “loading”.
As to the submission of D4 not teaching or suggesting dynamically loading portions of arranged conversation lines another point, it would appear that the applicant has interpreted “a portion of the arranged conversation lines” in claim 1 as meaning that what is displayed is the content of the conversation lines, such that what the claims require is for this content to be loaded, which, according to the applicant, does not happen in either D3 or D4. In this regard, I have already noted above that claim 1 does not require displaying the actual content of the conversation lines. Moreover, assuming that, when the present application purports to include Voice over Internet Protocol (VoIP) messaging in the arranged communication lines, it is showing only those VoIP message that are text only (since it would be, frankly, incredible for there to be a phone call where the only words spoken are “Hey Mandy”[34]), I believe that the present application requires a display of at least a part of the conversation where that conversation consists of text. In my opinion, such an arrangement is shown in Figures 2 and 3 of D3. I am also of the opinion that Figure 4 of D4, showing the subject lines of emails, also displays “a portion” of the emails.
[34] See item 925 of Figure 9 of the present application
Finally, with regards to the applicant’s final point quoted above, as I understand the reasoning, the applicant is of the opinion that D3 and D4 are, upon being requested to display an undisplayed portion of messages, generating an arrangement of individual messages to create a new page of threaded messages, such that a new page is created “on the fly” with each request. With respect, I simply cannot see that in either D3 or D4. In both there would appear to be a process that creates a complete list and then portions of that list are displayed. I cannot find support for a conclusion that a new list of threaded messages is created all over again whenever a scrolling instruction (or clicking a hyperlink as described in D3) is received.
“combination of the interworking features”
The final submission was that, notwithstanding the focus on individual features in the submission, it is the overall combination that must be considered. The applicant noted (bolding in original):
“In this case there is a combination of, for example:
a)The obtained data is in communication session files that store communications between the relevant users (the first and second users recited in claim 1);
b)Arranging conversation lines;
c)The arranged conversation lines are from all of the set of communication session files;
d)Loading another portion of the arranged conversation lines in response to a user scrolling input.
By the above, the process of arranging is an arranging of communications in the obtained session files. All obtained session files are used in the arranging process. There is therefore a level of control or reduction (in comparison to possible alternatives) over the use of processing resources for creating the communication history. This may be further increased by the dynamic loading (to adopt the examiner’s terminology). Further, the communication history specifically relates to conversation rather than for example metadata of messages containing conversation.”[35]
[35] Applicant’s submissions at page 7
Consideration
I do not disagree with the applicant that the combination as a whole is to be considered. This is well established in the caselaw.
Inventive step – finding
The examiner’s objection is not sustainable.
I am of the opinion that D3 discloses displaying a communication history over a plurality of electronic communication services between a first user and a second user after such is “requested” by the user selecting the thread. The thread consists of conversation lines (each line being a separate message) arranged in an order based on the timestamps associated with each message. When first displayed, only a portion of all conversation lines is loaded for display. D3 can load and display the remaining portion conversation lines when the user selects that option.
As noted by the examiner, D3 does not disclose loading the remaining portion of the conversation lines in response to receiving a scrolling indication. However, the examiner noted that this feature of dynamic loading of content when scrolling is common general knowledge in the art, and drew attention to D4. While disputed by the applicant, as is clear from my reasons above, I am of the opinion that the examiner’s position was reasonable to take. In the context of the problem being a very broad one of dealing with memory constraints, the reference in D3 and D4 to issues with rendering, and knowing that VRAM can interfere with efforts to properly (or quickly) render a display, to my mind, the PSA would, as a matter of routine, implement such a feature to address the memory constraint. I also note my comment that the loading of further items to display upon scrolling is a very well-known concept (with “infinite scrolling” being an example).
However, unlike the examiner, I do not see any evidence to suggest that, prior to creating the arranged conversation lines, a set of communication session files are retrieved from a source different (which is described in the present application as residing in databases associated with electronic communication services), where each file contains conversation lines between the users of that communication service. D3 does not describe the retrieval of discrete files and arranging them into a whole. Moreover, it is not known from any evidence currently on file, or to me, that such files exist in the databases of any communication service (or are stored in a phone’s memory) and are retrievable (or, if they exist, retrieved on a routine basis).
Dependent claims
It follows from this conclusion that an objection as to lack of inventive step cannot be sustained against the dependent claims.
However, noting that the applicant made submissions regarding the inventiveness of claims 11, 14 and 15 specifically, I will briefly address those claims. I will not provide the text of those claims here. They are provided in the Annex to this decision.
Claim 11
In my opinion, D3 discloses conversation lines from a first user to a second user via at least first and second electronic communication services and vice versa. The only feature in claim 11 that is not disclosed in D3 is the feature of the conversation lines of the different users are on different sides of a communication history region. Figure 9 shows this. In contrast, figures 2 and 3 of D3 show all the messages arranged in vertical alignment. I do not see how such a difference could contribute an inventive step. Such alignment has been present when displaying messages for many years. See, for example, the recording of the launch of the iPhone at from 30:39 to 32:23, with particular focus on 31:03 to 32:05.
Claim 14
Again, I do not see anything in this claim that could provide an inventive step. The use of background colour to distinguish different parts of a conversation is well known (see, again, the iPhone launch video mentioned above). I cannot see how a decision to use colour to distinguish the communication service used instead of an icon (as described in D3) is inventive. Both methods are well-known techniques; they are essentially technical equivalents.
Claim 15
This claim has an inventive step in light the current evidence for the same reason as claim 1 does. There is no disclosure or suggestion of obtaining a set of communication session files that store communications between the users in response to a user request.
CONCLUSION
The examiner’s objection is not sustainable. This conclusion is based upon the fact that there is no evidence to establish that it would be a matter of routine to retrieve communication session files from a source prior to arranging the lines into a coherent whole, based upon the timestamp associated with each conversation line in each file.
However, notwithstanding that I am not aware of such communication session files even existing (which would be required for the invention to work as described), this is not to say that they do not exist. Having regard to the casefiles of the present application, the parent application and the grandparent application, it could be said that the existence of such session files and their use has not been fully investigated by the examiner in their assessment of actions at other patent officers and in searches carried out by the examiner.
In such circumstances, it is appropriate for the matter to be returned to the examiner to carry out such investigation. If no evidence can be found to establish that communication session files are available at, and retrievable from, different sources, then the application should be accepted. If evidence is found, then the examiner will be required to assess whether an objection can be taken. I would expect acceptance, or objection, to occur within the month following this decision.
In accordance with sub-regulation 13.4(3), noting that I have returned the matter to examination, the final date for acceptance of this application shall be four (4) months from the date of this decision.
Greg Powell
Delegate of the Commissioner of Patents
Annex – Claims
1.        A method comprising:
receiving, by an electronic device that includes a display, a request for a communication history between a first user and a second user;
obtaining, by the electronic device, a set of communication session files that store communications between the first user and the second user, each of the set of communication session files including a set of conversation lines, each of the set of conversation lines being associated with a timestamp, wherein the conversation lines in different ones of the set of communication session files were transmitted using different ones of a plurality of electronic communication services;
arranging, by the electronic device, the conversation lines from all of the set of communication session files in an order based on the associated timestamps;
displaying, on the display, by the electronic device, at least a portion of the arranged conversation lines, wherein:
the arranged conversation lines are displayed on a page in a user interface of the electronic device;
the displayed portion of the arranged conversation lines corresponds to a portion of the page currently being viewed by the first user; and
at least the portion of the arranged conversation lines is loaded;
receiving an input of the first user scrolling from the portion of the page currently being viewed by the first user to another portion of the page; and
in response to receiving the input, loading another portion of the arranged conversation lines corresponding to the another portion of the page.
2         The method of claim 1, wherein the order is a chronological order.
3.        The method of claim 1 or 2, wherein obtaining the set of communication session files between the first user and the second user includes:
identifying a first set of account identifiers associated with the first user, each of the first set of account identifiers being associated with one of the plurality of electronic communication services; and
identifying, for the plurality of electronic communication services, a second set of account identifiers associated with the second user, wherein the set of communication session files is obtained by retrieving communication session files associated with at least one account identifier in the first set of account identifiers and at least one account identifier in the second set of account identifiers.
4.        The method of claim 1 or 2, wherein the request is received from the first user and includes a first identifier for the second user in any one of the plurality of electronic communication services.
5.        The method of claim 4, including:
determining, by the electronic device, one or more other identifiers for the second user;
wherein obtaining the set of communication session files includes obtaining a communication session file associated with one of the one or more other identifiers of the second user.
6.        The method of claim 5, wherein the one or more other identifiers for the second user are determined by searching a database of user contacts and identifying a set of identifiers associated with the first identifier for the second user, the one or more other identifiers being associated with different ones of the plurality of electronic communication services.
7.        The method of any of claims 1-6, wherein the communication history includes at least one of textual data, audio data, video data, image data, or a combination thereof.
8.        The method of any of claims 1-7, wherein the set of communication session files includes a first subset of the communication session files that are obtained locally and a second subset of the communication session files that are obtained from a remote server accessible through an application programming interface (API).
9.        The method of any of claims 1-8, wherein the plurality of electronic communication services includes at least one of e-mail, instant messaging, Short Message Service (SMS), or Voice over Internet Protocol (VoIP).
10.      The method of any of claims 1-9, wherein the set of communication session files includes a first communication history and a second communication history, the first communication history includes at least one message sent by the first user to the second user via a first communication service and at least one message sent by the second user to the first user via the first communication service, and the second communication history includes at least one message sent by the first user to the second user via a second communication service and at least one message sent by the second user to the first user via the second communication service.
11.      The method of any of claims 1-10, wherein displaying at least the portion of the arranged conversation lines includes concurrently displaying conversation lines from the first user and the second user arranged relative to different sides of a communication history region, including:
displaying the conversation lines from the first user arranged relative to a first side of the communication history region, wherein the conversation lines from the first user that are arranged relative to the first side of the communication history region include:
a conversation line from the first user via a first of the plurality of electronic communication services; and
a conversation line from the first user via a second of the plurality of electronic communication services; and
displaying the conversation lines from the second user arranged relative to a second side of the communication history region that is different from the first side of the communication history region, wherein the conversation lines from the second user that are arranged relative to the second side of the communication history region include:
a conversation lines from the second user via the first of the plurality of electronic communication services; and
a conversation line from the second user via the second of the plurality of electronic communication services.
12.      The method of any of claims 1-11, including, concurrently with displaying at least the portion of the arranged conversation lines, displaying, on the display, a communication creation affordance for sending a new communication from the first user to the second user via one of the plurality of electronic communication services.
13.      The method of claim 12, wherein the communication creation affordance includes a message entry box and a send button for sending a new communication that includes text entered in the message entry box.
14.      The method of any of claims 1-13, wherein displaying at least the portion of the arranged conversation lines includes concurrently displaying at least one message sent by the first user to the second user via the first communication service and at least one message sent by the second user to the first user via the first communication service, and at least one message sent by the first user to the second user via the second communication service and at least one message sent by the second user to the first user via the second communication service, the messages sent using the first communication service being visually distinguished from the messages sent using the second communication service by background color.
15.      The method of any of claims 1-14, wherein the request for a communication history is a user request and wherein obtaining the set of communication session files that store communications between the first user and the second user is performed in response to receiving the user request for the communication history between the first user and the second user.
16.      A computer readable medium encoded with program instructions that, when executed, cause a processor in a computing device including a display to execute the method of any of claims 1-15.
17.      An electronic device, comprising:
a display;
a processor; and
a memory device coupled to the processor, the memory device including instructions, wherein the instructions, when executed by the processor, cause the processor to perform the method of any of claims 1-15.